《CSNA網絡分析認證專家實戰案例》課件-第3章

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

3.1.1故障現象

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

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

×

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

圖3-1

3.2.1流量趨勢分析

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

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

圖3-3從圖3-4能夠看出，發生中斷時，有2分鐘左右的時間，在總公司防火墻前端能夠收到福建VPN對端的數據包，但是總公司的防火墻向對端發送的數據包很少。通過與正常時段的流量進行比對分析我們發現，在正常時段VPN兩端發送的數據包量基本相當。

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

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

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

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

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

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

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

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

圖3-7

3.3.1分析結論

根據上面的分析，我們可以得出以下結論：

(1)監控鏈路的流量趨勢穩定，沒有發現明顯的持續丟包或鏈路質量異常的現象，總公司與分公司之間使用聯通線路的VPN隧道短時間中斷現象與運營商的網絡鏈路無關。

3.3結?論?及?建?議

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

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