首页/网络/网络排障速查/VPN 故障排查要点(隧道通≠业务通)
排查流程与方法36 条

VPN 故障排查要点(隧道通≠业务通)

VPN 建得起来不等于业务通:MTU/分片、路由未引入、加密套件协商、NAT-T 端口(4500)都是高频问题,按「阶段」逐段验证。

网络排障速查网络更新于 2026-10-12
  • ① 隧道状态:IKE Phase1/Phase2 是否建立(设备命令或日志)
  • ② 隧道内 ping:两端隧道接口地址互 ping
  • ③ 路由:两端是否把业务网段引入隧道(感兴趣流/ACL 匹配)
  • ④ MTU:隧道内大包测试(ping -M do)
  • ⑤ 业务端口:nc -zv 业务地址端口
  • ⑥ 日志:IKE 调试与 DPD(对端存活检测)日志

隧道内 MTU 探测(Linux)

隧道内 MTU 探测(Linux)
ping -M do -s 1400 -c 3 <对端隧道地址>   # 1400+28=1428,逐步减到通为止
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
NAT 后的 IPsec 依赖 NAT-T(端口 4500);若 500/4500 被中间设备拦,表现为「配置都没问题就是建不起来」。

易错点

  • 只看隧道 Up 就认为业务应该通,忽略路由与感兴趣流(ACL)匹配
  • 隧道内业务卡顿先怀疑带宽,多数其实是 MTU 与分片问题

数据来源与参考

  • RFC 7296:IKEv2
  • RFC 3948:UDP Encapsulation of IPsec ESP(NAT-T)

相关工具

​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