第 10 章 通往信任的隧道
有一类问题，表面上看是网络配置问题，实际上是信任问题。
我们在这一章要处理的，正是这样一个问题。
想象一下，你正坐在一家充满了黑客和监控探针的咖啡馆里，打开笔记本电脑准备连上公司的内网查收一封紧急邮件。你发出的每一个比特，理论上都可能被中间的人截获、篡改、或是干脆丢弃。在这个场景下，物理线缆是不可信的，路由器是不可信的，甚至隔壁那个一直在敲键盘的家伙也是不可信的。
但你需要在这个完全不可信的网络上，构建出一条「完全可信」的通道。这听起来像是某种悖论——你怎么能利用脏水，洗出一件干净的衣服？
答案不是去净化整个网络（那是不可能的），而是要把你的数据装进一个别人打不开的「装甲车」里。无论外面多乱，装甲车里面的东西始终是完整的、保密的。
这就是 IPsec 的核心任务。它不仅是企业 VPN 的基石，也是现代 Linux 网络栈里最复杂的子系统之一。
这一章会很硬核。我们会从用户空间的密钥协商开始，一路钻到内核深处的 XFRM 框架，看着一个数据包是如何被一步步加密、封装、解密、还原的。这不仅仅是配置几个参数那么简单——我们需要理解这套机制是如何在不牺牲性能的前提下，为网络通信筑起一道防线的。
准备好了吗？让我们开始拆解这个装甲车。
10.1 概览：IPsec 的两种面孔
IPsec 已经成了当今世界 IP VPN（虚拟专用网络）事实上的标准。
当然，世界并不是铁板一块的。除了 IPsec，你肯定也见过基于 SSL 的 VPN，或者那种古老的、把 PPP 连接塞进 GRE 隧道里的 PPTP 方案。但说实话，如果你在 Linux 环境下谈「正统」的 VPN，大家默认指的就是 IPsec。它不是跑在应用层的一个小补丁，而是直接长在 IP 协议骨架上的肌肉。
在这个庞大的协议族里，有两个核心协议你必须先分清楚：AH（Authentication Header，认证头） 和 ESP（Encapsulating Security Payload，封装安全载荷）。
- AH 只负责一件事：证明「这个包没人动过」。它提供完整性和认证，但不加密数据。这就像寄信时用透明封套，虽然别人能看，但一旦拆开或涂改，收信人一眼就能看出来。
- ESP 才是真正的重头戏：它既加密数据，又保证完整性。这是 IPsec 里最常用的协议，也是我们这一章的主角。它就像一个不透明的保险箱，不但别人打不开，连里面装了什么都看不见。
模式的选择：传输 vs 隧道
知道用什么协议只是第一步，接下来你还得决定「怎么用」。IPsec 有两种截然不同的操作模式，这个选择决定了你的数据包长什么样。
1. 传输模式
你可以把传输模式理解为「自带防弹衣的快递员」。
在这种模式下，IP 头部原封不动，只有 IP 数据包的载荷被加密和认证。路由器依然能读取 IP 头部的信息来转发数据包，但真正的内容被保护起来了。这种方式通常用于端到端的加密通信，效率较高，但不支持虚拟网络地址（因为 IP 头是明文的，必须能用）。
2. 隧道模式
而隧道模式，是「把装甲车再装进一节火车车厢」。
在这种模式下，整个原始 IP 数据包（包括它的 IP 头）都被当作载荷加密，然后被塞进一个全新的 IP 数据包里。新 IP 头里包含的是网关的地址。
这就是为什么 VPN 大多用隧道模式。对于外面的路由器来说，它只看到一个从 A 地网关发往 B 地网关的普通数据包。至于里面装的是谁的数据，它完全不知道。这种模式允许私有 IP 地址（如 192.168.x.x）在公网上传输，因为它们被隐藏在新的 IP 头后面了。
当然，凡事有例外。有些场景（比如 L2TP/IPsec）虽然也是 VPN，但会用传输模式——这是因为它自己已经有一层隧道了，IPsec 只负责加密那层隧道里的数据。
本章路线图
IPsec 不仅仅是一个内核模块，它是一个跨越了用户空间和内核空间的庞大系统。为了讲清楚它，我给你画了一张地图：
- IKE（Internet Key Exchange）：这是用户空间的「外交官」。在真正传输数据之前，通信双方得先商量一下用什么密钥、什么算法，这叫密钥交换。这个活儿很复杂，通常由用户空间的守护进程（比如 strongSwan 或 Openswan）来完成，不归内核管。
- XFRM 框架：这是内核里的「执行者」。不管用户空间商量出什么结果，最终都要翻译成内核能理解的结构（策略和状态），由 XFRM 框架来执行加密、解密和封装。
- 收发路径：数据包怎么进入 IPsec 处理流程，又是怎么被还原的。
- NAT 穿透：一个专门处理「意外」的机制——当 IPsec 遇到了 NAT 设备，该怎么在夹缝中生存下来。
接下来，我们先从用户空间的 IKE 协议开始，看看这场「外交谈判」是怎么进行的。