《CSNA網(wǎng)絡(luò)分析認證專家實戰(zhàn)案例》課件-第3章

第3章某保險公司VPN異常中斷故障分析報告3.1故障描述3.2分析過程3.3結(jié)論及建議

3.1.1故障現(xiàn)象

某保險公司北京總公司與各地分公司均通過雙線與當(dāng)?shù)仉娦藕吐?lián)通兩大互聯(lián)網(wǎng)運營商相連，各地分公司通過IPSecVPN(即指采用IPSec協(xié)議來實現(xiàn)遠程接入的一種VPN技術(shù)，IPSec全稱為InternetProtocolSecurity)接入總公司內(nèi)部網(wǎng)絡(luò)。3.1故障描述近期由于業(yè)務(wù)量增加，對廣域網(wǎng)的帶寬需求加大，用戶對總公司的聯(lián)通接入線路進行了擴容，升級后總公司聯(lián)通線路的承載能力得到了提高，但各地分公司通過聯(lián)通網(wǎng)絡(luò)建立的VPN隧道經(jīng)常會出現(xiàn)短時間的中斷現(xiàn)象。用戶懷疑是新升級的聯(lián)通互聯(lián)網(wǎng)線路存在問題，或者運營商對其VPN通信進行了限制或干擾，需要通過網(wǎng)絡(luò)協(xié)議分析查找造成中斷的具體原因。3.1.2環(huán)境描述

本次分析使用科來回溯分析系統(tǒng)1002T，在總公司的VPN服務(wù)器(一臺Juniper防火墻)外側(cè)部署，7

×

24小時捕獲并分析其VPN隧道ESP流量以及ISAKMP(InternetSecurityAssociationandKeyManagementProtocol，Internet安全連接和密鑰管理協(xié)議)流量，其拓撲示意圖如圖3-1所示。

圖3-1

3.2.1流量趨勢分析

用戶的技術(shù)人員通過VPN兩端的防火墻日志查看到福建分公司VPN隧道于11月13日凌晨1時、下午15時和下午18時左右發(fā)生過3次短暫中斷，本次分析就重點針對這3次中斷進行。3.2分析過程首先，通過回溯分析系統(tǒng)的IP流量精細分析功能，查看發(fā)生中斷的VPN對端IP地址175.44.133.172在11月13日下午14時30分至18時30分的流量趨勢，如圖3-2所示。

圖3-2從4小時窗口(精度:分鐘)的趨勢圖上我們并沒有看到明顯的長時間流量中斷，在發(fā)生問題的15時05分和18時05分左右也沒有出現(xiàn)流量為0的情況。于是我們進一步使用4分鐘窗口(精度:秒)查看15時05分和18時05分左右的流量趨勢，如圖3-3所示。

圖3-3從圖3-4能夠看出，發(fā)生中斷時，有2分鐘左右的時間，在總公司防火墻前端能夠收到福建VPN對端的數(shù)據(jù)包，但是總公司的防火墻向?qū)Χ税l(fā)送的數(shù)據(jù)包很少。通過與正常時段的流量進行比對分析我們發(fā)現(xiàn)，在正常時段VPN兩端發(fā)送的數(shù)據(jù)包量基本相當(dāng)。

圖3-4在福建VPN13日凌晨發(fā)生中斷的時刻，以及用戶提供的其他VPN隧道中斷的時刻，我們也看到了相同的現(xiàn)象。由此我們基本可以判斷：發(fā)生中斷時，總公司和分公司之間的互聯(lián)網(wǎng)鏈路(聯(lián)通運營商網(wǎng)絡(luò))應(yīng)該沒有問題，很可能是由于一段時間內(nèi)總公司防火墻沒有發(fā)送數(shù)據(jù)導(dǎo)致VPN中斷。3.2.2數(shù)據(jù)包解碼分析

為了進一步分析造成VPN中斷的根源，我們下載了福建VPN175.44.133.172在11月13日下午的全部數(shù)據(jù)包進行解碼分析。

在福建分公司175.44.133.172與總公司123.127.198.81之間通信的數(shù)據(jù)包中我們看到，在發(fā)生中斷的15時03分58秒，兩端防火墻使用UDP500端口交互了3個報文，在此之后的1分50秒時間只看到175.44.133.172使用新的SPI(安全參數(shù)索引)發(fā)送ESP數(shù)據(jù)包，123.127.198.81沒有發(fā)送任何ESP數(shù)據(jù)包，如圖3-5所示。

