隧道起不来的主因
IPsec VPN 的建立分两个阶段：IKE 阶段协商管理通道（加密套件、DH 组、认证方式、预共享密钥），IPsec 阶段协商数据通道（加密与认证算法、PFS、SA 生命周期）。两端参数必须完全一致，任何一项不同都会让隧道卡在 Phase 1 反复重试，或者在 Phase 2 起不来。绝大多数「隧道不通」的根因是参数不一致，而不是底层网络不通。
基本信息
| 典型拓扑 | 云厂商 VPN 网关 ↔ 本地防火墙/路由器，多分支互连 |
|---|---|
| 必须一致 | IKE 版本、加密算法、认证算法、DH 组、预共享密钥、IPsec 算法、PFS 开关与组 |
| 可协商项 | SA 生命周期两端不同不必然失败，但会带来重协商抖动，建议一致 |
| 感兴趣流 | 本端网段与对端网段必须互为镜像，否则隧道 UP 但流量不进隧道 |
| 建议做法 | 两端配置同一套从强到弱的备选算法列表，避免逐项手工比对 |
参数一致性检查表
| 参数 | 示例 | 不一致的后果 |
|---|---|---|
| IKE 版本 | IKEv1 / IKEv2 | 一期协商无匹配提议，直接失败 |
| 加密与认证算法 | AES256 / SHA256 | Phase 1 协商失败，日志报无匹配提议 |
| DH 组 | Group 14（2048 位） | 密钥交换失败，一期无法完成 |
| 预共享密钥 | 42 位以上随机串 | 认证失败，日志提示 PSK 不匹配 |
| IPsec 加密与认证 | AES256 / SHA256 | Phase 2 协商失败，隧道无法 UP |
| PFS 开关与 DH 组 | 开启并使用 Group 14 | 一端开启一端关闭时 Phase 2 必然失败 |
| 感兴趣流网段 | 10.10.0.0/16 ↔ 192.168.0.0/16 | 隧道 UP 但业务不通，SA 上无流量计数 |
典型使用场景
- 云上 VPC 与本地 IDC 打通，成本低于专线、可当天开通
- 多分支门店与总部互连，用 IPsec 收敛到中心网关
- 专线的主备保护：专线故障时 VPN 顶上，需提前把路由优先级设好
- 跨地域或跨境组网，受链路质量影响需关注重协商与丢包
- 临时测试环境对接第三方，用一次性隧道替代长期专线投入
本端排查命令（strongSwan 环境示意）
本端排查命令（strongSwan 环境示意）
ipsec statusall # 连接状态与协商出的 SA 列表
ipsec whack --status # 查看全部 SA 与策略，确认是否建立
ipsec whack --trafficstatus # 看隧道内流量计数，判断流量是否真的进去
ipsec restart # 改完配置重启服务生效
journalctl -u strongswan -n 200 # 看协商失败原因（no proposal / PSK mismatch）隧道 UP 但业务不通时按顺序查：感兴趣流是否互为镜像、路由是否指向隧道接口、对端网段在安全组或 ACL 中是否放行、MTU/MSS 是否需要钳制。大包被丢的典型表现是小请求正常、大文件上传或长连接卡死。
IPsec 隧道会额外占用包头（典型 50-73 字节），路径 MTU 从 1500 降到约 1430 时，未做 MSS 钳制的 TCP 连接会出现「能建连、下不动数据」。通用解法是在隧道接口上钳制 TCP MSS，或让路由器按 PMTU 下发 ICMP 需分片报文。