传输模式还是隧道模式：看数据包，不看示意图

教科书上的示意图把传输模式与两台主机配对，把隧道模式与两个网关配对，这条经验规则会一直成立，直到第一次部署把它打破。模式描述的是 ESP 数据包包裹了什么，而不是两端是谁。网关可以在传输模式下保护流量，一对主机只要愿意也可以用隧道模式。三个问题就能确定某次具体部署需要什么。

模式是一种布局，不是一种拓扑

在传输模式下，ESP 头位于 IP 头之后、下一层载荷之前，所以原始 IP 头留在外面并且可见。在隧道模式下，被保护的内容是一个完整的 IP 数据包，而新的外层头指明两个 IPsec 对端。

Mode	What follows the outer IP header	Headers a capture shows
Transport	ESP, then the next-layer payload	One IP header
Tunnel	ESP, then a whole inner IP packet	Outer and inner headers

选择机密性时，隧道模式下被保护的区域包含那个内层 IP 头，因此没有密钥时抓包无法告诉你真正的端点。外层头在两种情况下都可读，而正是这一点让排障成为可能。

看一下应用生成的数据包，问是哪一条边界在保护它。如果答案是两个本来就正确的地址之间的传输载荷，传输模式就合适，不必再造第二个头。如果被保护的内容需要自己的地址，因为真正的端点不同于承载流量的对端，那么隧道模式来完成这件事。两种情况存在于同一个组织里，所以一条策略陈述很少能覆盖全部。

这个问题可以从一次抓包和一张路由表回答。它无法从一张把方框标成客户端和服务器的图回答。在任意一端抓的包，几秒钟内就能说明你看的是两者中的哪一个。

L2TP 就是说明这一点的历史反例。该服务在 L2TP 会话里承载 PPP，由 IPsec 保护这段交换；这种安排规定的是传输模式，同时允许隧道模式作为选项。可见的结果是服务层面的隧道，而它的外层保护用的是传输模式。

所以产品描述里出现隧道一词，并不能说明它下面那一层是什么模式。记下是哪个问题定下了这一点，因为下一位复核者会问同样的事。去读这种组合的规范，而不是从名字推断，因为这一习惯能避免大多数关于产品该支持什么的争论。

两端必须一致，而一方提供一种模式、另一方却要求第二种模式的提议，会在协商阶段直接失败，而不是悄悄降级。去问远端的所有者策略写的是哪种模式，并且核对提议本身，而不是文档摘要。

混合环境很常见：一个网关为旧产品终止传输模式会话，为站点链路终止隧道模式会话。模式是按关联算的，不是按设备算的。要关联清单，而不是功能名称，因为名称传得比配置快。

做复核时，列出对端、模式、选择器和下一层协议，然后补上包在结果外面的任何封装。地址转换会增加它自己的外层视角，并不是一种模式；经过转换的流仍然可以是两者之一。清单是唯一能显示关联实际安装状态而非意图状态的产物。

最后问路由和授权，因为正确的数据包布局并不能告诉你允许哪些子网，也不能说明回程路径是否存在。这些存在于策略和路由表里，而两者都不会改变关于模式的论证。