很多企业在上线IPsec VPN后频繁出现隧道闪断、两端子网无法互访、加密协商失败等问题，超过七成的这类上线初期故障都可以通过部署前的前置检查提前规避，本文就围绕IPsec VPN部署前的准备工作，从实际运维排查的角度梳理所有必须落地的校验项，帮技术人员提前扫清潜在障碍。
两端网络连通性与端口前置校验
很多运维人员上来就直接配置IPsec VPN的加密策略，完全跳过了底层公网连通性的检查，最后排查半天才发现两端公网IP本身就无法互通。首先要做的第一步就是从VPN两端的网关设备上，直接对ping对端的公网接口IP，而不是用内网终端测试，避免中间三层设备的转发规则干扰测试结果。
运维人员在IPsec VPN配置前先完成两端公网连通性与开放端口的前置校验，从根源规避上线后隧道异常故障
这个测试的预期结果是两端公网地址的ICMP报文可以正常往返，如果出现丢包或者完全不通，首先要排查两端的运营商线路是否存在公网IP私网化的情况，或者中间的安全网关已经默认拦截了对端的访问流量，先把底层连通性打通再进行后续配置。同时还要确认两端的UDP 500、UDP 4500端口没有被运营商或者中间防火墙拦截，这两个是IPsec协商的默认端口，一旦拦截IKE第一阶段协商会直接失败。
两端设备配置资源与策略边界排查
很多中小站点的网关设备本身已经跑满了会话数或者加密引擎的资源，部署IPsec VPN之后直接出现原有业务卡顿的现象，这也是部署前必须排查的项。首先要登录两端的VPN网关设备，查看当前的加密资源占用、并发会话数上限，确认剩余资源可以支撑规划的IPsec隧道数量和预期的加密流量规模。
接下来要梳理两端设备现有的访问控制策略，确认没有提前配置拦截ESP协议的规则，IPsec的封装报文除了UDP协商端口之外，ESP协议号50的报文也需要放行，很多运维人员只放通了两个UDP端口，忘记放通协议类型，导致第二阶段协商成功之后数据报文直接被丢弃。同时还要确认两端设备现有的NAT策略，不要把IPsec隧道需要转发的私网流量做了公网地址转换，否则对端收到的源地址会不符合预定义的感兴趣流规则，直接丢弃报文。
感兴趣流与子网路由的一致性校验
IPsec VPN最常见的上线故障就是两端感兴趣流配置不匹配，很多时候一端写的是本地全端子网，另一端漏写了其中的某个业务网段，导致部分业务无法互访。部署前的准备阶段就要把两端需要加密传输的所有私网网段全部梳理成表格，逐行核对两端的感兴趣流规则的镜像关系，不能出现单边多写或者漏写的情况。
校验完感兴趣流之后还要确认两端的路由配置，本地VPN网关必须存在指向对端私网网段的路由，下一跳指向隧道出接口方向，不能把去往对端私网的流量通过默认路由转发到其他出口，否则加密流量根本不会被送入IPsec隧道处理。这里的常见误区是很多运维人员以为配置完感兴趣流设备就会自动生成对应路由，实际上大部分厂商的IPsec实现都需要手动配置指向对端子网的静态路由，轻舟否则流量转发路径完全错误。
加密策略参数的预对齐校验
IKE第一阶段和第二阶段的加密算法、认证算法、协商模式、密钥生存时间这些参数，只要有一端配置不一致，协商过程就会直接中断，很多运维人员部署前没有提前对齐参数，反复调试几个小时都无法建立隧道。准备阶段就要把所有协商参数整理成核对清单，两端逐一确认，比如确认主模式还是野蛮模式的选择，预共享密钥两端完全一致，不要出现大小写字符的差异。
还要提前确认两端设备的NAT穿越功能是否同时开启，如果其中一端网关处于NAT环境下，必须开启NAT穿越才能让封装后的IPsec报文正常穿过中间NAT设备。另外如果规划的是多条IPsec隧道共存，轻舟VPN官网还要提前确认不同隧道的感兴趣流没有出现重叠冲突的情况，避免设备将不同业务的流量错误送入不对应的隧道。
所有这些部署前的准备校验全部完成之后，再开始进行IPsec VPN的正式配置，上线之后的故障概率会大幅降低，就算出现协商失败的问题，也可以对照之前的校验清单逐项回查，快速定位故障点，不需要再逐行排查所有配置项，大幅提升部署效率。
