4、IPsec VPN详解：IPsec协议族（AH、ESP、IKE）、传输模式与隧道模式、安全关联（SA）建立流程
各位同学，咱们今天来啃一块硬骨头——IPsec VPN。说实话，IPsec 这玩意儿在边缘计算设备里太常见了。我最早接触它是在做工业网关项目的时候，客户要求设备跟总部之间必须走加密隧道，而且不能影响实时数据的传输。折腾了整整一周，才把 IPsec 调通。今天我把这些经验掰开揉碎了讲给你听。
4.1 IPsec 协议族：三个核心兄弟
IPsec 不是一个单独的协议，而是一整套协议族。说白了，就是三个兄弟各司其职：AH、ESP 和 IKE。我习惯把它们比作「保镖」、「加密师」和「钥匙管理员」。
4.1.1 AH（认证头）——只负责验明正身
AH 的全称是 Authentication Header。它的任务很简单：保证数据包的完整性，验证发送方的身份。但它不加密数据。
嗯，这里要注意：AH 会校验整个 IP 包，包括 IP 头部中那些会变化的字段（比如 TTL、Checksum）。所以它在 NAT 环境下会出问题——NAT 改了 IP 地址，AH 校验就过不去了。我在项目中遇到过这种情况，当时排查了好久才发现是 NAT 把 AH 搞崩了。
4.1.2 ESP（封装安全载荷）——加密+认证二合一
ESP 是 IPsec 里的主力。它既做加密，又做认证。你想想看，在边缘计算场景下，设备采集的数据往往涉及生产机密，光认证不够，必须加密。
ESP 的格式是这样的：
+----------------+----------------+----------------+----------------+
| ESP Header | Payload | Padding | Auth Data |
| (SPI + Seq#) | (加密数据) | (填充对齐) | (完整性校验) |
+----------------+----------------+----------------+----------------+SPI 是安全参数索引，用来标识是哪条安全关联。Seq# 是序列号，防止重放攻击。这两个字段很重要，后面讲 SA 的时候还会提到。
我个人习惯用 ESP 的 传输模式 来做边缘设备之间的点对点通信，用 隧道模式 来做站点到站点的 VPN。具体区别下面会讲。
4.1.3 IKE（互联网密钥交换）——自动协商密钥
IKE 是 IPsec 的大脑。没有它，你只能手动配密钥，那在边缘设备成百上千的场景下根本不可行。
IKE 分两个阶段：
- 阶段一（IKE SA）：建立一条安全的控制通道。双方交换身份、协商加密算法、生成主密钥。这个过程可以用主模式（Main Mode）或野蛮模式（Aggressive Mode）。
- 阶段二（IPsec SA）：在安全通道上协商具体的 IPsec 参数，生成用于数据加密的会话密钥。
我记得有一次调试边缘设备，IKE 阶段一总是失败。查了半天，发现是两边的预共享密钥里有一个隐藏的空格字符。这种坑，你遇到了就知道有多烦人。
4.2 传输模式 vs 隧道模式
这两个模式的区别，说白了就是一句话：传输模式只保护上层数据，隧道模式保护整个 IP 包。
| 特性 | 传输模式 | 隧道模式 |
|---|---|---|
| 保护范围 | 仅传输层及以上（TCP/UDP 数据） | 整个原始 IP 包 |
| IP 头部 | 使用原始 IP 头 | 新增一个外层 IP 头 |
| 适用场景 | 端到端通信（如两台服务器之间） | 站点到站点、远程访问 VPN |
| 数据包大小 | 较小，开销少 | 较大，有额外头部开销 |
| NAT 兼容性 | 相对较好（ESP 模式下） | 需要额外处理（NAT-T） |
你想想看，在边缘计算场景下，如果是一个传感器设备直接跟云平台通信，用传输模式就够了。但如果是一个边缘网关后面挂着几十个设备，网关跟总部之间建 VPN，那就必须用隧道模式——因为网关要替后面的设备封装数据包。
我做过一个项目，边缘网关采集 PLC 数据，通过 4G 网络传到总部。一开始我用了传输模式，结果发现 PLC 的 IP 地址在公网上不可路由。后来改成隧道模式，在网关和总部防火墙之间建了一条隧道，所有内网地址都封装在隧道里传输，问题就解决了。
4.3 安全关联（SA）建立流程
SA 是 IPsec 的核心概念。你可以把它理解成「双方约定好的一套安全规则」。每条 SA 包含：SPI、源/目的 IP、安全协议（AH 或 ESP）、加密算法、认证算法、密钥、生命周期等。
SA 的建立流程，我习惯用「三步走」来记忆：
第一步：IKE 阶段一——建立 IKE SA
- 发起方发送 SA 提议（支持的加密算法、哈希算法、DH 组等）
- 响应方选择一组参数，回复确认
- 双方通过 Diffie-Hellman 交换生成共享密钥
- 验证对方身份（预共享密钥或证书）
- 生成 IKE SA，用于保护后续的 IKE 通信
这里有个细节：DH 交换的计算量很大。在边缘设备上，如果 CPU 主频只有几百 MHz，DH 交换可能会卡住几秒钟。我建议用 椭圆曲线 DH（ECDH），计算量小很多，安全性还更高。
第二步：IKE 阶段二——建立 IPsec SA
- 双方在 IKE SA 的保护下，协商 IPsec 参数
- 包括：使用的协议（AH/ESP）、加密算法、认证算法、SPI 值等
- 生成用于数据加密的会话密钥
- 建立两条 IPsec SA（一条入方向，一条出方向）
嗯，这里要注意：IPsec SA 是单向的。所以通信双方需要各建一条 SA，一条用来发送，一条用来接收。我刚开始学的时候老搞混，以为一条 SA 就够了。
第三步：数据传输与 SA 维护
- 数据包根据 SA 中的规则进行加密/认证
- SA 有生命周期，到期后自动重新协商
- 如果检测到对端失联，SA 会被删除
4.4 实战中的几个坑
最后分享几个我在边缘计算项目中踩过的坑：
- MTU 问题：IPsec 会增加头部开销，导致数据包超过链路 MTU。我曾经遇到过摄像头视频流经过 IPsec 隧道后卡顿，就是因为 MTU 没调好，导致大量分片和重传。解决方案是降低接口 MTU 或启用 TCP MSS 钳制。
- NAT 穿越：ESP 协议在 NAT 环境下会出问题，因为 NAT 无法识别 ESP 的端口信息。需要用 NAT-T（NAT 穿越）技术，把 ESP 包封装在 UDP 里。大部分现代 IPsec 实现都支持自动检测 NAT 并启用 NAT-T。
- DPD 检测：在 4G/5G 网络下，边缘设备的 IP 地址可能会变化。如果不启用 DPD（Dead Peer Detection），隧道断了你都不知道。我建议把 DPD 间隔设短一些，比如 10 秒，这样能快速发现隧道故障并重建。
好了，IPsec 的核心内容就这些。下一章咱们讲如何在实际的边缘设备上配置 IPsec VPN，包括 StrongSwan 和 Libreswan 的配置示例。到时候我会拿一个真实的项目案例来演示，保证你学完就能上手。