不少用户在部署IPsec VPN的过程中，经常遇到隧道反复协商失败、连通后业务丢包严重、大文件传输直接中断等问题，多数情况下这些故障并非加密策略配置错误，而是底层网络环境没有满足协议的前置要求。本文从实际故障排查的视角出发，飞机VPN逐项拆解配置IPsec VPN所需的网络环境要求，帮你提前规避大部分常见的连接异常问题。
公网连通性与NAT穿越的基础要求
配置IPsec VPN的第一环境前提，就是两端的VPN网关必须具备可互相抵达的公网路由，不能两端都完全隐藏在运营商的多层级NAT之后，这种场景下标准IPsec协议没有适配方案，后续所有协商报文都无法找到正确的转发路径。如果是总部-分支的典型部署场景，飞机VPN至少其中一端的VPN网关需要分配可被公网直接路由的公网IP，另一端哪怕处于私网NAT之后也可以正常发起协商。
排查这一项要求时，不要用两端内网的业务主机去ping对端地址，必须登录到VPN网关的命令行界面，直接用网关的公网出接口地址去ping对端的VPN公网地址，预期结果是能收到完整的ICMP回复，飞机不存在100%丢包的情况。如果完全无法ping通，首先要排查本地网关的默认路由配置是否正确，再确认沿途运营商没有拦截到对端公网地址的路由。
如果某一端或者两端的VPN网关都处于第三方NAT设备之后，必须确认中间所有网络节点都没有拦截UDP 500、UDP 4500端口的报文。IPsec的IKE第一阶段协商默认使用UDP 500端口，触发NAT穿越机制之后，所有封装后的VPN报文都会切换到UDP 4500端口传输，只要其中任意一个端口被拦截，协商流程就会中途直接中断。
运维人员在企业机房内操作VPN网关，排查IPsec VPN部署所需的公网连通性条件
IPsec专属协议报文的放行规则要求
很多企业的边界防火墙默认只会放行TCP、UDP类的常见业务协议，会直接拦截ESP和AH这两个IPsec专属的网络层协议，这两类协议不属于常见的传输层协议，没有对应端口号，协议号分别为50和51，哪怕你放通了所有UDP端口，没有单独配置这两个协议的放行规则，封装后的IPsec报文到了边界就会被直接丢弃。
排查这一项要求时，可以在VPN网关的出口镜像端口开启抓包，确认IKE协商完成之后，本地网关发出去的ESP报文是否能正常出现在公网链路上。如果本地已经发出完整的ESP报文，但对端VPN网关完全收不到对应报文，首先要回溯沿途所有安全设备的访问控制规则，确认ESP协议没有被拦截，不要上来就反复调整IKE的加密算法浪费排查时间。
这里的常见误区是很多用户以为只需要放通两端加密后的私网业务流量权限，忘了IPsec协商本身的源地址是VPN网关的公网接口IP，所以两端的边界防火墙都要给对端的VPN公网IP开放IKE协商、ESP/AH协议的访问权限，不能只针对加密后的私网网段配置放行规则。
两端私网地址段无重叠的硬性要求
这是很多新手部署IPsec VPN时最容易忽略的网络环境要求，IPsec VPN的核心作用是打通两端互相隔离的私网，如果两端本地的私网网段完全重叠，比如总部和分支都使用192.168.1.0/24作为办公网段，加密后的路由转发会出现逻辑冲突，报文根本无法判断该往本地私网转发还是往VPN隧道转发，哪怕隧道协商完全成功也没法正常传输业务数据。
排查这一项要求时，要分别导出两端VPN网关的所有内网直连网段、静态路由发布的网段，做完整的交叉比对，如果发现有地址段重叠的部分，要么修改其中一端的私网网段配置，要么在VPN网关侧配置NAT转换规则，把重叠的网段映射成不冲突的过渡地址段，没有其他捷径可以绕过这个限制。
中间网络的分片与MTU适配要求
不少用户遇到的典型故障是IPsec隧道协商完全正常，小体积的数据包传输没有任何问题，但是传输大文件或者大数据包的时候直接卡顿丢包，这类问题本质是中间网络的MTU值没有适配IPsec封装之后的额外开销。普通的IP报文封装ESP协议之后会多出额外的报头开销，如果不做适配，超过链路MTU的大体积报文会被中间的网络设备直接丢弃。
排查这一项要求时，可以在隧道连通之后，用不同大小的ICMP报文测试两端私网的连通性，飞机如果小包可以正常通、大包直接丢包，就需要在VPN网关的隧道接口下调整TCP MSS的数值，适配封装后的链路MTU，不需要去修改沿途所有网络设备的配置。
很多人配置IPsec VPN的时候一开始就盯着加密算法、预共享密钥这些策略项反复调试，却忽略了底层网络环境的前置要求，按照上述步骤逐项排查完环境要求之后，大部分隧道协商失败、业务不通的问题都能快速定位解决，不需要耗费大量时间在调试加密策略上。
