很多企业在搭建跨地域分支互联、远程办公安全接入的网络体系时，都会优先选择IPsec VPN作为加密传输方案，但不少运维人员部署前只关注两端网关的参数匹配，忽略了基础网络环境的前置校验，导致后续配置反复报错、隧道频繁断开，甚至核心业务数据传输异常，本文就从实际部署的全流程梳理IPsec VPN必须满足的各类网络环境要求，帮大家提前排查隐患，减少部署后的故障概率。
公网链路的基础连通性要求
不管是总部端还是分支端的IPsec VPN网关，都必须至少有一个可被对端访问的公网接口，不能两端都完全藏在运营商级别的NAT网络后面且没有任何端口映射配置，这种场景下如果没有专用的中继服务支持，是无法主动发起隧道连接的。
很多新手容易踩的误区是只测试网关能不能ping通对方的公网地址，忽略了上层网络有没有拦截IPsec协议对应的相关报文，比如UDP 500、UDP 4500端口的协商报文，还有ESP协议的50号协议报文，如果运营商或者上层防火墙拦截了这些类型的报文，哪怕三层网络完全连通，也没法正常协商生成安全联盟。
NAT网络的适配规则要求
不少中小分支的出口网关本身就在家庭宽带或者下级运营商的NAT地址池后面，这种场景下要正常运行IPsec VPN，必须要求两端的NAT设备支持标准的NAT-T穿透功能，且不能对ESP封装后的UDP报文做端口限制，也不能把这类会话的老化时间设置得过短。
这里的常见误区是很多运维直接把IPsec VPN的网关放在已经做了一次源NAT的出口后面，又没有在前端网关做好对应公网端口的映射配置，导致分支侧发起的协商报文到了总部侧直接被丢弃，隧道完全无法建立，排查很久也找不到配置层面的问题。
内网路由的可达性要求
IPsec VPN配置里加密域规则定义的两端私网网段，不能存在地址重叠的情况，比如总部私网用了192.168.1.0/24，分支侧的办公内网也用了完全相同的网段，就算隧道协商成功，两端的业务流量也没法正常路由转发，会出现隧道状态显示正常但内网服务器互访完全不通的问题。
另外还要保证两端IPsec VPN网关的路由表里面，都存在指向对端加密私网网段的静态或者动态路由，下一跳指向本地的内网转发接口，不能把加密私网的流量默认路由到公网接口直接转发，否则相关流量不会进入IPsec的加密处理流程，自然也没法通过隧道传输。
串接安全设备的放行规则要求
很多企业总部的出口除了IPsec VPN网关，还部署了下一代防火墙、入侵防御系统等安全设备，这些串接在公网和VPN网关之间的设备，必须提前放通两端IPsec协商和加密传输的所有相关报文，不能对ESP、AH协议报文做深度检测或者直接拦截。
这里容易被忽略的点是部分企业的安全设备默认开启了分片报文拦截规则，而IPsec加密后的报文封装后长度很容易超过公网链路的标准MTU值，这类报文被拦截后就会出现小体积文件传输正常、大体积文件或者高清视频会议流量直接中断的异常故障，部署前要提前调整对应接口的MTU值，或者关闭不必要的分片报文拦截规则。
实际故障定位过程中，运维人员可以先在两端网关的公网侧开启报文捕获功能，确认协商报文能正常收发，再逐步排查私网路由和安全策略规则，不要一上来就反复调整IPsec的加密算法、密钥有效期这类参数，很多时候配置本身没有问题，就是前期网络环境没达标导致的故障。
不少刚接触IPsec VPN的技术人员会觉得，部署的核心重点是加密算法、预共享密钥、SA生命周期这类参数的两端完全匹配，但实际上七成以上的部署初期故障都来自前期网络环境不符合要求，提前把这些环境项逐一排查确认，能大幅降低部署的时间成本，也能避免后续隧道长期运行过程中出现莫名的断连问题。
