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