不能說近期,準(zhǔn)確來說應(yīng)該是這兩年起,政策更注重網(wǎng)絡(luò)安全,直接表現(xiàn)是運(yùn)營商線路開始檢測并封殺標(biāo)準(zhǔn)的VPN協(xié)議:IPSEC、PPTP和L2TP。一般情況下是如何檢測和封殺的?如下:
- 偵測UDP 500和4500端口,過濾掉對應(yīng)的UDP流讓SA無法建立
- 偵測ESP加密封裝報(bào)文,中間鏈路直接攔截
- 偵測TCP 1723端口并封殺。端口用于 PPTP 控制消息的傳輸,像連接的建立、維護(hù)和終止等操作都通過該端口進(jìn)行通信
- 偵測UDP 1701端口并封殺。此端口用于建立L2TP的控制鏈路
今天便和大家分享一個案例,拓?fù)淙缦拢?/span>總部和A、B、C三個分支之間兩兩做IPSEC VPN隧道即:
問題描述:總部與A之間有SA(安全聯(lián)盟)但是內(nèi)網(wǎng)無法正常通信。而總部與B、C通信完全正常。
從直接的現(xiàn)象來看SA能正常建立,說明主模式/野蠻模式和快速模式的階段握手全部走完了的,UDP 500和UDP 4500大概率沒有被封,數(shù)據(jù)通信已經(jīng)走了ESP隧道加密封裝了
而總部和分支之間無法互訪,說明ESP封裝的數(shù)據(jù)報(bào)文大概是過不去的,所以基于這點(diǎn)抓取兩邊出口路由的WAN口報(bào)文比對即可;
在路由器的頁面中,可以看到IPSEC VPN的安全聯(lián)盟是已經(jīng)正常建立的,所以基本可以驗(yàn)證上述猜想:UDP 500和4500端口是允許放行的。
下一步直接抓WAN口報(bào)文,確認(rèn)ESP封裝的數(shù)據(jù)包是否有正常發(fā)出并被對方的WAN口接收。
第二步:對比手機(jī)和筆記本同時http拉取文件的情況監(jiān)控的接口分別為總部的出口路由器和A分支的出口路由WAN口:這邊是通過Tcpdump直接打印看的報(bào)文:
?A分支發(fā)出的MSS=800字節(jié)(最大數(shù)據(jù)長度)的報(bào)文經(jīng)過ESP封裝后得到的864字節(jié)包從A路由發(fā)出去了,但是總部的WAN口沒收到。說明中間鏈路丟包了。這邊分別測試了MSS=1000、1200的都是如此。
【問題總結(jié)和解決方案】
問題總結(jié):
運(yùn)營商線路封殺VPN相關(guān)的數(shù)據(jù)流
解決方案:
公眾文在此我不提供任何解決方案,僅提供你處理問題的排查思路。
閱讀原文:原文鏈接
該文章在 2025/5/7 17:58:21 編輯過