HQY 一个和谐有爱的空间

本期分享的案例是VPN的相关问题。

【问题背景】

不能说近期，准确来说应该是这两年起，政策更注重网络安全，直接表现是运营商线路开始检测并封杀标准的VPN协议：IPSEC、PPTP和L2TP。一般情况下是如何检测和封杀的？如下：

IPSEC VPN：

侦测UDP 500和4500端口，过滤掉对应的UDP流让SA无法建立

侦测ESP加密封装报文，中间链路直接拦截

PPTP VPN：

侦测TCP 1723端口并封杀。端口用于 PPTP 控制消息的传输，像连接的建立、维护和终止等操作都通过该端口进行通信

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带宽控制。

解决方案：

别问我，问就是：不花钱买互联网专线的话是 无解。  

推荐本站淘宝优惠价购买喜欢的宝贝:

本文链接：https://www.hqyman.cn/post/11614.html 非本站原创文章欢迎转载，原创文章需保留本站地址！

休息一下~~