IPSec 协议深度解析：原理、架构与实现细节
IPSec 协议深度解析：原理、架构与实现细节
IPSec（Internet Protocol Security）并不是单一的协议，而是 IETF 制定的一整套为 IP 网络提供安全性的协议族。它工作在 OSI 模型的网络层（Layer 3），这意味着它可以透明地保护上层的所有协议（如 TCP、UDP、ICMP），而无需应用程序进行任何修改。
本文将深入拆解 IPSec 的核心组件、工作模式以及密钥交换机制。
1. IPSec 的核心组件
IPSec 体系结构主要由三个部分组成：两个传输协议（AH, ESP）和一个密钥交换协议（IKE）。
1.1 AH (Authentication Header) - 协议号 51
AH 旨在提供数据完整性和数据源认证，但不提供加密（机密性）。这意味着数据是明文传输的，但接收方可以确信数据没有被篡改且确实来自声称的发送方。
- 功能:
- 完整性: 计算整个数据包（包括 IP 头中的不可变字段）的哈希值（ICV）。
- 防重放: 使用序列号机制。
- 局限性: AH 最大的问题是它会对 IP 头部进行签名。如果数据包经过 NAT（网络地址转换），IP 头部会发生变化，导致 AH 校验失败。因此，AH 几乎无法穿越 NAT。
1.2 ESP (Encapsulating Security Payload) - 协议号 50
ESP 是 IPSec 中最常用的协议，它同时提供机密性、完整性和认证。
- 功能:
- 机密性: 对 Payload 进行加密（如 AES, 3DES）。
- 完整性: 仅对 ESP 头部和 Payload 进行校验，不校验外层 IP 头。
- 适用性: 由于不校验外层 IP 头，ESP 对 NAT 更友好（尤其是在启用 NAT-T 时）。
1.3 IKE (Internet Key Exchange) - UDP 500/4500
手动配置加密密钥极其繁琐且不安全。IKE 协议用于自动协商密钥、建立安全关联（SA）。目前主流使用的是 IKEv2。
2. 两种工作模式
IPSec 可以根据需求在两种模式下运行：传输模式和隧道模式。
2.1 传输模式 (Transport Mode)
- 场景: 主机到主机（End-to-End）通信。例如，管理员从工作站安全管理服务器。
- 机制: 仅加密/认证 IP 数据包的载荷（Payload）。原始 IP 头部保留不变。
- 数据流:
[IP Header] [ESP Header] [Encrypted TCP/Data] [ESP Trailer]
2.2 隧道模式 (Tunnel Mode)
- 场景: 网关到网关（Site-to-Site VPN）或主机到网关（Remote Access VPN）。
- 机制: 加密整个原始 IP 数据包。然后添加一个新的 IP 头部，源/目地址为 VPN 网关的公网地址。
- 数据流:
[New IP Header] [ESP Header] [Encrypted Original IP Header + TCP/Data] [ESP Trailer]
3. 安全关联 (SA) 与数据库
IPSec 的运行依赖于两个核心数据库来管理连接状态。
3.1 SA (Security Association)
SA 是通信双方对“如何保护数据”达成的契约。SA 是单向的，双向通信需要建立两个 SA。SA 包含三元组标识：
- SPI (Security Parameter Index): 一个 32 位标识符，存在于 AH/ESP 头中。
- 目的 IP 地址。
- 安全协议标识 (AH 或 ESP)。
3.2 SPD (Security Policy Database) - 策略表
SPD 决定了“什么流量需要走 IPSec”。它类似于防火墙规则。
- 规则示例: “所有从 192.168.1.0/24 到 10.0.0.0/24 的流量，必须使用 ESP 加密。”
- 动作: Protect (加密), Bypass (直连), Discard (丢弃)。
3.3 SAD (Security Association Database) - 状态表
SAD 存储了“具体的加密参数”。当 SPD 匹配到需要加密的流量时，内核会查找 SAD 中对应的 SA 来获取密钥和算法。
4. IKEv2 协商流程简述
IKEv2 相比 IKEv1 进行了大幅简化，通常只需要 4 个消息包即可建立连接。
- IKE_SA_INIT (2 packets):
- 协商加密算法（如 AES-256）、哈希算法（SHA-256）和 Diffie-Hellman 组。
- 交换 Nonce 值，生成初始密钥材料（SKEYSEED）。
- 此时，IKE 自身的控制通道已建立，后续所有消息都是加密的。
- IKE_AUTH (2 packets):
- 身份验证: 双方交换身份信息（ID）和认证数据（预共享密钥 PSK 或 证书签名）。
- 建立 Child SA: 顺便协商出第一对用于传输实际数据的 IPSec SA。
5. NAT 穿越 (NAT-T)
标准的 ESP 协议直接封装在 IP 层之上，没有端口号（TCP/UDP 头被加密了）。这导致 PAT（端口转换）设备无法处理多个 IPSec 客户端。
- 解决方案: NAT-Traversal (NAT-T)。
- 机制:
- IKE 协商时探测是否存在 NAT 设备。
- 若存在，自动将 ESP 包封装在 UDP 4500 端口中。
- NAT 设备将其视为普通的 UDP 流量进行转发。
6. 图解：IPSec 工作全流程
文字描述可能比较枯燥，无论是传输模式还是隧道模式，其核心处理逻辑都可以通过以下流程图来理解。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
+----------+ +---------+ +---------+ +----------+
| Host A | | Gw A | | Gw B | | Host B |
+----+-----+ +----+----+ +----+----+ +-----+----+
| | | |
| (1) Ping | | |
| 192.168.2.5 | | |
+---------------->| | |
| | |
[Phase 1: Traffic Trigger & Policy Check] | |
| | |
| (2) Match SPD? -> YES | |
| (3) Check SAD (SA exists?) | |
| | |
[Phase 2: IKE Negotiation (If No SA)] | |
| | |
| (4) UDP 500: IKE_SA_INIT | |
+------------------------------->| |
| <-----------------------+ | |
| | |
| (5) UDP 500: IKE_AUTH | |
+------------------------------->| |
| <-----------------------+ | |
| (Generate Keys -> SAD) | |
| | |
[Phase 3: ESP Data Transfer] | |
| | |
| (6) Encrypt & Encapsulate | |
| (ESP / UDP 4500) | |
+===============================>| |
| [Encrypted] | |
| | (7) Decrypt |
| | (Check ICV) |
| | |
| | (8) Forward |
| +---------------->|
| | |
关键步骤解析
- 策略匹配 (SPD): 数据包到达网关，内核检查 SPD。如果匹配到
PROTECT规则，则拦截数据包，不直接路由。 - 状态查找 (SAD): 检查是否已经存在建立好的加密通道（SA）。
- 无 SA: 触发 IKE 进程（UDP 500），进行身份验证和密钥交换。
- 有 SA: 直接使用 SA 中的算法和密钥。
- 加密封装: 使用 ESP 协议对数据加密，并打上新的 IP 头（隧道模式）或 UDP 头（NAT-T）。
- 解密转发: 对端网关收到包后，根据包头中的 SPI（索引号）去自己的 SAD 里找解密密钥，还原数据后发给目标主机。
7. 现实痛点：IPSec 与 NAT 及“科学上网”
在实际部署中，尤其是个人用户环境下，IPSec 面临着两个截然不同的挑战。
6.1 NAT 环境下的“生存之道”
如前文所述，原始的 IPSec（尤其是 AH 协议）在 NAT 环境下几乎无法工作。但通过 NAT-T (UDP 4500 封装)，现代 IPSec 已经完美解决了这个问题。
- 结论: 无论你是通过家用的光猫拨号，还是在酒店的 Wi-Fi 下，只要支持 NAT-T，建立 IPSec 隧道在技术上是没有障碍的。
6.2 为什么它不适合“科学上网”？
既然能穿透 NAT，为什么在翻墙工具中很少见到 IPSec 的身影？主要原因在于特征识别：
- 特征过于明显: IPSec 的 IKE 协商过程（UDP 500）和数据传输（ESP/UDP 4500）具有极强的报文特征。GFW 能够轻易识别并封锁这些流量。
- 运营商 QoS: 许多运营商会对跨境的 UDP 流量进行限速或丢包（QoS 策略），导致 IPSec 链路极不稳定。
- 缺乏混淆机制: IPSec 设计初衷是为企业级安全设计的，它强调的是“不可破解”，而不是“不可识别”。相比之下，Shadowsocks 或 Trojan 等协议更擅长将流量伪装成正常的网页访问。
7. 总结
IPSec 是一个构建在 OSI 模型网络层的强大安全框架。
- ESP 负责数据加密，IKE 负责密钥管理。
- 隧道模式 适合构建 Site-to-Site VPN，连接不同的网络分支。
- NAT-T 让其适应了复杂的互联网 NAT 环境。
虽然在“科学上网”等对抗性较强的场景下表现不佳，但在企业内网互联、移动办公安全等正规领域，IPSec 依然是不可逾越的工业标准。
附录：数据包结构速查
从网关 A (Gw A) 发出的数据包长什么样？这取决于是否存在 NAT。
1. NAT-T 模式 (常见于家用/移动网络)
当检测到路径上有 NAT 设备时，ESP 会被封装在 UDP 4500 中。
1
2
3
4
5
6
+---------------------+---------------------+---------------------+-------------------------+
| IP Header | UDP Header | ESP Header | Encrypted Data |
+---------------------+---------------------+---------------------+-------------------------+
| Proto: 17 (UDP) | Src Port: 4500 | SPI: 0x1A2B3C4D | (Original IP + Payload) |
| | Dst Port: 4500 | Seq: 101 | [不可读乱码] |
+---------------------+---------------------+---------------------+-------------------------+
2. 原生 ESP 模式 (常见于企业专线/纯公网)
当双方直接拥有公网 IP 且中间无 NAT 时，直接使用 IP 协议号 50。
1
2
3
4
5
6
+---------------------+---------------------+-------------------------+
| IP Header | ESP Header | Encrypted Data |
+---------------------+---------------------+-------------------------+
| Proto: 50 (ESP) | SPI: 0x9876FEDC | (Original IP + Payload) |
| [No UDP Header] | Seq: 202 | [不可读乱码] |
+---------------------+---------------------+-------------------------+