隧道通不等于业务通
VPN 排障最大的误区是看到隧道 Up 就认为业务应该通。IPsec/SSL VPN 的故障点分布在多个独立阶段：IKE 协商、隧道建立、感兴趣流匹配、路由引入、MTU 与分片、NAT 穿越。每个阶段失败都会表现为「不通」，但处置动作完全不同。正确的做法是按阶段逐段验证，每一步都拿到证据再往下走。
基本信息
| 关键阶段 | IKE Phase1 → Phase2 → 隧道接口互通 → 路由与感兴趣流 → MTU → 业务端口 |
|---|---|
| 关键端口 | UDP 500（IKE）、UDP 4500（NAT-T）、协议 50（ESP） |
| 协议依据 | RFC 7296（IKEv2）、RFC 3948（NAT-T 封装） |
| MTU 建议 | 隧道接口 MTU 下调（常见 1400 以下）并启用 MSS clamping |
| 适用设备 | 华为 VRP、思科 IOS、Linux strongSwan/libreswan、各类防火墙 |
按阶段排查
- ① 隧道状态：IKE Phase1/Phase2 是否建立，用设备命令或日志确认
- ② 隧道内互通：两端隧道接口地址互 ping，验证封装与解封装正常
- ③ 路由与感兴趣流：确认业务网段被引入隧道，ACL 或感兴趣流匹配
- ④ MTU：隧道内大包测试，逐步减小包长找到可通尺寸
- ⑤ 业务端口：nc -zv 目标地址端口，确认是网络还是服务问题
- ⑥ 日志：IKE 调试与 DPD（对端存活检测）日志是最终判据
隧道内 MTU 探测与抓包
隧道内 MTU 探测与抓包
# MTU 探测：1400 + 28 字节头部 = 1428，逐步减小到能通为止
ping -M do -s 1400 -c 3 <对端隧道地址>
ip link show tun0 # 查看隧道接口 MTU 实际值
# IPsec 常见建议：隧道接口 MTU 下调到 1400 以下，并启用 MSS clamping
sudo tcpdump -i eth0 -nn 'udp port 500 or udp port 4500 or esp' -c 20 # 在物理出口抓封装流量
sudo ip xfrm state | head -20 # strongSwan/libreswan 环境下查看 IPsec 状态阶段与验证手段
| 阶段 | 验证手段 | 失败表现 |
|---|---|---|
| IKE 协商 | 设备日志、抓 UDP 500/4500 | 隧道起不来，配置看起来都正常 |
| 隧道建立 | 查看隧道接口与 SA 状态 | Phase2 反复协商失败 |
| 隧道内互通 | 两端隧道地址互 ping | 隧道 Up 但隧道内地址不通 |
| 路由与感兴趣流 | 核对路由表与 ACL 匹配计数 | 隧道内能 ping，业务网段不通 |
| MTU 与分片 | ping -M do 逐步调整包长 | 小包通、大包失败，表现为握手成功但传输卡死 |
| 业务端口 | nc -zv 业务地址端口 | 网络通但服务未监听或被拦 |
NAT 后的 IPsec 依赖 NAT-T（UDP 4500）；如果 500 或 4500 被中间设备拦截，表现就是「配置都没问题但隧道建不起来」。