递归路由：当隧道把自己的数据包抓了进来

隧道起来了，日志显示握手已经完成，可一秒之后同一个会话就断开，并在循环中重新连接。这种情形有明确成因：通往服务器的路由现在指向隧道内部，承载隧道的数据包于是被送进了隧道。认证环节没有任何变化，所以重新输入凭据当然没有用。对比路由变更前后外层路径的变化，递归就暴露出来了。

先检查外层路径

这里涉及两个数据包，而不是一个。内层数据包属于应用，理应被加密；外层数据包的目标是服务器，必须经由一条不依赖隧道的路径抵达它。

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

隧道起来之后，向内核查询通往服务器地址的路由；默认路由变更之后再查一次。如果下一跳落在隧道设备上，那就是递归本身，不用抓包也能看出来。接口绑定、标记或网络命名空间会让普通查询不完整，所以要使用客户端自己所用的上下文。答案看起来正确、会话却仍在循环时，去读路由策略规则，而不只是主路由表。

为什么会话还能撑一瞬间

握手在新路由生效之前就完成了，所以最初几秒看起来一切正常。客户端一加上默认路由，下一个外层数据包就顺着它进入了那个本该承载外层数据包的接口。服务器什么也收不到，客户端不断重传，这次尝试要么超时，要么直接杀掉会话重来。

这个先后顺序解释了为什么同一套隧道在笔记本上能用、在路由器上却失败，也解释了为什么故障往往出现在流量开始时，而不是在连接建立时。它同样解释了循环：每次重启都在路由让连接变得不可能之前先把会话恢复起来。

找出端点例外规则归谁管

受支持的客户端会自己安排例外：要么通过原网关加一条到服务器的主机路由，要么用一个标记把外层套接字留在隧道之外。问题在于，是不是别的东西把它删掉或者盖掉了。

对于基于路由的 IPsec，检查决定哪些数据包进入隧道的策略选择器，并确认对端地址被排除在外。对于 WireGuard，接口的防火墙标记及其策略规则会把传输数据包留在隧道之外，所以手工添加的默认路由可能破坏这套安排。第二个 VPN 配置，或者一个重写默认路由的管理脚本，是常见的元凶。一条条加上去的宽泛绕过规则就是常见后果，它们把路由缺陷变成一张没人维护得动的表。

网络变更后重新检查

经由 Wi-Fi 网关的主机路由在机器换到另一个网络之前都是正确的。换网之后，同样的症状会在配置毫无改动的情况下再次出现。

记下端点的地址、连接前后的路由，以及各自使用的接口。这三项事实通常能把客户端缺陷和被覆盖区分开，而且不会随着收集者离职而消失。

在新网络上重新连接并重复这次读取。如果例外又缺失了，修复它的位置就在拥有它的配置里，而不是故障期间临时敲下的单条命令。