传输模式和隧道模式回答的是：这份 IPsec 安全关联保护到哪一截，外层地址属于谁。模式是安全关联的属性。截至 2026 年 10 月，一对安全关联要用同一种模式，这条简化要求写在 RFC 4301。ESP 如何摆放头部，写在 RFC 4303。

模式是安全关联的属性

一个可独立引用的定义句：传输模式安全关联通常用在一对主机之间，为端到端提供安全服务。ESP 插在 IP 头之后、下一层协议之前，保护的是这些下一层协议，不是 IP 头，也不是排在 ESP 前面的扩展头（RFC 4301）。

另一个可独立引用的定义句：隧道模式安全关联作用在一条 IP 隧道上，访问控制看的是隧道内部流量的头部。外层 IP 头写 IPsec 处理的源和目的，内层 IP 头写最终的源和目的。ESP 只保护被封装的那一份包，不保护外层头（RFC 4301）。

RFC 4301 写明，IKE 成对创建安全关联；为了简化，要求一对里的两条使用同一种模式。两条方向相反的关联，一个传输、一个隧道，不是这份架构里的配对方式。

「传输」这个词不表示只能承载 TCP 或 UDP。RFC 4303 专门写了一句：不要把传输模式理解成只能用于 TCP 和 UDP。

传输模式留下原来的 IP 头

IPv4 里，ESP 放在 IP 头和选项之后、下一层之前。原来的源地址和目的地址仍在这一个 IP 头里。紧挨着 ESP 的那个协议字段取 50，表示后面是 ESP（RFC 4303 第 2 节）。

IPv6 里，ESP 被视为端到端载荷，应当出现在逐跳选项、路由头和分片头之后。目的选项可以在 ESP 之前、之后，或两边都有。因为 ESP 只保护自己后面的字段，把目的选项放在 ESP 之后，才能让这些选项也落在保护范围内。这是 RFC 4303 的建议，不是一条禁止放在前面的必须。

ESP 尾部的下一个头从 IANA 的 IP 协议号里选取。RFC 4303 举的例子是：4 表示 IPv4，41 表示 IPv6，6 表示 TCP。传输模式下，它标识的是原来的下一层。取 59 表示没有下一个头，用来标记填充用的哑包。发送方必须能够生成这种哑包，接收方必须准备丢掉它们，并且不把它当成差错。RFC 4303 要求实现应当按安全关联提供打开这一能力的本地开关。某一实现有没有这个开关，本文没有测量。本文不写如何打开它。

路径上仍能看见传输模式那个 IP 头里的地址。看不见的是 ESP 后面的下一层。完整性覆盖从 ESP 头到尾部；加密覆盖载荷和尾部，不含前面的 IP 头。图见 RFC 4303 第 3.1.1 节。AH 还会覆盖前面 IP 头里的一部分，范围在 RFC 4302。本文只写 ESP。

隧道模式另加一对地址

RFC 4303 第 3.1.2 节写明：内层 IP 头携带最终的源和目的，外层 IP 头携带 IPsec 对端的地址，例如安全网关的地址。内层和外层的 IP 版本可以不同，IPv6 套 IPv4 或 IPv4 套 IPv6 都允许。ESP 相对外层头的位置，与传输模式里 ESP 相对原 IP 头的位置相同。下一个头在隧道模式下标识的是内层 IP 包。

加密因此盖住内层地址。外层地址仍然可见，否则中间路由器无法把包送到对端。RFC 4301 把这种效果称作部分流量机密性：藏起的是最终源和目的，还可以用填充掩盖包长。它同时写明，粒度更细的安全关联比汇集许多用户的粗粒度关联更容易被做流量分析。这是架构文档里的比较，不是对某一产品的测量。

解密并转发之后，内层包离开网关。网站看到的源，是这一跳之后的结果。出口若再改写地址和传输标识，见 出口 NAPT。隧道模式不代替那一步。各层加密各覆盖谁，见 VPN 与 HTTPS 各加密哪一层。

