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

3.1.1故障現(xiàn)象

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

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

×

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

圖3-1

3.2.1流量趨勢分析

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

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

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

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

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

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

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

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

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

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

在18時(shí)05分左右，我們又看到了相同的現(xiàn)象：第一次二階段協(xié)商后總公司防火墻不發(fā)送新的ESP數(shù)據(jù)，1分53秒后進(jìn)行第二次二階段協(xié)商，只不過第二次二階段協(xié)商后過了48秒總公司防火墻才使用新的SA發(fā)送數(shù)據(jù)，這也正是趨勢圖上看到有2分40秒單向通信的原因所在，如圖3-7所示。通過對比多次不同分公司VPN中斷時(shí)刻的數(shù)據(jù)，我們發(fā)現(xiàn)每次中斷的現(xiàn)象均一致，并且有些正常時(shí)段在雙方更新SA后，總公司的防火墻也會(huì)出現(xiàn)短時(shí)間不發(fā)送數(shù)據(jù)的情況。如果這一現(xiàn)象持續(xù)時(shí)間超過1分50秒，雙方就會(huì)重新開啟二階段協(xié)商，在這段時(shí)間內(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隧道短時(shí)間中斷現(xiàn)象與運(yùn)營商的網(wǎng)絡(luò)鏈路無關(guān)。

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

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

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