实战案例：不只是封杀，运营商还对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门店—IPCNVR—总部<——>B门店—IPCNVR—总部<——>C门店—IPC问题描述：总部和三个分支建立IPSEC VPN均正常，A、B门店的IPC网络摄像头上传到总部NVR的视频是正常的，但C门店特别卡顿。IPC的所需码流是2Mbps。
第一步：测试网络带宽
虽然分支是通过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，上下行能跑20MbpsPC1—总部<——>B门店—PCB，上下行能跑40MbpsPC1—总部<——>C门店—PCC，上下行只有1Mbps
答案显而易见了，运营商链路对IPSEC VPN流做了管控，这已经不是我遇到的第一例了，只不过现在才整个典型给你们看。
问题总结和解决方案问题总结：运营商线路对VPN相关的数据流做了QoS带宽控制。
解决方案：别问我，问就是：无解。
