模块七 · 网络安全
IPsec 与虚拟专用网
前面的 TLS 工作在应用层和传输层之间，它保护的是"一个应用的连接"。但如果要让整台机器的所有流量都安全地穿过一个不可信的网络呢？答案是在网络层做保护 —— 这就是 IPsec，也是 VPN 的技术基础。
本章要解决的问题：前面的 TLS 工作在应用层和传输层之间，它保护的是"一个应用的连接"。但如果要让整台机器的所有流量都安全地穿过一个不可信的网络呢？答案是在网络层做保护 —— 这就是 IPsec，也是 VPN 的技术基础。
本章的证据来源：概念讲法参考教材§8.7，纸书427–433页（PDF446–452页），具体出处见章末。旧稿的命令与数值属于历史转述，相关附件未随当前项目提供，本次没有重新采集或运行原实验；模型计算、协议规则与观察不能互相替代。
先从一个例子理解概念
远程办公设备通过公共网络访问内部服务，希望保护某段传输路径。先说清保护从哪里开始、到哪里结束，再理解VPN与隧道。
VPN与隧道
VPN借助共享网络构建受控的逻辑连接；隧道把原数据封装进另一层传送。隧道不天然等于加密，VPN名称也不自动说明所有流量都经过它。
IPsec与安全关联
IPsec在IP层提供相关安全机制；安全关联（SA）记录方向、算法、密钥等状态。实际保护能力取决于选用的协议、模式和配置。
VPN 的两种用途
"VPN"这个词经常被混用，其实它指两种不同的场景：
| 用途 | 典型场景 | 保护什么 |
|---|---|---|
| 远程接入 | 员工在家连公司内网 | 从公网到企业网络这一段 |
| 站点互联 | 把两个办公地点连成一个网 | 两地之间的链路 |
两者的共同点是：在一条不可信的链路上，建立一条逻辑上的"私有通道" —— 而这就是"虚拟专用网"（Virtual Private Network）这个名字的字面含义。
为什么要在网络层做？
| 在哪一层做保护 | 效果 | 代价 |
|---|---|---|
| 应用层 / 传输层（HTTPS） | 只保护那一个应用的连接 | 每个应用都要自己支持 |
| 网络层（IPsec） | 整台机器的所有流量都被保护，对应用完全透明 | 配置复杂，且中间设备看不到内容 |
"对应用透明"是网络层方案最大的优势：应用不需要任何改动，甚至不知道自己被保护了。
IPsec 的两个协议
IPsec 不是一个协议，是一组协议。 其中最核心的两个：
| 协议 | 提供什么 | 加密吗 |
|---|---|---|
| AH（认证头） | 认证 + 完整性 | 不加密 |
| ESP（封装安全载荷） | 认证 + 完整性 + 加密 | 加密 |
实践中几乎只用 ESP —— 因为 AH 不提供机密性，而且它认证整个 IP 包包括可变字段（如 TTL），在中间有 NAT 的环境里会失效。
ESP 的具体做法：在原始 IP 包外面加一个 ESP 头，把内层数据加密，然后再加上一个新的 IP 头（隧道模式）。
传输模式与隧道模式
这是理解 IPsec 和 VPN 的关键区分。
传输模式：保护"载荷"，不改变端点
原始： [ IP 头 ][ TCP 头 ][ 数据 ]
↓ 保护
传输模式：[ IP 头 ][ ESP 头 ][ TCP 头 ][ 数据 ][ ESP 尾 ]
└────── 这一段被加密/认证 ──────┘IP 头没有被保护（因为路由器需要它来转发），被保护的是 TCP/UDP 头和数据。
用途：主机到主机的通信（两端都装了 IPsec）。
隧道模式：把整个包封起来，改变端点
原始： [ IP头1 ][ TCP 头 ][ 数据 ]
↓ 整个包被当作"载荷"
隧道模式：[ 新IP头 ][ ESP头 ][ IP头1 ][ TCP头 ][ 数据 ][ ESP尾 ]
└─ 这一层是"公网可见的" ─┘ └─ 这一整块被加密 ─┘注意这里出现了两个 IP 头：
| 谁看得见 | 里面写什么 | |
|---|---|---|
| 外层 IP 头 | 公网上所有设备都能看到 | 两个 VPN 网关的地址 |
| 内层 IP 头 | 只有隧道两端能看到（被加密） | 真实的源和目的地址 |
这就是"隧道"这个名字的由来：真实的包被装进另一个包里传输，中间的网络只能看到外层。这就是 VPN 能隐藏内网结构的原因。
用途：网关到网关（站点互联）或主机到网关（远程接入）。
安全关联（SA）：隧道的"配置"
IPsec 是双向的，但每条方向上的保护参数是独立协商的。 一组这样的参数叫一个安全关联（SA）：
| SA 里包含什么 | 例子 |
|---|---|
| 用哪个协议 | ESP |
| 用哪种加密算法 | AES-256 |
| 用哪种认证算法 | SHA-256 |
| 密钥是什么 | 协商出来的会话密钥 |
| 有效多久 | 生存期到了就要重新协商 |
SA 是单向的 —— 所以一条双向的 VPN 隧道需要两个 SA。
SA 由 IKE 协商建立。 IKE 做的事和 TLS 握手很像：双方互相鉴别身份、协商算法、用 Diffie-Hellman 生成密钥。区别是 IKE 跑在 UDP 500/4500 上，而且它协商的是"网络层隧道的参数"，不是"某个应用连接的参数"。
实测：本机装了三个 VPN 适配器，但都没连
Get-NetAdapter | Where-Object { $_.InterfaceDescription -match 'VPN|WireGuard|TAP|Wintun|IPsec' }实测结果：
Name InterfaceDescription Status
---- -------------------- --------
以太网 3 iNode VPN Virtual NIC Disconnected
本地连接 QMTAP Adapter V9 Disconnected
Heysocks TAP-Windows Adapter V9 TAP-Windows Adapter V9 Disconnected另外：Get-NetIPsecRule 返回 0 条规则 —— 本机没有任何 IPsec 配置。
这张表里最值得注意的是一个模式：三个 VPN 都是"虚拟网卡"的形式。
iNode VPN → 虚拟网卡
QMTAP → 虚拟网卡（TAP 驱动）
Heysocks → 虚拟网卡（TAP-Windows）
FlClash → 虚拟网卡（TUN，见《MAC 地址》那一章）为什么 VPN 都用虚拟网卡？
| 做法 | 原理 | 优点 |
|---|---|---|
| 虚拟网卡 + 改路由 | 建一块假网卡，把路由指过去 | 对应用完全透明（和 IPsec 隧道模式同一个思路） |
| 应用层代理 | 每个应用自己配置走代理 | 需要对每个应用配置，且有的应用不支持 |
"虚拟网卡 + 改路由"正是本教程反复观察到的那个机制：FlClash 就是这样接管了默认路由（《代理与负载均衡》实测），而 IPsec 的隧道模式在原理上也一样 —— 都是"把流量导入一个逻辑通道，对应用透明"。
IPsec VPN 与 TLS VPN 的对比
现代 VPN 有两条技术路线，值得对比：
| IPsec VPN | TLS VPN | |
|---|---|---|
| 工作在哪一层 | 网络层 | 传输层之上 |
| 保护范围 | 整台机器的所有流量 | 通常是特定应用/流量 |
| 对应用透明 | 完全透明 | 需要配置（或用一个本地代理） |
| 穿透防火墙 | 难（ESP 不是 TCP/UDP，NAT 后需要额外处理） | 容易（看起来就是 HTTPS） |
| 客户端 | 通常需要装驱动（虚拟网卡） | 浏览器或一个普通程序 |
| 鉴别方式 | IKE 里协商（常用证书或预共享密钥） | 复用 TLS 的证书体系 |
"穿透防火墙"这一行很关键：ESP 是 IP 协议号 50 的协议，不在 TCP/UDP 之列，很多防火墙和 NAT 设备对它处理不好。而 TLS VPN 的流量看起来就是普通的 HTTPS（TCP 443），几乎无法被简单规则挡住。
常见误解
误解一：「VPN 是一种加密算法」
不是，它是一种用法 —— 在不可信链路上建立逻辑私有通道。底层可以用 IPsec（网络层）也可以用 TLS（传输层之上），两者都能实现 VPN。"VPN"说的是要达到的效果，不是达到它的手段。
误解二：「VPN 和 HTTPS 是一回事」
保护范围不同。 HTTPS 只保护那一个应用的连接；IPsec VPN 保护整台机器的所有流量，而且对应用完全透明（应用不需要改任何东西，甚至不知道自己被保护了）。
误解三：「隧道模式就是加密了数据」
比加密更多。 隧道模式把整个原始 IP 包（含原始 IP 头）当作载荷加密，外面再套一个新的 IP 头。所以中间网络只能看到两个 VPN 网关的地址，看不到真实的源和目的。这就是 VPN 能隐藏内网结构的原因 —— 而传输模式会保留原始 IP 头，隐藏不了。
误解四：「IPsec 和 NAT 可以随便一起用」
它们有冲突。 AH 认证整个 IP 包（包括 TTL、校验和这些会被 NAT 改写的字段），NAT 一改就认证失败。ESP 在 NAT 后也需要额外处理（NAT-T，把 ESP 封装进 UDP 里穿过 NAT）。 根本原因：NAT 破坏了端到端原则，而 IPsec 的设计假设是端到端的 —— 两者对"地址会不会变"的假设正好相反。
误解五：「本机装了三个 VPN 客户端，说明在用 VPN」
不能这么推断。 本机实测：三个适配器全部是 Disconnected，而且 Get-NetIPsecRule 返回 0 条规则。 "装了客户端"和"建立了隧道"是两件事 —— 前者只是软件存在，后者需要真正连接并协商出 SA。
本章小结
| 结论 | 类型 |
|---|---|
| VPN 有两种用途：远程接入与站点互联 | 标准 |
| 网络层做保护的优势是"整机流量都被保护且对应用透明" | 标准 |
| IPsec 的两个核心协议：AH（只认证不加密）、ESP（认证 + 加密） | 标准 |
| 实践中几乎只用 ESP，因为 AH 不提供机密性且与 NAT 冲突 | 标准 |
| 传输模式保护载荷、保留原 IP 头；隧道模式保护整个原包、套新 IP 头 | 标准 |
| 隧道模式下中间网络看不到真实的源与目的地址 | 推理 |
| 安全关联（SA）是单向的，一条双向隧道需要两个 SA | 标准 |
| SA 由 IKE 协商，IKE 跑在 UDP 500/4500 | 标准 |
| 实测：本机装了三个 VPN 虚拟适配器，全部处于 Disconnected | 实测 |
实测：本机 Get-NetIPsecRule 返回 0 条规则，无 IPsec 配置 | 实测 |
| VPN 普遍采用"虚拟网卡 + 改路由"，与代理接管路由是同一机制 | 推理 |
| TLS VPN 比 IPsec VPN 更容易穿透防火墙，因为看起来就是 HTTPS | 标准 |
| 本机没有活跃隧道，故观察不到 IPsec 的实际行为 | 实测限制 |
自测题
7 题 · 先自己答，再展开对照
VPN 有哪两种典型用途？
远程接入（员工在家连公司内网）和站点互联（把两个办公地点连成一个网）。共同点是在不可信链路上建立逻辑私有通道 —— 这就是"虚拟专用网"的字面含义。在网络层做安全保护（IPsec）相比在应用层（HTTPS）有什么优势和代价？
优势：整台机器的所有流量都被保护，而且对应用完全透明 —— 应用不需要任何改动，甚至不知道自己被保护了。
代价：配置复杂，而且中间设备看不到内容（这既安全也带来运维困难，还容易与 NAT 冲突）。AH 和 ESP 的区别是什么？为什么实践中几乎只用 ESP？
AH 只提供认证和完整性、不加密；ESP 提供认证、完整性，还提供加密。
几乎只用 ESP 的原因：① AH 不提供机密性（数据还是明文）；② AH 认证整个 IP 包，包括 TTL、校验和这些会被 NAT 改写的字段 —— 一旦经过 NAT 就认证失败。传输模式和隧道模式的区别是什么？哪种能隐藏真实的源和目的地址？
传输模式保护的是载荷（TCP/UDP 头和数据），保留原始 IP 头，用于主机到主机。隧道模式把整个原始 IP 包当作载荷加密，外面再套一个新的 IP 头，用于网关到网关或主机到网关。
隧道模式能隐藏真实的源和目的地址 —— 因为原始 IP 头也在加密范围之内，中间网络只能看到两个 VPN 网关的地址。为什么一条双向的 VPN 隧道需要两个安全关联（SA）？
因为 SA 是单向的。 它描述的是一组"某个方向上的保护参数"（协议、算法、密钥、生存期）。
一条双向隧道有两个方向，每个方向需要自己的一套参数和密钥，所以需要两个 SA —— 一个管 A→B，一个管 B→A。本机实测装了三个 VPN 适配器，能否据此认为在用 VPN？
不能。 本机实测：三个适配器全部是Disconnected，而且Get-NetIPsecRule返回 0 条规则。
"装了客户端"和"建立了隧道"是两件事 —— 后者需要真正连接、通过 IKE 协商出 SA 才能工作。为什么现代很多 VPN 选择基于 TLS 而不是 IPsec？
因为穿透防火墙容易得多。 IPsec 的 ESP 是 IP 协议号 50 的协议，不在 TCP/UDP 之列，很多防火墙和 NAT 设备对它处理不好（还需要 NAT-T 之类的变通）。
而 TLS VPN 的流量看起来就是普通的 HTTPS（TCP 443），几乎无法被简单的规则挡住。
所以这是"协议僵化"的又一个体现 —— 不是因为 IPsec 技术上不行，而是因为中间设备决定了什么协议能跑得通。
参考资料与适用范围
- 《计算机网络：自顶向下方法（原书第8版）》§8.7，纸书427–433页（PDF446–452页）：本章概念与机制的对应教学章节，引用时需保留模型与版本条件。
- 教材作者配套教学资源入口：网站目前显示的教材版本与用户提供的第8版可能不同，页码以本章列出的中文第8版为准。
修订核对日期：2026-10-13。本次补充概念入口与教材出处；旧稿的具体数值为历史观察，未重新实测。相关脚本和完整日志未随当前项目提供，不能仅凭转述断言实验已复核，也不据此断言数据造假。