IPsec 需要放行什么
隧道不通时，把怀疑顺序倒过来会更快：先确认沿途有没有放行。IPsec 在网络上留下三类流量：UDP 500 承载初始 IKE 协商，UDP 4500 承载 NAT 穿越（NAT-T）封装以及 NAT 存在时的协商，协议 50 的 ESP 承载真正的业务数据。如果用了 AH 还会出现协议 51，不过只做加密的场景一般不需要。很多防火墙默认放行 UDP 500 却拦掉协议 50，结果是阶段一能建成、业务流量黑洞，这种「协商成功但 ping 不通」的现象几乎都指向数据面被拦。
基本信息
| UDP 500 | IKE 协商初始通道，双向 |
|---|---|
| UDP 4500 | NAT-T 封装与保活，检测到 NAT 后启用 |
| 协议 50（ESP） | 加密业务数据，双向，不可用端口号过滤 |
| 协议 51（AH） | 仅认证场景使用，与 NAT 不兼容 |
| 方向 | 均为双向放行，回程不能省 |
| 常见拦截点 | 边界防火墙、云安全组、运营商策略、NAT 设备 |
典型使用场景
- 新增隧道前做放行清单评审，避免开通当天才发现被拦
- 云上部署 VPN 网关：安全组需要同时放行 UDP 500/4500 与协议 50
- 阶段一成功但业务不通：优先核对 ESP 是否被中间设备丢弃
- NAT 环境下协商异常：确认 UDP 4500 是否打开、是否发生端口改写
- 多级防火墙串联：逐跳核对，避免只改了靠近设备的那一台
验证与放行思路
验证与放行思路
# 两端同时抓包对比，最快判断被哪一跳拦截
tcpdump -ni eth0 'udp port 500 or udp port 4500'
tcpdump -ni eth0 'proto 50'
# 出口有报文、对端入口无报文 -> 中间被拦截
# iptables 放行示例（仅示意，按实际策略调整）
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp --dport 4500 -j ACCEPT
iptables -A INPUT -p esp -j ACCEPT
# 确认 NAT-T 是否生效
show crypto ipsec sa | include nat报文与用途对照
| 流量 | 方向 | 用途 |
|---|---|---|
| UDP 500 | 双向 | IKE 阶段一与阶段二协商 |
| UDP 4500 | 双向 | NAT-T 封装、NAT 场景下的后续协商 |
| ESP（协议 50） | 双向 | 加密后的业务报文 |
| AH（协议 51） | 双向 | 完整性认证，NAT 环境下不可用 |
ESP 是 IP 协议号而不是端口，防火墙策略里通常要单独选「协议 50」；只放行端口的策略无法覆盖 ESP，这是云上安全组最常见的配置遗漏。
两端都在 NAT 后面时，双方都走 UDP 4500，且需要避免设备改写源端口；若出现端口改写，可评估在两台 NAT 设备上固定映射关系。