IPSec VPN 能连上却不通？从协商到策略的逐层排查实战
很多工程师遇到 IPSec VPN 时都有这样的困惑：隧道状态显示『已建立』，可业务系统就是 ping 不通、连不上。问题往往不在加密算法本身，而在感兴趣流、NAT 穿越、路由回包或 MTU 分片。本文按分层思路带你逐一排查，定位真正断点。
一、确认阶段一与阶段二是否真的协商成功
不要只看界面上的『连接』字样，要用命令行看真实状态。
- 在路由器或防火墙执行 show crypto isakmp sa（或 ipsec sa），状态应为 QM_IDLE 而非 MM_xxxx，后者说明阶段一卡在野蛮模式。
- 执行 show crypto ipsec sa，确认入向/出向 SPI 已生成，且 encap/decap 计数在增长。若计数不增长，说明流量没命中策略。
- 查看系统日志里是否有 NO_PROPOSAL_CHOSEN 或 INVALID_ID_INFORMATION，这类报错几乎都指向两端策略不匹配。
二、检查感兴趣流是否对称
两端 ACL（或 traffic selector）必须互为镜像，且掩码一致。
- 核对本地子网与对端子网是否写反，常见错误是把源和目的对称写成了完全相等。
- 确认协议与端口是否一致：一端写 ip 任意，另一端写 tcp/443，这种不对称会让协商直接失败。
- 若使用 VTI 或路由型隧道，确认已用 ip route 把流量引到 tunnel 接口，而不是依赖 ACL 触发。
三、排查 NAT 穿越与 NAT-T
- 若 VPN 设备背后还有一层 NAT（如光猫），务必开启 NAT-T（UDP 4500），否则 ESP 报文会被上层 NAT 丢弃。
- 检查中间防火墙是否放通 UDP 500 与 UDP 4500，很多企业只开 500 导致能协商第一阶段却建不起第二阶段。
- 确认两端 NAT 探测一致，一端开一端关会造成 端口浮动不一致。
四、确认路由与回包路径
- 在服务器侧用 tracert / traceroute 确认回包走的是 VPN 隧道而非默认网关。
- 检查对端是否有到达你方子网的回指路由，缺回程路由是『能连不通』的头号原因。
- 若本地有多出口，确认策略路由把 VPN 流量固定到正确出接口。
五、MTU 与分片问题
- IPSec 封装会增加 50–80 字节开销，把接口 MTU 降到 1400 并设 tcp adjust-mss 1360 试试。
- 用 ping -f -l 1400 对端IP 测不分片最大包，逐步减小定位分片丢弃点。
技术总结：IPSec『能连不通』八成出在策略不对称、缺回程路由或 NAT-T 没开。先做 show 看 SPI 计数，再核对感兴趣流与路由，最后调 MTU，基本都能定位。