IPsec ESP：它承载什么，以及如何证明它正在流动

ESP 承载 IPsec VPN 中的流量，而它的 runbook 从一条规则开始：先读安全关联，再改策略。大多数无法解释的 ESP 行为都源于选择器不匹配、模式靠假设而非读取，或者在一整条流发送期间没人检查的计数器。下面三个步骤确定什么承载什么，证明一条流确实用它，并留下一个不依赖记忆的回滚。每一步都产出一条值得写下来的观察。

读之前先认识字段

ESP 在受保护数据前面加头部、后面加尾部。头部携带安全参数索引，用来标识接收方应使用哪条关联；还携带序列号以检测重放；尾部中的填充让载荷按加密算法的要求对齐。尾部里的下一头部字段说明受保护内容是什么，接收方由此知道自己解封装了什么。

模式决定了这层保护里面装什么。隧道模式下，受保护的是完整的内层 IP 报文，由一个新的外层头部在两端之间搬运。传输模式下，保护只包住现有报文的上一层载荷，所以没有第二个 IP 头部需要拆开。用哪种模式是配置事实，不是解释问题。要从状态条目里读出来，而不是从拓扑图上猜。

两种模式都不隐藏必须投递报文的外层寻址。这是设计属性而非缺陷，也正因如此，中间观察者即使看不到载荷内容，仍能看出是哪两个地址在通信。

第一步：先读状态，再读策略

状态条目保存密钥和计数器；策略条目保存决定谁可以使用的选择器。在 Linux 上两者都无需抓包即可查看，按这个顺序读能让两个问题保持分开。

ip xfrm state
ip xfrm policy

在状态输出里检查关联的源和目的、模式，以及封装是否显示 UDP 端口。这些端口说明正在使用 NAT 穿越，这会改变中间防火墙必须放行什么，但不改变两端适用哪些选择器或密钥。

然后读策略里的选择器。选择器声明的前缀比你在测的流量更窄，是隧道明明在工作却像忽略某条流的最常见原因；而协议选错的选择器会带来同样的沉默。

厂商工具以更顺手的形式打印同样的信息。ipsec statusall在 strongSwan 上，它会列出子关联、它们的选择器和字节计数器；如果你已经知道该看哪个子关联，这通常比读原始 xfrm 输出更快。

第二步：证明一条流推动了计数器

只有知道本应谁来推动计数器，计数才有意义。所以选一个选择器肯定覆盖的源和目的，发一个无害请求，然后再读同一个条目并对比。

ip -s xfrm state
tcpdump -ni any esp

两次读数讲的是不同的故事。出方向递增而入方向从不递增的报文，指向的是转发或回程路径问题，而不是密钥问题，因为报文已经被封装并发出去了。若没有任何计数器移动，说明流量从未匹配上策略，而选择器就是该看的地方。

同一步里的抓包确认了线上的封装，包括外层是 ESP 还是 UDP 封装的 ESP。它还会显示真正承载这条流的地址，而这些地址有时与你正在读的配置不同。

第三步：只改一处，并保留回滚

在动手之前，记录关联的源、目的、模式、选择器和计数器。如果改动让情况变糟，正是这份记录让你能恢复原状，而不是凭猜测重建一份能用的配置。这份记录花一分钟，后面能省一小时。它也是改动者离开之后唯一留下的东西。

改一个选择器或一个参数，重新加载，然后对同一条流重做第二步。删除关联会拆掉所有使用它的流，所以定向修改加重新加载子关联，几乎总比清空状态看会发生什么要好。

选择器改动的回滚是恢复原策略并重新加载，附带条件是：如果选择器是协商而来而非本地的，对端可能需要相应改动。趁记忆新鲜把这条依赖写下来，因为半恢复的一对，比两个终态中的任何一个都更难推理。

最后，把范围说清楚。一条流动的 ESP 关联证明两台网关在保护并投递这个分段，它并不说明上层应用是否认证用户、是否加密存储。那些是另外的控制项和另外的证据；只有下一个人能照着笔记复现，这份 runbook 才算完成。