故障描述
某保險公司北京總公司與各地分公司均通過雙線與當地電信和聯(lián)通兩大互聯(lián)網運營商相連，各地分公司通過IPsec VPN接入總公司內部網絡。
由于業(yè)務量增加，對廣域網的帶寬需求加大，用戶對總公司的聯(lián)通接入線路進行了擴容。升級后總公司聯(lián)通線路的承載能力得到了提高，但各地分公司通過聯(lián)通網絡建立的VPN隧道經常會出現短時間的中斷，用戶懷疑是新升級的聯(lián)通互聯(lián)網線路存在問題，或運營商對其VPN通訊進行了限制或干擾，需要通過網絡協(xié)議分析查找造成中斷的具體原因。
環(huán)境描述
本次分析使用科來回溯分析系統(tǒng)1002T，在總公司的VPN服務器(一臺Juniper防火墻)外側部署，7×24小時捕獲并分析其VPN隧道ESP流量以及ISAKMP流量，部署拓撲示意圖1：
1、流量趨勢分析
首先通過回溯分析系統(tǒng)的IP流量精細分析功能查看發(fā)生中斷的VPN對端IP地址175.44.133.172的11月13日下午14:30~18:30的流量趨勢。從趨勢圖上，并沒有發(fā)現明顯的長時間流量中斷，在發(fā)生問題的15:05和18:05左右也沒有出現流量為0的情況。于是進一步使用4分鐘窗口(1秒鐘精度)查看15:05和18:05左右的流量趨勢，發(fā)現在發(fā)生中斷的2min內，總公司防火墻前端能夠收到福建VPN對端的數據包，但是總公司的防火墻向對端發(fā)送的數據包卻很少。通過與正常時段的流量進行比對分析，正常時段VPN兩端發(fā)送的數據包量基本相當。
福建VPN 13日凌晨中斷，通過用戶提供的其他VPN隧道中斷時刻我們也看到了兩端數據包發(fā)送量差距巨大的現象。由此我們基本可以判斷發(fā)生中斷時刻，總公司和分公司之間的互聯(lián)網鏈路(聯(lián)通運營商網絡)沒有問題，很可能是由于總公司防火墻某段時間沒有發(fā)送數據導致VPN中斷。
2、數據包解碼分析
下載福建分公司VPN 175.44.133.172的11月13日下午的全部數據包進行解碼分析。
從數據包來看，當天下午雙方每小時會進行一次二階段協(xié)商來更換ESP密鑰，可推斷雙方的ESP SA生存時間為1小時，但15:03的二階段協(xié)商出現了意外情況。
在福建分公司175.44.133.172與總公司123.127.198.81之間通信的數據包中我們看到在發(fā)生中斷的15:03:58兩端防火墻使用UDP 500端口交互了3個報文。通過分析3個UDP 500端口的報文，發(fā)現偏移量為3C的字段值(Exchange type類型字段)均為”0x20”，表示這三個報文是ISAKMP二階段協(xié)商的報文，主要作用是協(xié)商新的ESP SA。這三個報文之后175.44.133.172發(fā)送的ESP報文使用了新的SPI(安全參數索引)，但總公司的防火墻并沒有使用新的SA發(fā)送數據，也沒有繼續(xù)使用以前的SA發(fā)送數據，可推斷是總公司防火墻自身的程序出現問題導致這一現象。1分51秒后，我們看到175.44.133.172再次向123.127.198.81發(fā)送了一個Exchange type字段為“0x05”(ISAKMP Information)的通知報文，然后雙方又交換了3個二階段協(xié)商報文，此次協(xié)商之后VPN兩端都使用了新的SPI進行ESP數據交互，后續(xù)通訊正常。
從上面這些情況來看，15:03第一次協(xié)商之后，福建分公司的防火墻IPSec處理正常，后續(xù)發(fā)送的ESP數據包序列號連續(xù)，可以確定兩地之間的互聯(lián)網鏈路也沒有問題。造成此次中斷的直接原因是15:03的第一次協(xié)商之后，總公司防火墻處理出現異常，沒有正確使用新的ESP SA通訊。
在18:05左右時段，我們又看到了相同的現象：第一次二階段協(xié)商后總公司防火墻不發(fā)送新的ESP數據，1分53秒后進行第二次二階段協(xié)商，48秒后總公司防火墻使用新的SA發(fā)送數據，這就是造成 2分41秒單向通訊的原因。
通過對比多次不同分公司VPN中斷時刻的數據，我們發(fā)現每次中斷的現象均一致，并且有些正常時段在雙方更新SA后，總公司的防火墻也會出現短時間不發(fā)送數據的情況，如果這一現象持續(xù)時間超過1分50秒，雙方就會重新開啟二階段協(xié)商，在這段時間內VPN處在中斷的狀態(tài)。
結論及建議
1、結論：
監(jiān)控鏈路的流量趨勢穩(wěn)定，沒有發(fā)現明顯的持續(xù)丟包或鏈路質量異常的現象，總公司與分公司之間使用聯(lián)通線路的VPN隧道短時間中斷現象與運營商的網絡鏈路無關;
造成異常中斷的直接原因是在周期性二階段協(xié)商之后，總公司的防火墻可能存在Bug或異常情況導致不能使用新的SA進行后續(xù)ESP通訊;
由于這一現象是在聯(lián)通線路擴容之后才出現的，可推斷是由于擴容后聯(lián)通線路流量增大，總公司防火墻上有上百個IPSec隧道，頻繁的密鑰更新增大了防火墻的負荷，導致其在刷新SA后相關進程出現延時或鎖死。
2、建議：
將捕獲數據包與我們分析的結論提交給防火墻廠商，請廠商協(xié)助處理;
在廠商沒有徹底解決相關問題期間，可以通過配置增大各隧道IPsec SA的生存時間，這樣可以降低密鑰更新的頻率減少對防火墻性能的壓力。
責任編輯：admin
某保險公司北京總公司與各地分公司均通過雙線與當地電信和聯(lián)通兩大互聯(lián)網運營商相連，各地分公司通過IPsec VPN接入總公司內部網絡。
由于業(yè)務量增加，對廣域網的帶寬需求加大，用戶對總公司的聯(lián)通接入線路進行了擴容。升級后總公司聯(lián)通線路的承載能力得到了提高，但各地分公司通過聯(lián)通網絡建立的VPN隧道經常會出現短時間的中斷，用戶懷疑是新升級的聯(lián)通互聯(lián)網線路存在問題，或運營商對其VPN通訊進行了限制或干擾，需要通過網絡協(xié)議分析查找造成中斷的具體原因。
環(huán)境描述
本次分析使用科來回溯分析系統(tǒng)1002T，在總公司的VPN服務器(一臺Juniper防火墻)外側部署，7×24小時捕獲并分析其VPN隧道ESP流量以及ISAKMP流量，部署拓撲示意圖1：
圖 1設備部署拓撲圖
1、流量趨勢分析
首先通過回溯分析系統(tǒng)的IP流量精細分析功能查看發(fā)生中斷的VPN對端IP地址175.44.133.172的11月13日下午14:30~18:30的流量趨勢。從趨勢圖上，并沒有發(fā)現明顯的長時間流量中斷，在發(fā)生問題的15:05和18:05左右也沒有出現流量為0的情況。于是進一步使用4分鐘窗口(1秒鐘精度)查看15:05和18:05左右的流量趨勢，發(fā)現在發(fā)生中斷的2min內，總公司防火墻前端能夠收到福建VPN對端的數據包，但是總公司的防火墻向對端發(fā)送的數據包卻很少。通過與正常時段的流量進行比對分析，正常時段VPN兩端發(fā)送的數據包量基本相當。
福建VPN 13日凌晨中斷，通過用戶提供的其他VPN隧道中斷時刻我們也看到了兩端數據包發(fā)送量差距巨大的現象。由此我們基本可以判斷發(fā)生中斷時刻，總公司和分公司之間的互聯(lián)網鏈路(聯(lián)通運營商網絡)沒有問題，很可能是由于總公司防火墻某段時間沒有發(fā)送數據導致VPN中斷。
2、數據包解碼分析
下載福建分公司VPN 175.44.133.172的11月13日下午的全部數據包進行解碼分析。
從數據包來看，當天下午雙方每小時會進行一次二階段協(xié)商來更換ESP密鑰，可推斷雙方的ESP SA生存時間為1小時，但15:03的二階段協(xié)商出現了意外情況。
在福建分公司175.44.133.172與總公司123.127.198.81之間通信的數據包中我們看到在發(fā)生中斷的15:03:58兩端防火墻使用UDP 500端口交互了3個報文。通過分析3個UDP 500端口的報文，發(fā)現偏移量為3C的字段值(Exchange type類型字段)均為”0x20”，表示這三個報文是ISAKMP二階段協(xié)商的報文，主要作用是協(xié)商新的ESP SA。這三個報文之后175.44.133.172發(fā)送的ESP報文使用了新的SPI(安全參數索引)，但總公司的防火墻并沒有使用新的SA發(fā)送數據，也沒有繼續(xù)使用以前的SA發(fā)送數據，可推斷是總公司防火墻自身的程序出現問題導致這一現象。1分51秒后，我們看到175.44.133.172再次向123.127.198.81發(fā)送了一個Exchange type字段為“0x05”(ISAKMP Information)的通知報文，然后雙方又交換了3個二階段協(xié)商報文，此次協(xié)商之后VPN兩端都使用了新的SPI進行ESP數據交互，后續(xù)通訊正常。
從上面這些情況來看，15:03第一次協(xié)商之后，福建分公司的防火墻IPSec處理正常，后續(xù)發(fā)送的ESP數據包序列號連續(xù)，可以確定兩地之間的互聯(lián)網鏈路也沒有問題。造成此次中斷的直接原因是15:03的第一次協(xié)商之后，總公司防火墻處理出現異常，沒有正確使用新的ESP SA通訊。
在18:05左右時段，我們又看到了相同的現象：第一次二階段協(xié)商后總公司防火墻不發(fā)送新的ESP數據，1分53秒后進行第二次二階段協(xié)商，48秒后總公司防火墻使用新的SA發(fā)送數據，這就是造成 2分41秒單向通訊的原因。
通過對比多次不同分公司VPN中斷時刻的數據，我們發(fā)現每次中斷的現象均一致，并且有些正常時段在雙方更新SA后，總公司的防火墻也會出現短時間不發(fā)送數據的情況，如果這一現象持續(xù)時間超過1分50秒，雙方就會重新開啟二階段協(xié)商，在這段時間內VPN處在中斷的狀態(tài)。
結論及建議
1、結論：
監(jiān)控鏈路的流量趨勢穩(wěn)定，沒有發(fā)現明顯的持續(xù)丟包或鏈路質量異常的現象，總公司與分公司之間使用聯(lián)通線路的VPN隧道短時間中斷現象與運營商的網絡鏈路無關;
造成異常中斷的直接原因是在周期性二階段協(xié)商之后，總公司的防火墻可能存在Bug或異常情況導致不能使用新的SA進行后續(xù)ESP通訊;
由于這一現象是在聯(lián)通線路擴容之后才出現的，可推斷是由于擴容后聯(lián)通線路流量增大，總公司防火墻上有上百個IPSec隧道，頻繁的密鑰更新增大了防火墻的負荷，導致其在刷新SA后相關進程出現延時或鎖死。
2、建議：
將捕獲數據包與我們分析的結論提交給防火墻廠商，請廠商協(xié)助處理;
在廠商沒有徹底解決相關問題期間，可以通過配置增大各隧道IPsec SA的生存時間，這樣可以降低密鑰更新的頻率減少對防火墻性能的壓力。
