實戰案例：不只是封殺，運營商還對VPN做了流量控制
本期分享的案例是VPN的相關問題。
問題背景
不能說近期，準確來說應該是這兩年起，政策更注重網絡安全，直接表現是運營商線路開始檢測并封殺標準的VPN協議：IPSEC、PPTP和L2TP。一般情況下是如何檢測和封殺的？如下：
(1) IPSEC VPN：
- 偵測UDP 500和4500端口，過濾掉對應的UDP流讓SA無法建立
- 偵測ESP加密封裝報文，中間鏈路直接攔截
(2) PPTP VPN：
偵測TCP 1723端口并封殺。端口用于 PPTP 控制消息的傳輸，像連接的建立、維護和終止等操作都通過該端口進行通信
(3) L2TP VPN：
偵測UDP 1701端口并封殺。此端口用于建立L2TP的控制鏈路
當然了，這邊還遇到了一種情況是：鏈路沒有封殺VPN，但是對其做了流量控制，也就是Qos
今天便和大家分享一個案例，拓撲如下：
某奶茶店總部和A、B、C三個分支門店之間兩兩做IPSEC VPN隧道即：
- NVR—總部<——>A門店—IPC
- NVR—總部<——>B門店—IPC
- NVR—總部<——>C門店—IPC
問題描述：總部和三個分支建立IPSEC VPN均正常，A、B門店的IPC網絡攝像頭上傳到總部NVR的視頻是正常的，但C門店特別卡頓。IPC的所需碼流是2Mbps。
排查思路
- 考慮IPC主要走上行帶寬，所以需要測速；
- 對比正常門店出口的視頻流報文和異常門店出口的區別；
基礎分析
第一步：測試網絡帶寬
雖然分支是通過VPN封裝傳給總部的，一般情況下直接取決于上行帶寬，所以在異常門店使用speedtest測個速：
上行/下行=118M/217M，這跑個IPC的視頻流2Mbps不是綽綽有余嗎？為啥卡的要死？
第二步：對比正常門店和異常門店的IPC數據流
監控的接口是IPC上聯口，如下：
監控正常A、B門店可以看到TCP視頻流是很絲滑基本無丟包、錯序的：
而異常C門店，TCP流大量的錯序、丟包重傳（黑漆漆一片）
統計下吞吐量，發現正常A、B門店的視頻流是可以平滑的達到2Mbps的，而異常的C門店達到0.6Mbps就上不去了：
所以，為什么C異常門店的上行帶寬能到118Mbps，但是通過VPN回傳到總部卻連2Mbps都打不到呢？答案呼之欲出了，前端線路對于VPN這種協議流做了Qos帶寬控制。
第三步：總部和分店跑吞吐量進一步確認
為了進一步確認總分之間的吞吐量，便在總分下用兩臺PC直接跑iperf3測速，拓撲和結果如下：
- PC1—總部<——>A門店—PCA，上下行能跑20Mbps
- PC1—總部<——>B門店—PCB，上下行能跑40Mbps
- PC1—總部<——>C門店—PCC，上下行只有1Mbps
答案顯而易見了，運營商鏈路對IPSEC VPN流做了管控，這已經不是我遇到的第一例了，只不過現在才整個典型給你們看。
問題總結和解決方案
問題總結：運營商線路對VPN相關的數據流做了QoS帶寬控制。
解決方案：別問我，問就是：無解。
