不少企业运维人员在配置IPsec VPN时经常遇到连接失败的问题，不知道故障点出在协商的哪个环节，本文把IPsec VPN连接建立过程拆解成可逐段校验的运行步骤，结合故障排查的思路说明每个阶段的预期结果和常见误区，帮使用者快速定位连接异常的根因。
第一阶段：IKE SA协商前的基础连通性预检查
很多新手调试IPsec VPN时上来就核对加密配置，反而忽略了最基础的公网连通性校验，你首先需要从分支VPN网关侧，直接ping对端总部VPN网关的公网接口地址，确认双向公网路由可达，没有运营商链路中断或者中间防火墙拦截基础访问的情况。这个步骤的预期结果是两端公网地址可以正常互访，没有持续性丢包或者完全不通的现象。
接下来要确认两端的网络路径没有封禁IPsec协商必需的端口，IPsec默认协商使用UDP 500端口，开启NAT穿越后还需要用到UDP 4500端口，如果中间的运营商防火墙或者出口安全设备拦截了这两个端口的报文，后续所有协商动作都没法正常触发。很多人习惯用TCP端口测试连通性，很容易漏掉UDP端口的放行规则，这是非常高频的低级配置失误。
调试IPsec VPN前优先完成公网连通性与协商端口的预校验
第二阶段：IKE SA正式协商的报文交互校验
完成预检查之后就进入IPsec VPN连接建立过程的第一个核心协商环节，也就是IKE安全联盟的生成阶段，主模式场景下两端网关会通过6个UDP报文的来回交互，同步协商匹配加密算法、哈希算法、DH组参数，同时完成身份认证动作。
排查这个阶段的故障时，如果抓包能看到前两个协商报文正常收发，后续报文没有回应，大概率是两端配置的IKE提议集不匹配，比如一端启用了AES-256加密算法，另一端的IKE提议列表里根本没有加入对应算法，shadowrocket协商流程就会直接卡在参数匹配环节，没法往下推进。
这个阶段还有个常见故障点是身份认证信息不匹配，不管是用预共享密钥认证还是数字证书认证，只要两端的密钥字符串有一个字符输入错误，或者证书的有效期、签发机构信息不对应，协商到身份校验环节就会直接被拒绝，设备日志里会明确弹出认证失败的告警提示。正常完成这个阶段的所有交互后，设备的VPN状态列表里会生成活跃的IKE SA条目。
第三阶段：IPsec SA策略协商与生成校验
IKE SA成功建立之后，就进入IPsec VPN连接建立过程的第二阶段协商，两端会基于已经通过加密保护的IKE隧道，同步需要加密传输的感兴趣流规则，以及IPsec封装层的加密、校验、PFS特性参数。
如果排查时发现IKE SA已经处于活跃状态，但IPsec SA始终生成失败，首先要核对两端的感兴趣流规则是否完全镜像，比如总部端配置的加密网段是192.168.1.0/24访问分支192.168.2.0/24，分支端的感兴趣流必须是反向的对应网段组合，只要任意一端多写了无关网段、漏写了对应网段，或者两端网段范围不匹配，第二阶段协商就会直接失败。
另外还要核对两端的PFS特性配置是否一致，要是一端开启了PFS密钥前向保密功能，另一端没有开启对应配置，shadowrocket第二阶段的参数匹配环节也会直接报错。这个阶段协商完成后，VPN设备上会生成两个方向独立的IPsec SA条目，分别对应加密报文的发送和接收处理。
第四阶段：隧道连通性验证与故障收尾排查
IPsec SA条目正常生成之后，整个IPsec VPN连接建立过程的核心流程就已经全部走完，小火箭共享账号网站接下来需要从两端的内网业务主机发起跨网段访问测试，验证加密隧道是否可以正常转发业务流量。
如果IPsec SA状态正常但内网业务还是不通，就要排查两端内网的路由配置，确保分支端的内网回程路由指向本地VPN网关，总部端的对应网段回程路由也指向VPN隧道接口，避免业务流量被路由到其他公网出口，没有进入IPsec封装处理流程。
如果确认所有配置都匹配，还是看不到加密报文的转发统计，可以尝试开启两端的NAT穿越功能，小火箭共享账号网站部分运营商的中间安全设备会拦截原生的ESP协议报文，启用NAT穿越之后所有封装报文都会通过UDP 4500端口转发，就能绕过这类拦截规则。日常运维时建议长期开启VPN设备的协商日志功能，后续遇到连接失败的场景可以直接根据日志提示的阶段快速定位问题，不用逐行核对所有配置，大幅降低故障排查的耗时。
