实战案例：运营商逐步封杀 VPN

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

一、问题背景

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

IPSEC VPN：

侦测UDP 500和4500端口，过滤掉对应的UDP流让SA无法建立侦测ESP加密封装报文，中间链路直接拦截

PPTP VPN：

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

L2TP VPN：

侦测UDP 1701端口并封杀。此端口用于建立L2TP的控制链路

今天便和大家分享一个案例，拓扑如下：

总部和A、B、C三个分支之间两两做IPSEC VPN隧道即：

总部<——>A分支总部<——>B分支总部<——>C分支

问题描述：总部与A之间有SA（安全联盟）但是内网无法正常通信。而总部与B、C通信完全正常。

二、排查思路

从直接的现象来看SA能正常建立，说明主模式/野蛮模式和快速模式的阶段握手全部走完了的，UDP 500和UDP 4500大概率没有被封，数据通信已经走了ESP隧道加密封装了

而总部和分支之间无法互访，说明ESP封装的数据报文大概是过不去的，所以基于这点抓取两边出口路由的WAN口报文比对即可；

三、基础分析

第一步：检查安全联盟

在路由器的页面中，可以看到IPSEC VPN的安全联盟是已经正常建立的，所以基本可以验证上述猜想：UDP 500和4500端口是允许放行的。

下一步直接抓WAN口报文，确认ESP封装的数据包是否有正常发出并被对方的WAN口接收。

第二步：对比手机和笔记本同时http拉取文件的情况

监控的接口分别为总部的出口路由器和A分支的出口路由WAN口：

这边是通过Tcpdump直接打印看的报文：

可以很显性的看到：

A分支发出的MSS=800字节（最大数据长度）的报文经过ESP封装后得到的864字节包从A路由发出去了，但是总部的WAN口没收到。说明中间链路丢包了。这边分别测试了MSS=1000、1200的都是如此。

四、问题总结和解决方案

问题总结：运营商线路封杀VPN相关的数据流。

解决方案：公众文在此我不提供任何解决方案，仅提供你处理问题的排查思路。