如果你曾经在路由器或防火墙上配置过 IPsec VPN，大概率遇到过这样的场景：两边配置都填好了，点击连接，等了几秒显示协商失败。VPN 日志里出现了 no acceptable proposal 或 no matching policy 之类的报错。这时如果不理解 IKE 阶段一（Main Mode）和阶段二（Quick Mode）到底在做什么，就很容易对着屏幕发呆。
这篇文章完全面向小白来写——不涉及复杂的密码学公式，只关注协商流程中的关键参数，以及当协商失败时，你应该从哪个方向去排查。
一、IPsec VPN 的握手协议：为什么需要两个阶段？
故障定位思路
IPsec VPN 不是一条直接拉通的物理线缆，它相当于在公网上建立一条加密隧道。建立这条隧道之前，两端必须“互相认识”并且约定好用什么方式加密、用什么密钥解密。这个过程叫做 IKE（Internet Key Exchange），它分为两个阶段：
- 阶段一（Main Mode）：双方先建立起一个安全的管理通道（ISAKMP SA）。这个通道本身是加密的，用来保护后续的协商流量。
- 阶段二（Quick Mode）：在阶段一的保护下，双方协商出用于传输真正业务数据的 IPsec SA。阶段二可以同时生成多条 SA，对应不同的数据流。
简单类比：阶段一是你与对方打电话前先确认身份和通话密码，阶段二是用这个加密线路讨论具体要传哪些文件。任何一步出错，电话就打不通。
二、阶段一（Main Mode）协商过程与常见故障
2.1 阶段一做了什么
阶段一通常使用 Diffie-Hellman（DH）算法来产生一个临时密钥，然后用这个密钥加密后续的交互。整个过程分三步：
- 策略交换：双方交换支持的加密算法、哈希算法、DH 组、认证方式（预共享密钥或证书）。
- DH 交换：交换 DH 公钥，计算共享密钥。
- 身份验证：用预共享密钥或证书验证对方身份。这一步在 Main Mode 中是加密传输的。
2.2 阶段一失败的主要原因
- 算法不匹配：两端配置的加密算法（如 AES-128 vs 3DES）、哈希算法（SHA-1 vs SHA-256）、DH 组（Group 2 vs Group 5）不完全一致。日志会显示
no acceptable proposal。 - 预共享密钥不匹配：虽然配置了相同的加密套件，但密钥值不同。报错可能为
invalid payload或pre-shared key mismatch。 - 身份 ID 不匹配：阶段一本地 ID 与对端期望的 ID 不一致。许多防火墙会验证对方 ISAKMP 报文中的 ID 字段，如果不同则中断协商。
- NAT 穿越问题：如果两端之间有 NAT 设备，没有启用 NAT-T（NAT 穿越），会导致 UDP 500 端口被扰乱。部分厂家默认开启 NAT-T，但有些需要手动开启。
- 超时或端口不通：UDP 500 被封、防火墙没有放行该端口，或者中间有策略阻止 IKE 包。日志中常出现
retransmitting直到超时。
2.3 如何排查阶段一
最直接的方法是打开两端设备的调试日志。以 strongSwan 为例：
ipsec statusall # 查看当前隧道状态
ipsec auto --status # 详细查看所有配置和连接状态
journalctl -u strongswan # 查看 strongSwan 服务日志对于经典 IPSec 设备（如 Cisco ASA 或 Router）：
debug crypto isakmp 255 # 这条命令会打出详尽的 IKE 调试信息如果看到 payload malformed 或 invalid hash information，那大概率是预共享密钥写错了。如果是 no acceptable proposal，就需要核对加密算法和 DH 组。
相关阅读：此处可内链到“IPsec VPN常见问题”专题。
三、阶段二（Quick Mode）协商过程与常见故障
3.1 阶段二做什么
当阶段一的 SA 建立成功后（即 ISAKMP 状态为 UP），就开始阶段二的协商。阶段二会做这些事：
- 协商 IPsec 安全提议：加密算法（如 ESP-AES-128）、认证算法、封装模式（隧道模式或传输模式）以及 PFS（完美向前保密）设置。
- 协商感兴趣流（Proxy ID）：也就是哪些 IP 段允许通过 VPN 传输。通常定义为本地子网与远程子网的配对。
- 生成 IPsec SA：最终产生两条单向的 SA（一条进、一条出），用于实际加密数据。
3.2 阶段二失败的主要原因
- 感兴趣流（Proxy ID）不匹配：这是最常出现的阶段二问题。比如本端配置的本地子网为 192.168.1.0/24，对端期望的却是 192.168.1.0/24 但端口不一样，或者对端允许的子网列表里不包含这个范围。日志常见
no matching policy或TS_UNACCEPTABLE。 - PFS（完美向前保密）不匹配：如果一端启用了 PFS（要求阶段二使用新的 DH 组），另一端没有使用相同的 DH 组或完全关闭了 PFS，则阶段二协商失败。典型报错
no acceptable key exchange。 - IPsec SA 生命周期不匹配：一端例如设定了 3600 秒，另一端设定了 28800 秒，虽然部分设备会迁就对端，但不同厂商行为不同，可能导致协商不通过。
- 阶段一 SA 过期：阶段一的 SA 有生存时间，如果阶段二在这个生存时间之后才开始协商且两端都要求重新认证，也可能失败。
3.3 如何排查阶段二
查看阶段二的调试信息，继续在 strongSwan 上：
ipsec statusall # 查看阶段一和阶段二 SA 状态
cat /var/log/charon.log | grep 'CHILD_SA'在 Cisco 设备上：
debug crypto ipsec 255如果输出中出现 TS_UNACCEPTABLE，说明两端对感兴趣流的定义不匹配。建议检查双方的本地子网和远程子网是否严格对等——包括子网掩码长度。比如 192.168.1.0/24 和 192.168.1.0/25 会被认为不同。此外，检查 ACL（访问控制列表）配置，确认两边允许的流量方向一致。
对于 PFS 问题，最简单的做法是将两端都关闭 PFS 试试；如果必须开启，则确保 DH 组相同（如 Group 5）。
延伸阅读：此处可内链到“IPsec VPN配置案例”相关文章。
四、从零开始的诊断流程建议
故障定位思路
- 检查基本网络连通性：先确认两端公网 IP 能 ping 通。如果中间有 NAT，验证 UDP 500 和 UDP 4500（NAT-T 使用）端口可达。
- 核对阶段一参数：加密算法、认证算法、DH 组、认证方式（PSK 或证书）、预共享密钥、以及当地 ID 和对端 ID。
- 打开阶段一调试：观察是否完成策略交换与身份验证。若失败，根据日志中的关键字定位原因。
- 阶段一成功后，再核对阶段二参数：特别是 Proxy ID（本地子网、远程子网）和协议类型（通常为 0，代表所有协议）。如果使用了 PFS，需确认 DH 组一致。
- 检查生存时间：将两端的阶段一和阶段二生命周期设为相同值（例如 28800 秒和 3600 秒），减少因轻微差异导致的失败。
- 抓包确认：如果日志仍不清晰，用 Wireshark 在 VPN 设备外侧抓包，过滤
esp或udp.port == 500，观察 IKE 交互报文是否完整。例如：
tcpdump -i eth0 -n udp port 500 or udp port 4500 -w vpn.pcap把 pcap 文件导入 Wireshark，选择 IKEv1 （如果是 IKEv1）即可看到每一步的 payload。注意观察是否有 Notify 报文携带错误代码，比如 NO_PROPOSAL_CHOSEN 或 INVALID_ID_INFORMATION。
进阶阅读：此处可内链到“IPsec VPN性能优化”指南。
五、脑图式的故障速查表
故障定位思路
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 阶段一反复重传，无响应 | UDP 500 端口不通 / NAT 未开启 / 对端防火墙丢弃 | 检查 ACL、ping、traceroute |
| 阶段一拒绝 proposal | 加密算法 / DH 组 / 认证方式不匹配 | 核对两边 config 中的具体算法列表 |
| 阶段一报 invalid payload | 预共享密钥不一致 | 检查 PSK 值（注意空格和大小写） |
| 阶段一审通过，阶段二拒绝 | Proxy ID 不匹配 | 核对两端本地/远程子网掩码 |
| 阶段二报 PFS 失败 | PFS 设置不一致或 DH 组不同 | 关闭 PFS 或统一 DH 组 |
| VPN 连接后时断时通 | SA 生命周期不一致 / 任何一方触发 DPD 超时 | 统一生存时间，检查 DPD 配置 |
IPsec VPN：六、小结
验证与回滚
IPsec VPN 的 IKE 协商就像两个人建立一条加密通话，阶段一是互相确认身份和临时通讯密码，阶段二是分配具体的通话频道。遇到故障时，先确认阶段一是否建立成功（ISAKMP SA 为 UP），再排查阶段二的感兴趣流和 PFS。大多数连接问题都出在预共享密钥、加密套件匹配或子网定义不一致上。用上面提到的命令和思路，你完全可以自己定位出问题所在，而不必焦急地等待售后支持。记住：多看日志，少猜配置。
延伸阅读