双 WAN 的 VPN 策略应该匹配哪个数据包？

把 VPN 改走第二条上行链路的请求，至少描述了两件不同的事，而修好其中一件的策略不会碰另一件。第一件事里，两个端点之间的加密传输换到了另一个 WAN 地址。第二件事里，某个已连入用户的解密应用流投向另一个下一跳。两件事都成立，都用到路由，而且各自都需要在决策所在的位置匹配一个确实存在的数据包。请按顺序做完下面的检查，因为第一项决定了后面的规则该点名哪个数据包。

把两段会话分别命名

设想一位远程员工接在办公网关上，正在向内部应用服务器打开 HTTPS。 线路上同时有两段互不相同的会话，它们在两端的地址也各不相同。外层会话在两个 VPN 端点之间运行：从网关地址到对端地址，协议和端口由本次部署实际协商决定。内层会话从分配给客户端的地址发往应用服务器 443 端口上的地址。

应用的目标端口不是 VPN 的传输端口，在 TCP 443 上堆多少策略都动不了隧道。同样，一条重定向对端传输地址的规则，也不会说明该用户的 HTTP 请求在解密之后去哪里。先不碰任何规则，把两段会话连同各自的真实地址写下来，因为这一带的大部分混乱都来自给其中一段命名、却给另一段做配置。

找出你的策略究竟能在哪里看到数据包

匹配必须在数据包仍处于你描述的那种形态的链和命名空间里求值。挂在 LAN 入向的规则，看到的是尚未加密的内层数据包，而且是在它被路由进隧道之前。 施加于本机产生流量的规则，看到的是网关自己生成的数据包，而它不会自动覆盖网关只是转发的流量。封装后的出向流量又是第三种情况，通常放在承载隧道的接口上处理，而不是 LAN 一侧。

这也是同一段配置在两个平台上行为不同的原因：挂载点不同，而厂商的策略钩子可能位于加密步骤之前，也可能在其后。请针对具体产品读它的数据包路径，不要拿另一家厂商的示意图来假定顺序。

确认你实际协商出来的传输方式

对于以 UDP 封装的 IPsec，RFC 3948把 ESP 放进 UDP 内部，并用一个非 ESP 标记让 IKE 在共享端口上仍可区分。明文 ESP 是 IP 协议而不是 TCP 或 UDP 端口，因此按端口号写的防火墙规则根本匹配不到它。这一区别决定了你的 WAN 策略需要 UDP 规则、协议规则，还是两者都要。

协商出来的值胜过记住的值。从设备上读取当前关联的端口和地址，不要为了保险起见加上 TCP 4500 或某个旧厂商端口，那样会把无关流量一起抓进来，并掩盖真正的分类问题。

提交之前先检查回程

出向成功只证明设计的一半。返回远程客户端池的数据包，一旦被封装替换，就不再以客户端地址的形式可见：外层目的是对端的传输地址。如果第二条上行链路经另一家运营商到达该对端，它的转换和过滤可能与第一条不一致，此时关联可能需要重建，而不是迁移。

网络地址转换状态是 WAN 切换时最常见的受害者。记录选定的上行链路、预期的外层源地址、正在使用的转换以及该对端能否回访，然后在不把传输送进它所承载的隧道的前提下保持可达。

用两次抓包验证两层

在 WAN 接口上抓一次、在隧道内部抓一次，比任何配置比对都更快地定案。在获批客户端只发起一次请求时从网关上执行，并保留两个文件。

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

第一次抓包应当显示外层会话从你预期的接口离开，并带有预期的源地址。第二次应当显示内层会话只出现一次、没有重复，源为客户端地址、目的为应用服务器。路由查询确认路由器会为这对源和目的使用哪张表，策略错误通常就出现在那里。若任一次抓包没有出现，决策点就不在规则所挂的位置，修正也属于那里，而不是更宽的匹配。