一文搞定 IKEv2 加密不兼容：排查要点与快速修复

• 开始排查前：先搞清楚 IKEv2 的“分工”
• 典型症状与可能的根因
• 1. 协商失败（双方拒绝对方的提议）
• 2. 建立成功但无法透传流量
• 3. 频繁重协商或掉线
• 4. 证书相关的错误
• 实战排查流程（按步骤走，避免盲目改动）
• 步骤一：收集基础信息
• 步骤二：查看日志与抓包
• 步骤三：比对提议并调整到共同子集
• 步骤四：检查 NAT 与端口/MTU
• 步骤五：证书与时间同步
• 步骤六：重现并验证修复
• 常见厂商/平台的坑与解决办法
• 实用工具与日志关键信息
• 快速修复清单（遇到问题时优先尝试）
• 若要避免重复问题：配置建议与未来趋势
• 案例速览：加密套件不匹配导致的失败

开始排查前：先搞清楚 IKEv2 的“分工”

遇到 IKEv2 隧道不能建立或频繁掉线，别急着换服务器或重装客户端。先理解 IKEv2 的两个阶段与主要参数会让排查事半功倍。简要地说，IKE_SA（阶段1）负责身份验证与加密协商，CHILD_SA（阶段2）负责实际的数据加密。每个阶段都有一系列“提议”（加密算法、认证算法、DH 组、PRF、SA lifetime 等），任何一项不匹配都可能导致不兼容。

典型症状与可能的根因

1. 协商失败（双方拒绝对方的提议）

表现：客户端/服务器在 IKE_SA_INIT 或 IKE_AUTH 阶段就中止，日志提示“no acceptable proposal”或“NO_PROPOSAL_CHOSEN”。

原因通常是：双方支持的加密套件、认证方法（证书 vs PSK vs EAP）、DH 组或 PRF 不一致，或者服务器强制使用某些不常见的选项。

2. 建立成功但无法透传流量

表现：IPSec 隧道显示为 UP，但数据包不走或双向无响应。

常见原因：ESP transform 不一致（例如 AH/ESP 或加密模式不同），或是路由/策略错误、MTU/分片问题、NAT 后端端口映射被破坏。

3. 频繁重协商或掉线

表现：隧道每隔一段时间就重建，或出现重放/不匹配的 rekey。

原因可能是 SA lifetime 设置差异、动态 IP 与 MOBIKE 行为、或者 DPD/keepalive 策略不一致。

4. 证书相关的错误

表现：证书链验证失败、签名算法不支持、证书格式不识别。

常见原因：客户端/服务器对 ECC vs RSA 的支持差异、缺少中间 CA、时钟偏差导致证书无效。

实战排查流程（按步骤走，避免盲目改动）

步骤一：收集基础信息

确认双方 IP、使用的客户端/服务器软件及版本、认证方式（PSK/证书/EAP）、是否经过 NAT。记录当前的提议（加密、认证、DH、PRF、lifetime）。

步骤二：查看日志与抓包

启动详细日志（如 strongSwan/Libreswan 的 debug，Windows Event 或 macOS 系统日志），并用 tcpdump/wireshark 抓包。关键报文是 IKE_SA_INIT、IKE_AUTH、CREATE_CHILD_SA。观察是否有明确的拒绝码（NO_PROPOSAL_CHOSEN、AUTHENTICATION_FAILED 等）。

步骤三：比对提议并调整到共同子集

把双方支持的算法列表列出来，先选择最保守、兼容性最好的组合（例如：AES-CBC/CTR 或 AES-GCM、SHA256、DH14/19）。如果一方是老设备，优先兼容老算法。

步骤四：检查 NAT 与端口/MTU

如果存在 NAT，确保 NAT-T（UDP encapsulation）被启用。抓包看是否有 ESP 包被丢弃或被错误 NAT。MTU/DF 导致的碎片问题，常见表现是 IKE 阶段成功但 CHILD_SA 建立失败或数据不通，必要时减小 MSS/MTU 或启用 IKEv2 的分片扩展。

步骤五：证书与时间同步

确认时钟同步（NTP），证书链完整且算法被支持。对 ECC/RSA 的不兼容可以用临时回滚为 RSA 或更新对端软件解决。

步骤六：重现并验证修复

每做一次更改都重启相关服务并在抓包中验证 IKE_SA_INIT/IK E_AUTH 的协商结果。确保变更不会影响到其它已运行隧道。

常见厂商/平台的坑与解决办法

Windows：默认对某些 PRF/transform 有固定偏好，常导致与 Linux 的 strongSwan/Libreswan 不匹配。解决方法：在服务器端加入 Windows-compatible 的提议，或在客户端策略里允许更广泛的算法。

iOS/macOS：对证书和 EAP 类型敏感，常因证书链问题或未启用某些扩展而失败。推荐使用 Apple 支持的证书格式并保证 CA 在系统信任链中。

Cisco/Juniper 等硬件：默认配置偏旧或非标准扩展，需要手动对齐 DH 组和 lifetimes，有些设备需要显式开启 NAT-T 或 fragmentation 支持。

实用工具与日志关键信息

常用工具：tcpdump、wireshark（解析 IKEv2 报文）、swanctl/ipsec status、strongSwan/Libreswan 的日志、ike-scan。抓包时重点看 IKE_SA_INIT 的 SECURITY_ASSOCIATION 提议、IKE_AUTH 中的身份/证书交换、CREATE_CHILD_SA 的 ESP transform。

关注字段：Proposal payload、Transform IDs（ENCR/PRF/INTEG/DH）、Notify messages（例如 NAT_DETECTION_SOURCE_IP）。Notify 中常有说明为何提议被拒绝。

快速修复清单（遇到问题时优先尝试）

– 对齐加密/认证/PRF/DH 到一个双方都支持的组合；

– 启用 NAT-T 并检查 NAT 检测报文；

– 同步时钟并确认证书链完整；

– 临时降低安全策略以确认兼容性（测试完再回滚）；

– 对 MTU/分片问题，尝试减小 MTU 或启用 IKEv2 分片；

– 启用并查看详细日志/抓包，优先分析 NO_PROPOSAL_CHOSEN、AUTH_FAILED、INVALID_KE_PAYLOAD 等错误。

若要避免重复问题：配置建议与未来趋势

在服务器端保持一组向后兼容的算法集合，同时逐步淘汰弱算法并通知客户端升级。对证书管理要规范化：统一 CA、使用常见签名算法、保证有效期和 NTP。关注 IKEv2 新扩展（如 IKEv2 分片、MOBIKE）以及加密套件的演进（更多采用 AES-GCM、ChaCha20-Poly1305、更高的 DH 组或基于曲线的算法）。

案例速览：加密套件不匹配导致的失败

场景：strongSwan 服务器与某厂商 VPN 网关建立 IKEv2，日志显示 NO_PROPOSAL_CHOSEN。抓包显示服务器只提议 AES-GCM/PRF=AES128、DH=19，而对端只接受 AES-CBC/SHA1、DH=14。解决办法是临时在服务器加入 AES-CBC+SHA1+DH14 的提议，确认能连通后再制定升级计划，逐步淘汰弱算法。

通过系统化的排查流程、抓包与日志分析，以及将配置对齐到双方共同支持的子集，大多数 IKEv2 加密不兼容问题都能在短时间内定位并修复。翻墙狗（fq.dog）提醒：在生产环境修改加密策略时请谨慎操作，先在测试环境验证再上线。