本期分享的案例是VPN的相關(guān)問題。

問題背景

不能說近期，準(zhǔn)確來說應(yīng)該是這兩年起，政策更注重網(wǎng)絡(luò)安全，直接表現(xiàn)是運(yùn)營商線路開始檢測(cè)并封殺標(biāo)準(zhǔn)的VPN協(xié)議：IPSEC、PPTP和L2TP。一般情況下是如何檢測(cè)和封殺的？如下：

(1) IPSEC VPN：

• 偵測(cè)UDP 500和4500端口，過濾掉對(duì)應(yīng)的UDP流讓SA無法建立
• 偵測(cè)ESP加密封裝報(bào)文，中間鏈路直接攔截

(2) PPTP VPN：

偵測(cè)TCP 1723端口并封殺。端口用于 PPTP 控制消息的傳輸，像連接的建立、維護(hù)和終止等操作都通過該端口進(jìn)行通信

(3) L2TP VPN：

偵測(cè)UDP 1701端口并封殺。此端口用于建立L2TP的控制鏈路

當(dāng)然了，這邊還遇到了一種情況是：鏈路沒有封殺VPN，但是對(duì)其做了流量控制，也就是Qos

今天便和大家分享一個(gè)案例，拓?fù)淙缦拢?/p>

某奶茶店總部和A、B、C三個(gè)分支門店之間兩兩做IPSEC VPN隧道即：

• NVR—總部<——>A門店—IPC
• NVR—總部<——>B門店—IPC
• NVR—總部<——>C門店—IPC

問題描述：總部和三個(gè)分支建立IPSEC VPN均正常，A、B門店的IPC網(wǎng)絡(luò)攝像頭上傳到總部NVR的視頻是正常的，但C門店特別卡頓。IPC的所需碼流是2Mbps。

排查思路

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

基礎(chǔ)分析

第一步：測(cè)試網(wǎng)絡(luò)帶寬

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

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

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

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

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

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

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

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

第三步：總部和分店跑吞吐量進(jìn)一步確認(rèn)

為了進(jìn)一步確認(rèn)總分之間的吞吐量，便在總分下用兩臺(tái)PC直接跑iperf3測(cè)速，拓?fù)浜徒Y(jié)果如下：

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

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

問題總結(jié)和解決方案

問題總結(jié)：運(yùn)營商線路對(duì)VPN相關(guān)的數(shù)據(jù)流做了QoS帶寬控制。

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