安全网关何时必须用隧道模式

一个可独立引用的定义句：除下面两类例外，只要安全关联的任一端是安全网关，这条关联就必须是隧道模式。主机实现则必须同时支持传输模式和隧道模式（RFC 4301）。

两类例外是：

  1. 流量的目的就是这台安全网关，例如管理用的报文。此时网关是在充当主机，允许传输模式。
  2. 安全网关可以用传输模式，为路径上两个中间系统之间的 IP 流量提供保护，例如主机与安全网关之间，或两台安全网关之间。

第二类还有一条限制：中间系统使用传输模式，只允许用在出站时源地址属于这台中间系统自己、或入站时目的地址属于它自己的那些包。这样用时，IPsec 的访问控制用不到穿越这条关联的端到端头部，RFC 4301 要求在具体场合里谨慎评估。

主机必须两种都支持。RFC 4301 点名的范围包括原生实现，以及栈内插入（BITS）和线路插入（BITW）。安全网关必须支持隧道模式，可以支持传输模式。若支持，也只应在它充当主机时使用，例如网络管理，或为路径上两个中间系统之间提供保护。这里的「只应」是 RFC 4301 摘要里的 should，不是该段前面那句 MUST 的同义词。

L2TP/IPsec 把 ESP 放在传输模式，是因为 L2TP 已经另有一层隧道，ESP 保护的那份 UDP 以隧道端点自己的地址为源和目的。这落在上面的限制里。端口和层次见那一篇，本文不重写。

两台主机之间也可以建立隧道模式。模式因此不能从「有没有网关」一个词推出来。

RFC 4301 还写明：对已经是分片的 IPv4 包，不能用传输模式施加 AH 或 ESP，只能用隧道模式。IPv6 在技术上可以把明文分片放进传输模式，但为了简化，同一限制也适用于 IPv6。分片字段本身如何工作，见 RFC 791 与 RFC 8200；本文不把那一套字段再讲一遍。更后面的处理顺序在 RFC 4301 第 7 节。

它不决定哪些包走进去

哪些包匹配一条安全关联，由选择符和安全策略数据库决定。那是基于策略的 VPN 与基于路由的 VPN 的差别，见 基于策略与基于路由。两条路线都可以协商出隧道模式的 ESP。模式回答保护范围，策略和路由回答包进不进这条关联。

其他协议即使也在外面再加 IP 头，也不因此拥有 RFC 4301 的这两种模式。IKEv2 与 WireGuard 的差别见 IKEv2 与 WireGuard。WireGuard 不使用这份架构里的模式字段。把它的外层 UDP 叫做隧道模式，只是借用说法。

一个可独立引用的结论句：界面上的「已连接」不说明这条安全关联是传输模式还是隧道模式，也不说明网站看到的地址等于内层源地址。

本文不提供选择模式、修改选择符或生成哑包的步骤。

现象对照

现象更可能先看什么
路径上的 IP 头仍是两端主机的地址，协议字段为 50传输模式。最终地址就在这一个头里
外层地址是网关，解密后里面还有一份 IP 头隧道模式。最终地址在内层
外层是 IPv4，内层是 IPv6隧道模式允许版本不同
网关在转发别人的流量，关联却是传输模式先核对是不是两类例外之一
策略已经匹配，包仍以明文离开模式没有被用上。先看包有没有进入这条关联

核对清单

  1. 先看有几层 IP 头：一层且协议为 50，是传输模式；外层里面还有内层，是隧道模式；
  2. ESP 不加密外层头：隧道模式藏起的是内层地址，外层仍要可路由；
  3. 一对关联同一种模式：这是 RFC 4301 为简化 IKE 配对写下的要求；
  4. 网关转发别人的包要用隧道模式：例外只覆盖目的就是网关，或包的地址属于中间系统自己；
  5. 模式不选择流量：包进哪条关联，仍看策略或路由。