實戰案例：運營商逐步封鎖 VPN

本期分享的案例是VPN的相關問題。



一、問題背景
不能說近期，準確地說應該是這兩年起，政策更注重網路安全，直接表現是營運商線路開始偵測並封鎖標準的VPN協定：IPSEC、PPTP和L2TP。一般情況下是如何檢測和封鎖的？如下：

IPSEC VPN：

偵測UDP 500和4500端口，過濾掉對應的UDP流讓SA無法建立
偵測ESP加密封裝報文，中間連結直接攔截
PPTP VPN：

偵測TCP 1723埠並封鎖。連接埠用於 PPTP 控制訊息的傳輸，像連接的建立、維護和終止等操作都透過該連

L2TP VPN：

偵測UDP 1701埠並封鎖。此連接埠用於建立L2TP的控制鏈路
今天便和大家分享一個案例，拓樸如下：

總部和A、B、C三個分支之間兩兩做IPSEC VPN隧道即：

總部<——>A分支
總部<——>B分支
總部<——>C分支
問題描述：總部與A之間有SA（安全聯盟）但是內網無法正常通訊。而總部與B、C通信完全正常。

二、排查思路
從直接的現象來看SA能正常建立，說明主模式/野蠻模式和快速模式的階段握手全部走完了的，UDP 500和UDP 4500大概率沒有被封，數據通信已經走了ESP隧道加密封裝了

而總部與分公司之間無法互訪，說明ESP封裝的資料封包大概是過不去的，所以基於這點抓取兩邊出口路由的WAN口報文比對即可；

三、基礎分析
第一步：檢查安全聯盟
在路由器的頁面中，可以看到IPSEC VPN的安全聯盟是已經正常建立的，所以基本上可以驗證上述猜想：UDP 500和4500連接埠是允許放行的。


下一步直接抓WAN口報文，確認ESP封裝的資料包是否有正常發出並被對方的WAN口接收。

步驟二：比較手機和筆記本同時http拉取文件的情況
監控的介面分別為總部的出口路由器和A分公司的出口路由WAN埠：


這邊是透過Tcpdump直接列印看的報文：

可以很顯性的看到：

A分支發出的MSS=800位元組（最大資料長度）的封包經過ESP封裝後得到的864位元組包從A路由發出去了，但是總部的WAN口沒收到。說明中間連結丟包了。這邊分別測試了MSS=1000、1200的都是如此。

四、問題總結與解決方案
問題總結：運營商線路封鎖VPN相關的資料流。

解決方案：公眾文在此我沒有提供任何解決方案，僅提供你處理問題的檢驗思路。