引言：为什么需要理解IKE协商的两个阶段？
IPsec VPN是企业和云上常用的安全隧道技术，而IKE（Internet Key Exchange）协议负责自动协商加密和认证参数，生成会话密钥。IKE协商分为两个阶段：阶段一建立安全通道（ISAKMP SA），阶段二在保护下建立数据加密通道（IPsec SA）。理解这两个阶段的工作原理，是排障的基础。许多一线工程师遇到VPN不通时，往往只检查两端配置是否一致，却忽略了协商报文交互的细节——例如阶段一的ID类型、阶段二的流量选择器等易错点。本文将从协商流程、报文交换到常见故障逐一拆解。
阶段一：建立ISAKMP SA（安全联盟）
1. 阶段一的目标与模式
阶段一的主要任务是：身份认证、交换密钥材料、协商保护套件，最终生成一个双向的ISAKMP SA。该SA用于保护后续阶段二的协商报文。阶段一支持两种模式：
- 主模式（Main Mode）：使用6条报文交互，身份保护能力强（身份信息在加密后才传输）。适用于大多数场景，特别是公网连接。
- 野蛮模式（Aggressive Mode）：仅3条报文，速度更快，但身份信息以明文传输——因此仅在NAT穿越或对端IP不固定时推荐使用。
2. 主模式6条报文详细交互
以预共享密钥认证为例，主模式流程如下：
- 报文1-2：发起方与响应方交换SA载荷（即策略提议），包括加密算法（AES、3DES）、哈希算法（SHA256、MD5）、DH组（Group 14/5）、认证方法（预共享密钥）以及生存期。双方找到匹配的策略组合。
- 报文3-4：交换DH公钥和随机数（Nonce）。至此，双方可以计算出一个共享密钥（SKEYID_d、SKEYID_a、SKEYID_e），用于后续的身份认证和加密。
- 报文5-6：在加密通道内（使用已生成的会话密钥）交换身份信息（IDi/IDr）并进行哈希认证。验证预共享密钥或证书的有效性。
关键点：阶段一生成的ISAKMP SA是双向的——即同一个SA可以被双方用来保护后续报文。它的生存期通常较短（如3600秒），到期后需要重新协商。
3. 野蛮模式3条报文速览
野蛮模式将策略提议、DH公钥、身份信息合并到前两条报文内，第三条报文仅做认证确认。优点是只需一次往返，但身份以明文发送，易被嗅探。因此仅用于诸如Remote Access VPN（远程接入VPN）中客户端IP动态变化时。
阶段二：建立IPsec SA（数据加密隧道）
1. 快速模式（Quick Mode）的作用
阶段二在已建立的ISAKMP SA保护下进行，目的是协商具体的数据加密参数，包括：IPsec协议（ESP或AH）、加密算法、完整性算法、封装模式（传输模式或隧道模式），并协商受保护的数据流（即感兴趣的流量，通过ACL定义）。阶段二使用3条报文完成，可生成多个IPsec SA（通常为一出一入两个方向的SA）。
2. 快速模式3条报文交互
- 报文1（HASH + SA + Nonce + [IDci, IDcr] + [可选KE]）：由发起方发送，包含IPsec策略提议、Nonce、身份选择器（即流量选择器，如源/目的IP、端口、协议）。HASH用于验证报文完整性。
- 报文2（HASH + SA + Nonce + [IDci, IDcr] + [可选KE]）：响应方回复选中的策略组合、自己的Nonce，以及流量选择器确认。
- 报文3（HASH）：发起方发送最终确认，阶段二完成。
注意：流量选择器的不匹配是阶段二协商失败的主要原因之一。例如，一端配置了10.0.0.0/24，而另一端配置了10.0.0.0/16，即便证书通过，SA也会协商失败。
3. PFS（完美前向安全性）的影响
如果在阶段二配置了PFS（需要额外DH交换），则阶段二报文会包含KE载荷，重新进行DH计算，使得即使阶段一的长期密钥泄露，也无法解密IPsec流量。
常见故障诊断与排查方法
1. 阶段一协商失败故障
症状：VPN状态显示IKE SA建立失败，日志显示“NO_PROPOSAL_CHOSEN”或“INVALID_COOKIE”。可能原因及诊断步骤：
- 策略不匹配：检查双方加密算法、DH组、认证方法是否完全一致。使用debug crypto isakmp显示正在发送的提议组。
- 预共享密钥不一致：在极端情况下（如野蛮模式），密钥错误会导致身份认证失败。建议将密码重置为不含特殊字符的字符串并核对。
- 防火墙/UDP 500端口阻塞：IKE使用UDP 500端口，NAT穿越时加用UDP 4500。使用telnet或nc测试UDP端口是否可达。
- ID类型不匹配：主模式下ID为IP地址或FQDN。如果响应方配置了基于ID的策略（如指定允许特定FQDN），而发起方发送的是IP地址，则认证失败。检查debug输出中的IDi字段。
2. 阶段二协商失败故障
症状：ISAKMP SA已建立（状态显示MM_ACTIVE或QM_IDLE），但IPsec SA未建立，日志显示“IPSEC KEY ENGINE”错误或“NO_PROPOSAL_CHOSEN”。常见原因：
- 感兴趣流（ACL）不一致：两端保护的数据流必须对称。例如，一端定义10.0.1.0/24到10.0.2.0/24，另一端必须为10.0.2.0/24到10.0.1.0/24（源目相反）。使用命令show crypto ipsec sa可查看失败的SA及流向。
- PFS配置冲突：若一端启用PFS而另一端未启用，或DH组不同，会导致阶段二失败。检查两端PFS设置。
- NAT穿越故障：如果设备在NAT网关后面，未开启NAT-T（UDP 4500封装），会导致ESP报文被NAT丢弃，阶段二超时。启用“isakmp nat-traversal”并检查是否使用UDP 4500。
3. 连通性正常但数据传输慢
- MTU问题：IPsec封装增加20+8+可变加密头，导致实际报文大于接口MTU，触发分片或丢包。可以尝试降低MTU（如1400）或启用TCP MSS Clamping。
- 重传与超时：死对端检测（DPD）间隔过短导致频繁重协商。调整为30秒或更长。
排错实战：一个典型场景
假设公司总部与分支通过IPsec VPN互联，配置完成后总部能ping通分支，但分支不能ping通总部。检查show crypto isakmp sa：两端MM_ACTIVE，正常。show crypto ipsec sa：发现只有入方向SA，没有出方向SA。推断是感兴趣流定义不对称。确认：总部定义acl 101 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255，分支定义acl 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255——实际正确。再检查：分支设备NAT转换规则将内网地址转换了，导致流量不匹配。关闭NAT后问题解决。
总结与最佳实践
IKE两个阶段的设计将身份认证与数据保护分离，提高了灵活性。故障排查时应遵循“先阶段一，后阶段二”的顺序，辅以抓包（Wireshark过滤udp.port==500或4500）查看Payload字段。建议在日常配置中：
- 统一加密套件为AES256-SHA256-DH14及以上，避免兼容性问题；
- 为每个隧道单独配置感兴趣的流，并检查双向对称；
- 在公网环境开启NAT-T（即使当前没有NAT，以防故障）；
- 开启DPD并设置合理间隔（如10秒发送，30秒超时）。
掌握阶段一与阶段二的原理，能让工程师在面对“建不起来”或“掉线”时迅速定位到问题层。记住：日志中的“phase 1 failed”不等于“IKE阶段一失败”，可能是认证失败；而“phase 2 failed”往往与流量定义有关。
延伸阅读