IP安全 SEC VPN_2

IPSec协议框架

IPsec 不是一个单一协议，而是一个框架，包含三个核心标准协议：

ESP（Encapsulating Security Payload） ：真正干活的"保镖"，负责加密和完整性校验，保护用户数据。
AH（Authentication Header） ：只负责完整性校验和身份认证，不加密（现网很少单独使用）。
IKE（Internet Key Exchange） ：幕后"管家"，负责自动协商出 ESP/AH 工作所需的各种参数（密钥、算法、SPI 等）。

一句话 ：IKE 负责"谈好条件"，ESP/AH 负责"按条件执行"。绝大数现网 VPN 只用 IKE + ESP，AH 几乎被淘汰。

完整工作流程（以 IKEv1 主模式 + ESP 隧道模式为例）

bash 复制代码

1. 触发 VPN 流量（如访问对端子网）
   ↓
2. IKE 第一阶段（主模式）
   ├─ 消息1-2：明文协商 IKE 策略（加密算法、哈希、DH组等）
   ├─ 消息3-4：DH 交换 → 计算出 DH 共享密钥，生成随机数
   └─ 消息5-6：在加密隧道中交换身份和认证数据 → 建立 IKE SA
   ↓
3. IKE 第二阶段（快速模式）
   ├─ 在 IKE SA 保护下，协商感兴趣流（ACL）、新随机数
   ├─ 使用 SKEYID_d + 随机数派生出 ESP 加密密钥和认证密钥
   └─ 建立一对 IPsec SA（入方向和出方向）
   ↓
4. 数据包处理（以 ESP 隧道模式为例）
   ├─ 原始 IP 包（如 PC→Server）
   ├─ 防火墙/网关根据 ACL 匹配，决定送入 IPsec 隧道
   ├─ 查找出方向的 IPsec SA，获得 SPI、加密密钥、认证密钥
   ├─ 对原始 IP 包加密，加上 ESP 头和尾，计算 ICV
   ├─ 封装在新的 IP 头中（源=本端公网IP，目的=对端公网IP，协议=50）
   └─ 发送到公网
   ↓
5. 接收端处理
   ├─ 收到协议 50 的包，提取 SPI，查找入方向的 IPsec SA
   ├─ 验证序列号（抗重放）
   ├─ 验证 ICV（完整性）
   ├─ 解密载荷
   └─ 还原原始 IP 包，转发给内网服务器

在IPsec VPN中，IKE（Internet Key Exchange）是唯一的"谈判官"和"信使"。两台防火墙之间所有关于"如何保护数据"的细节------用什么加密算法、用什么哈希算法、用什么密钥、保护哪些流量、多长时间换一次密钥------都必须由IKE协议来承载和传递。没有IKE，就没有自动协商，只能靠手工配置（现网基本不用）。

一句话：IKE负责所有控制层面的沟通，数据层面（ESP/AH）只管"埋头干"，不问"怎么干"。

IKE的协商

IKE主模式的前4条消息确实是明文发送的，其中包含了DH公共值（ga mod p 和 gb mod p）和随机数（Nonce）

这正是IKE协议的精妙所在。它的设计前提，就是让DH交换在公开的、不安全的信道上完成，并且交换的内容是安全的。

IKE（Internet Key Exchange）的前期交换（IKE_SA_INIT / 主模式前4个包）确实是明文传输。但这并不危险，因为：

真正敏感的"身份信息"（ID、预共享密钥哈希）在加密的交换阶段才发送。

用于生成加密密钥的DH公开值（公钥）即使明文泄露，也无法反向计算出共享密钥（离散对数难题）。

设计之初就假设网络是"可窃听但不可篡改"的（只防被动攻击，不防中间人） -- 中间人攻击需要靠预共享密钥或证书来防范。

底层原理 & 设计逻辑（以IKEv1为例）

IKEv1主模式（Main Mode）交换分3个"交换对"，共6个包：

交换对	报文内容	是否加密	泄露风险
1 (包1-2)	IKE策略提议（加密算法、哈希算法、DH组、认证方式）	❌ 明文	低 -- 攻击者知道你在用什么算法，无法直接破解
2 (包3-4)	DH公开值 (ga mod p)、Nonce（随机数）	❌ 明文	极低 -- 离散对数难题：知道`g^a mod p`和`g^b mod p`，无法算出`g^{ab} mod p`（DH共享密钥）
3 (包5-6)	身份ID（IP或FQDN）、认证数据（预共享密钥哈希或证书签名）	✅ 已加密	无 -- 此时双方已用DH共享密钥 + Nonce 派生出SKEYID_e（加密密钥），报文加密