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

問題背景

不能說近期，準確來說應該是這兩年起，政策更注重網(wǎng)絡安全，直接表現(xiàn)是運營商線路開始檢測并封殺標準的VPN協(xié)議：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網(wǎng)絡攝像頭上傳到總部NVR的視頻是正常的，但C門店特別卡頓。IPC的所需碼流是2Mbps。

排查思路

• 考慮IPC主要走上行帶寬，所以需要測速；
• 對比正常門店出口的視頻流報文和異常門店出口的區(qū)別；

基礎分析

第一步：測試網(wǎng)絡帶寬

雖然分支是通過VPN封裝傳給總部的，一般情況下直接取決于上行帶寬，所以在異常門店使用speedtest測個速：

上行/下行=118M/217M，這跑個IPC的視頻流2Mbps不是綽綽有余嗎？為啥卡的要死？

第二步：對比正常門店和異常門店的IPC數(shù)據(jù)流

監(jiān)控的接口是IPC上聯(lián)口，如下：

監(jiān)控正常A、B門店可以看到TCP視頻流是很絲滑基本無丟包、錯序的：

而異常C門店，TCP流大量的錯序、丟包重傳（黑漆漆一片）

統(tǒng)計下吞吐量，發(fā)現(xiàn)正常A、B門店的視頻流是可以平滑的達到2Mbps的，而異常的C門店達到0.6Mbps就上不去了：

所以，為什么C異常門店的上行帶寬能到118Mbps，但是通過VPN回傳到總部卻連2Mbps都打不到呢？答案呼之欲出了，前端線路對于VPN這種協(xié)議流做了Qos帶寬控制。

第三步：總部和分店跑吞吐量進一步確認

為了進一步確認總分之間的吞吐量，便在總分下用兩臺PC直接跑iperf3測速，拓撲和結果如下：

• PC1—總部<——>A門店—PCA，上下行能跑20Mbps
• PC1—總部<——>B門店—PCB，上下行能跑40Mbps
• PC1—總部<——>C門店—PCC，上下行只有1Mbps

答案顯而易見了，運營商鏈路對IPSEC VPN流做了管控，這已經(jīng)不是我遇到的第一例了，只不過現(xiàn)在才整個典型給你們看。

問題總結和解決方案

問題總結：運營商線路對VPN相關的數(shù)據(jù)流做了QoS帶寬控制。

解決方案：別問我，問就是：無解。