圖3-5這3個UDP500端口的報文偏移量為3C的字段值(Exchangetype類型字段)均為“0x20”，表示這三個報文是ISAKMP二階段協(xié)商的報文，主要作用是協(xié)商新的ESPSA。從這三個報文之后175.44.133.172發(fā)送的ESP報文使用了新的SPI可以判斷，此次二階段協(xié)商并沒有問題，福建分公司的防火墻已經(jīng)使用了新的ESPSA進行后續(xù)數(shù)據(jù)加密，但總公司的防火墻并沒有使用新的SA發(fā)送數(shù)據(jù)，也沒有繼續(xù)使用以前的SA發(fā)送數(shù)據(jù)，很可能是總公司防火墻自身的程序出現(xiàn)問題導(dǎo)致這一現(xiàn)象。從整個下午的數(shù)據(jù)包來看，在13時04分和14時04分也有過一次二階段協(xié)商，但后續(xù)雙方都正常使用新的SPI交互數(shù)據(jù)。由此可以推斷：雙方的ESPSA生存時間為1小時，雙方每過一小時會進行一次二階段協(xié)商更換ESP密鑰，不過15時03分的二階段協(xié)商之后出現(xiàn)了意外情況。

在圖3-5中的二階段協(xié)商完成1分51秒后，我們看到175.44.133.172向123.127.198.81發(fā)送了一個Exchangetype字段為“0x05”(ISAKMPInformation)的通知報文，然后雙方又交換了3個二階段協(xié)商報文，如圖3-6所示。

圖3-6不過在此次協(xié)商之后VPN兩端都使用了新的SPI進行ESP數(shù)據(jù)交互，后續(xù)通信正常。我們推斷很可能是福建分公司的防火墻在15時03分更新ESPSA后一直沒有收到總公司的ESP數(shù)據(jù)，因此在1分50秒后通過ISAKMPinformation消息通知總公司防火墻刷新SA，而這次SA更新后總公司防火墻沒有出現(xiàn)異常。

從上面這些情況來看，15時03分第一次協(xié)商之后，福建分公司的防火墻IPSec處理正常，后續(xù)發(fā)送的ESP數(shù)據(jù)包序列號連續(xù)，可以確定兩地之間的互聯(lián)網(wǎng)鏈路也沒有問題。造成此次中斷的直接原因是在15時03分的二階段協(xié)商之后，總公司防火墻處理出現(xiàn)異常，沒有正確使用新的ESPSA通信。

在18時05分左右，我們又看到了相同的現(xiàn)象：第一次二階段協(xié)商后總公司防火墻不發(fā)送新的ESP數(shù)據(jù)，1分53秒后進行第二次二階段協(xié)商，只不過第二次二階段協(xié)商后過了48秒總公司防火墻才使用新的SA發(fā)送數(shù)據(jù)，這也正是趨勢圖上看到有2分40秒單向通信的原因所在，如圖3-7所示。通過對比多次不同分公司VPN中斷時刻的數(shù)據(jù)，我們發(fā)現(xiàn)每次中斷的現(xiàn)象均一致，并且有些正常時段在雙方更新SA后，總公司的防火墻也會出現(xiàn)短時間不發(fā)送數(shù)據(jù)的情況。如果這一現(xiàn)象持續(xù)時間超過1分50秒，雙方就會重新開啟二階段協(xié)商，在這段時間內(nèi)VPN處于中斷的狀態(tài)。

圖3-7

3.3.1分析結(jié)論

根據(jù)上面的分析，我們可以得出以下結(jié)論：

(1)監(jiān)控鏈路的流量趨勢穩(wěn)定，沒有發(fā)現(xiàn)明顯的持續(xù)丟包或鏈路質(zhì)量異常的現(xiàn)象，總公司與分公司之間使用聯(lián)通線路的VPN隧道短時間中斷現(xiàn)象與運營商的網(wǎng)絡(luò)鏈路無關(guān)。

3.3結(jié)?論?及?建?議

(2)造成異常中斷的直接原因是在周期性二階段協(xié)商之后，總公司的防火墻可能存在Bug或異常情況，導(dǎo)致不能使用新的SA進行后續(xù)ESP通信。

由于這一現(xiàn)象是在聯(lián)通線路擴容之后才出現(xiàn)的，我們懷疑是由于擴容后聯(lián)通線路流量增大，而總公司防火墻上