一、开篇总览：先建立全局认知
1. IKEv2 的核心定位
IKEv2（RFC 7296）是 IETF 针对 IKEv1 的原生架构缺陷，从零重构的第二代 IPSec 密钥交换协议。它的核心设计目标，就是彻底解决 IKEv1 的五大顽疾：
- 架构臃肿：阶段 1 + 阶段 2 两层拆分，报文多、建连慢
- 互通性差：大量可选实现，不同厂商设备对接经常协商失败
- 安全性弱：野蛮模式身份明文泄露，主模式抗 DoS 能力极差
- 场景受限：原生不支持 NAT 穿越、不支持移动性切换
- 运维复杂：批量接入场景配置冗余，扩展性差
而初始交换（Initial Exchange）是 IKEv2 的核心骨架，仅用4 个报文、2 次往返，就完成了 IKEv1 需要 6~9 个报文才能做完的「IKE SA 建立 + 身份认证 + IPSec SA 建立」全部工作，同时原生集成了 NAT 检测、地址分配等扩展能力。
2. 核心设计原则（贯穿全流程）
理解了这 4 条原则，你就能看懂每一步设计的底层逻辑：
1. 分层防御，资源后置：越外层的校验成本越低，越核心的资源越晚分配。用最低成本挡住绝大多数攻击，核心资源只给合法用户。
身份保密，动态兼容：既支持动态 IP、非 IP 身份接入，又全程加密传输身份信息，解决 IKEv1"安全就不灵活，灵活就不安全" 的死局。
标准化，去歧义：所有载荷、流程、错误处理都有严格标准，尽量减少厂商自定义的可选实现，从根源提升跨设备互通性。
原生扩展，面向未来：内置标准化扩展载荷框架，NAT 穿越、移动性、国密算法等新能力，都可以通过扩展载荷兼容，不需要重构协议。
3. 前置术语统一（避免概念混淆）
| 术语 | 定义 | 核心作用 |
|---|---|---|
| SA（安全联盟） | 双方约定的加密 / 认证算法、密钥、生命周期等参数的集合 | 加密通信的基础，所有加密行为都基于 SA 执行 |
| IKE SA | 控制平面的 SA，用来协商、管理 IPSec SA | 相当于 "加密通道的指挥部"，生命周期通常 86400 秒 |
| IPSec SA | 数据平面的 SA，用来加密业务流量 | 相当于 "加密通道本身"，生命周期通常 3600 秒 |
| 载荷 | IKE 报文里的独立功能数据块 | 类似积木，不同载荷组合完成不同协商功能 |
| DH 密钥交换 | 不安全信道上协商共享密钥的密码学算法 | 双方只交换公钥，各自算出一模一样的共享密钥，密钥本身永不传输 |
| Cookie | IKE 报文头里的会话标识 | 唯一标识一次协商，同时是抗 DoS 攻击的核心 |
二、第一阶段：IKE_SA_INIT 交换（报文 1、报文 2）
阶段定位
明文交换密钥材料，生成加密通道的基础密钥，完成 NAT 检测和抗 DoS 第一道校验。 这一阶段全程明文传输，不涉及任何身份信息，不分配正式 SA 资源，只做最轻量的密钥材料交换。
报文 1：发起方 → 响应方（IKE_SA_INIT 请求）
1. 携带的核心载荷 & 每个载荷的作用
| 载荷名称 | 作用 | 设计细节 |
|---|---|---|
| IKE 头部（HDR） | 报文标识，携带发起方 Cookie | 发起方生成一个真随机数作为自己的 Cookie，用来唯一标识本次会话 |
| SA 载荷（SAi） | 发起方把自己支持的所有 IKE 加密算法、认证算法、DH 组打包发给对端，供对端选择 | 一次性把所有提议发完，避免多次往返，提升协商速度 |
| KE 载荷（KEi） | 发起方的 DH 公钥 | 核心：把 DH 密钥交换提前到第一个报文，这是 IKEv2 比 IKEv1 快的关键设计 |
| Nonce 载荷（Ni） | 发起方生成的真随机数 | 参与后续密钥推导，增加密钥随机性，防止重放攻击 |
2. 响应方收到报文后的处理流程
3. 本步达成的状态
- 响应方：无任何会话状态，零持久化资源占用。
- 发起方：还没收到响应，只准备好了自己的 DH 私钥、随机数。
报文 2：响应方 → 发起方（IKE_SA_INIT 响应）
1. 携带的核心载荷 & 每个载荷的作用
| 载荷名称 | 作用 | 设计细节 |
|---|---|---|
| IKE 头部（HDR） | 携带「发起方 Cookie + 响应方 Cookie」，双 Cookie 唯一标识本次会话 | 后续所有报文都必须携带双 Cookie 才能被处理 |
| SA 载荷（SAr） | 响应方选定的、双方都支持的 IKE 算法组合 | 选定后双方就用这套算法做后续协商 |
| KE 载荷（KEr） | 响应方的 DH 公钥 | 和发起方公钥配对，双方各自计算 DH 共享密钥 |
| Nonce 载荷（Nr） | 响应方生成的真随机数 | 和发起方随机数一起参与密钥推导 |
| NAT-D 载荷 | NAT 检测载荷，用来判断双方之间有没有 NAT 设备 | 🔴 原生设计：IKEv2 把 NAT 检测直接内置到初始交换，不需要额外打补丁 |
2. 发起方收到报文后的处理流程
3. 本步达成的状态
- 双方拥有了一模一样的会话密钥，具备了加密通信的条件。
- 双方完成了 NAT 环境检测，知道后续要不要用 NAT-T 封装。
- 响应方依然没有保存任何会话状态，零持久化资源占用。
本阶段设计思想 & IKEv1 对比
1. 核心设计：无状态首包响应，极致抗 DoS
IKEv1 最大的架构缺陷，就是首包就分配半开 SA 资源：收到第一个协商报文，立刻在内存里创建完整的半开 SA 条目，保存所有协商状态。攻击者只要伪造 10 万个源 IP 发首包，就能占满设备内存，让合法用户无法接入。
而 IKEv2 的设计彻底解决了这个问题：
- 首包响应完全无状态，不分配任何持久化内存；
- 只有发起方能收到 Cookie 并带回，才能进入下一阶段；
- 伪造源 IP 的攻击，永远收不到响应，也耗不掉设备内存。
同等硬件下，IKEv2 的抗 DoS 能力是 IKEv1 的几十上百倍。
2. 效率提升：DH 交换前置，一次往返完成密钥协商
IKEv1 主模式的 DH 公钥交换，放在第 3、4 个报文，光是阶段 1 就需要 3 次往返； IKEv2 直接把 DH 公钥放到第 1、2 个报文，一次往返就完成密钥材料交换，生成会话密钥。
这是 IKEv2 建连速度快的核心原因之一。
3. 原生 NAT 检测，不再是补丁
IKEv1 的 NAT-T 是后续补充的 RFC，属于事后打补丁，不同厂商实现差异极大，经常出现 "SA 协商起来但流量不通" 的玄学问题。 IKEv2 把 NAT 检测、NAT-T 封装直接写入协议标准，所有厂商按统一规则实现，兼容性和稳定性大幅提升。
三、第二阶段：IKE_AUTH 交换（报文 3、报文 4）
阶段定位
加密通道内完成身份认证，分配正式 SA 资源，同时建立首个 IPSec SA。
这一阶段所有报文全程加密，是整个协商的核心安全环节，也是资源正式分配的节点。
报文 3：发起方 → 响应方（IKE_AUTH 请求）
1. 报文整体特性
- 整个报文除了 IKE 头部，全部用 SK_e 加密，外界抓包看不到任何内部内容。
- 携带 SK_a 生成的完整性校验值，报文被篡改会直接校验失败。
2. 携带的核心载荷 & 每个载荷的作用
| 载荷名称 | 作用 | 设计细节 |
|---|---|---|
| IDi 载荷 | 发起方的身份标识 | 可以是 IP、域名、用户名、证书 DN 等，支持多种动态身份类型🔴 全程加密传输，彻底解决 IKEv1 野蛮模式身份明文泄露的问题 |
| AUTH 载荷 | 身份认证签名 | 核心中的核心，用来证明发起方持有合法的认证凭证 |
| SA 载荷（SAi2） | 发起方支持的 IPSec 加密 / 认证算法提议 | 🔴 直接在身份认证阶段协商 IPSec SA 参数，不需要单独走 "阶段 2"，这是 IKEv2 高效的另一个关键 |
| TSi/TSr 载荷 | 流量选择子，定义需要加密的流量范围 | 相当于 IKEv1 的感兴趣流 ACL，但更灵活，支持动态下发 |
| CP 载荷（可选） | 配置请求载荷，向服务端申请虚拟 IP、DNS、网关等信息 | 原生支持远程接入地址分配，对应之前讲的 VPN 地址池场景 |
3. 🔴 深度拆解：AUTH 载荷到底是什么？怎么生成的？
这是你之前最困惑的点，这里彻底讲透：
AUTH 载荷不是直接发送预共享密钥，而是用预共享密钥计算出来的 "数字签名"，全程密钥本身永不传输。
生成公式（预共享密钥场景）：
bash
AUTH = PRF(预共享密钥, 前面所有报文的完整内容 + IDi + 其他参数)简单说就是：用提前约定好的预共享密钥，把前面 1、2 号报文的所有内容、自己的身份 ID，一起算一个不可逆的哈希签名。
它的两大核心作用：
1. 身份认证：只有持有正确预共享密钥的人，才能算出正确的 AUTH 签名。对端用自己手里的同一个密钥按同样方法计算，结果一致就证明对方身份合法。
2 . 抗中间人攻击：签名里包含了前面所有报文的内容，如果中间人篡改了 DH 公钥、算法等任何内容，算出来的 AUTH 签名就会对不上，协商直接失败。
这就完美解决了 "DH 交换本身不抗中间人" 的密码学缺陷。
4. 响应方收到报文后的处理流程（分层校验，逐层分配资源）
这是整个流程最核心的设计，严格遵循「先校验，再分配；先轻量，再核心」的原则：
报文 4：响应方 → 发起方（IKE_AUTH 响应）
1. 携带的核心载荷 & 每个载荷的作用
| 载荷名称 | 作用 |
|---|---|
| IDr 载荷 | 响应方的身份标识，加密传输，供发起方验证对端身份 |
| AUTH 载荷 | 响应方的身份认证签名，发起方用来验证响应方身份 |
| SA 载荷（SAr2） | 响应方选定的 IPSec 算法组合 |
| TSi/TSr 载荷 | 确认后的加密流量范围 |
| CP 载荷（可选） | 配置响应，返回分配给客户端的虚拟 IP、DNS、网关等信息 |
2. 发起方收到报文后的处理流程
- 校验报文完整性，解密报文。
- 验证响应方的 AUTH 签名，确认对端身份合法。
- 确认 IPSec SA 参数、流量范围。
- 如果是远程接入场景，保存分配到的虚拟 IP，生成对应的路由。
- 正式在本地创建 IKE SA 和 IPSec SA。
3. 本步达成的最终状态
✅ 双方 IKE SA 正式建立成功。
✅ 双方首个 IPSec SA 正式建立成功。
✅ 业务流量可以开始通过 IPSec 加密传输。
✅ 远程接入场景下，客户端已经获取到虚拟 IP，可以访问内网资源。
本阶段设计思想 & IKEv1 对比
