站点 VPN 在哪里终结，决定了什么会被检查

站点间隧道隐藏了一个决定整套检查设计的细节：内层数据包在哪台设备上变成明文。这个点之前的一切只看到 ESP，之后的一切看到的是规则可以匹配的普通 IP。边界画错位置，你花钱买的防火墙就变成了一台带许可证的路由器。下面的说明先画出这条线，然后才问这条线该由哪台设备来守。

把线画在数据包不再被加密的地方

在隧道模式下，原始数据包被加密，并封装进一个指向对端网关的新外层 IP 头。这个外层包携带 ESP 的协议号 50，因此两个网关之间的任何设备都能转发它，而无需读取内层地址。第一台解密的设备就是安全边界，也是第一台能对内层流量施加策略的设备。该点下游的一切都属于普通路由。

在图上标出三样东西：接纳 ESP 的外侧端点、策略中列明的受保护网段，以及解密后的数据包所走的下一跳。如果这三者不在同一台设备上，你要设计的是一次交接，而不是单一控制点。

RFC 4301 把负责解密的设备称为安全网关，并把它的策略视为边界的一部分。这比按产品类别来理解更有用：一台设备之所以是边界，是因为它持有策略，而不是因为其规格书写着防火墙。

防火墙终结：一台设备，一个策略点

当防火墙终结隧道时，上游路由器只需把 ESP 送达它。防火墙认证对端、解密，然后对前往服务器 VLAN 的内层数据包施加常规规则。这样读策略只有一个地方，读日志也只有一个地方，通常这正是审计所要的。

要分别检查两种许可。允许 IKE 和 ESP 到达设备，与允许远端站点访问服务器，并不是同一条规则；一台接受了隧道却拦截内层流量的防火墙，从远端看与一条坏掉的隧道完全一样。

代价是防火墙现在位于站点全部流量的路径上，因此它的吞吐、会话上限和故障切换行为就成了隧道本身的行为。要按站点合并后的流量来选型，而不是按它当初可能为远程接入而买的配置档位。

路由器终结：检查这一跳变成可选项

当路由器解密时，数据包到达路由表时已经是明文。如果另有一台防火墙要检查这些流量，路由器必须把它送进防火墙，回程也必须原路返回。从路由器直连服务器 VLAN 的路由，会悄悄把防火墙从路径上摘掉，却仍把它留在图上。

这正是要在现网里找的故障：到同一前缀的两条路由，一条经防火墙、一条直连，而直连那条凭前缀长度或度量值胜出。隧道照常通流量，你相信的那道检查却没有发生。

基于路由的隧道让这一点可见，因为隧道本身就是可以经另一台设备路由的接口。基于策略的隧道用选择器挑流量，这可能把解密后的数据包留在路由器上，无处可去。

向两位候选提同样的五个问题

一页简短的清单胜过功能矩阵，因为每个问题都对应图上的那条线。逐个问候选：

• 这个版本实际支持哪些 IKE 版本、哪些对端认证方式和路由模型？
• 本地主机如何学到远端前缀，对端又如何学到你的前缀？
• ESP 在哪里被接纳，解密后的流量又在哪里被放行或拒绝？
• 面对真实负载，端点必须扛住多大的吞吐、多少会话数、怎样的故障切换行为？
• 当出问题的正是隧道时，谁拥有对端凭据、策略和恢复路径？

pfSense 把基于策略和基于路由的 IPsec 记为两种独立模型，各有限制，这个差别比盒子上的标签更重要。要在你真正要上线的版本上，核对准确模式以及对解密流量受支持的过滤能力。

如果某位候选无法用一条你能读懂的规则回答第二个问题，那它就不是你要的边界，其他方面做得再好也一样。要规则原文，不要一句“可以”；含糊的回答按“不行”处理。

用抓包验证路径，而不是用图

图描述的是意图，抓包描述的是行为，所以在相信任何一方之前，先确认哪个接口承载 ESP、哪个承载内层流量。

tcpdump -ni wan0 esp
tcpdump -ni lan0 host 10.60.4.20
ip xfrm policy list

如果第一次抓包显示 ESP 到达，第二次抓包显示内层数据包出现在 LAN 一侧，解密点就在你以为的地方。如果内层数据包出现在绕过防火墙的网段上，那么无论策略文本怎么写，路由都是错的。随后 xfrm 列表会显示装了哪些选择器、朝哪个方向。

回程路径要重复抓包，因为一个站点有两个可能出口时，非对称路由很常见。一个方向能通、另一个方向超时的隧道几乎总是这个原因，远端怎么改策略都修不好。