当 VPN 运行在路由器上时，STUN 回复揭示了什么

当隧道位于路由器上时，运行浏览器的机器根本没有隧道接口。向这台机器查询本地地址，得到的只是一个私有 LAN 地址和一个回环地址，没有任何像 VPN 地址的东西。然而，远端 STUN 服务器仍然可以就路径报告一些有意义的信息，而它报告什么，完全取决于那个具体请求是如何被路由和转换的。

这正是值得放慢速度的部分。“浏览器并不拥有 VPN 地址”回答的是关于接口的问题，而反射地址回答的是关于一条经过地址转换的路径的问题。把两者混为一谈，就会得出证据并不支持的、关于泄露的笃定结论。

两台设备，两套接口

在基于路由器的部署中，隧道在路由器上终结，LAN 客户端把普通流量发往其默认网关。客户端的接口列表依然很短：一个私有地址，也许还有一个用于其他网络的地址，以及回环。风险不在于其中某个恰好是隧道地址，而在于请求从你并未选择的路径发出。

与其询问存在哪些接口，不如问客户端某个特定目的地会走哪条路由。答案会指出网关以及内核会使用的源地址，这已经比任何地址清单都更有信息量。

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

文档用途的地址段很适合作为测试目标，因为它们永远不会解析到真实服务。把客户端的说法与路由器的说法做对比，任何分歧都视为证据：策略路由、分离隧道规则或第二条默认路由做了你没有考虑的事情。

RFC 8489 定义了 Binding 请求与响应，服务器在其中报告它观察到的该请求的源传输地址。这是关于某一时刻一个五元组的陈述，而不是对客户端接口的普查。因此所有有趣的事情都发生在客户端与观察点之间。

这段空白由路由与地址转换填补。对出站流量做源 NAT 的路由器，会把客户端的私有源地址替换为它在出站接口上的自身地址。如果该接口是隧道，反射器看到的就是隧道地址。如果数据包被排除在隧道之外，反射器看到的就是 WAN 转换所产生的结果。同一个客户端、同一个反射器，答案不同。

有用的区分不是公网与私有，而是由哪个执行点处理了数据包。请打开路由器自身的表来处理这些情况，因为同一个浏览器可能根据你忘记写过的规则产生全部三种结果。

Where the request leaves	What rewrites the source	What the reflector reports
Tunnel interface on the router	Router NAT towards the tunnel address	The tunnel address as seen on that path
WAN interface, excluded by policy	Ordinary WAN translation	The public WAN address
Private reflector reached through the tunnel route	Router NAT towards the tunnel address	An internal identifier valid only inside that path

只有第二种情况违反了“某些流量绝不直接外出”这一要求，也只有第一种和第三种会暴露隧道侧的标识符。这三行都不是对某个特定供应商行为的断言：私有反射器能否到达，取决于路由、对端的允许 IP 地址以及两端的防火墙策略。

在同一家供应商拥有账户并不能证明上述任何一点。同样值得记住的是，如果没有任何设备做转换，被路由的请求可能保留客户端的 LAN 源地址，因此源字段必须被追踪，而不能从拓扑图推断。

WebRTC 会收集候选地址去尝试，而出现在诊断列表中的候选地址可能从未承载过媒体。把该列表读作“对端就是知道了这个”会高估证据。真正承载会话的是被选中的那一对，它位于另一个字段中。

HTTPS 出口检测回答的是另一个问题：Web 服务器为该请求看到的源地址。它之所以是有用的交叉验证，正是因为它使用的协议不同，而且往往目标也不同于 UDP 反射器；两者不一致通常指向路由规则，而不是缺陷。

在测试之前写下意图：哪些流量必须走隧道，哪些可以直接外出，涉及哪些地址族，以及隧道断开时应当发生什么。没有这条基线，每一次观察都是含糊的，因为你无法把泄露与你刻意允许的路径区分开。

然后一次只问一个问题。这个目的地走哪条路由。这个反射器报告哪个地址。会话选择了哪一对候选。把答案放在策略旁边并标注日期，因为一次固件更新就可能以悄然作废去年结论的方式改变默认行为。

路由器仍然是强有力的执行点，因为它能看到客户端在不重新配置自身的情况下无法绕开的流量。这并不是承诺每个应用协议中的每个字段都不泄露任何信息，也不能替代把你选择允许的路径写下来。