VPN 出口 IP 不是隧道的证明：服务器能看到什么

有人想要一个只有 VPN 用户才能访问的服务，最直白的实现就是放行一份出口地址清单。这份清单确实起了作用：它限制了谁能连进来。但它并不能证明使用了隧道，因为地址属于运营出口的一方，而该运营方可以转发任何人的流量。这两句话之间的落差，正是整个设计问题。

服务器每个连接只看到一个地址

一个连接带着源地址和目标端口到达，这就是网络层所报告的全部内容。当客户端使用隧道时，到达你监听端的包来自出口，或来自出口前面的地址转换。客户端自己的地址通常是私有的，从不会出现。因此，为客户端局域网网段编写的防火墙规则毫无作用。

源地址之后的一切都属于应用数据，应用只能在自己完成认证的范围内信任它。

测试你的出口是什么样子

在写规则之前，先从两端看一遍路径。客户端对自身出口的看法，以及服务器对这个连接的看法，才是真正重要的两个事实。

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

第一条命令报告客户端对外呈现的公网地址，任何允许清单都必须包含这个值。第二条显示服务器上已建立的连接及其对端地址，规则实际匹配的正是它。如果两者与你的心智模型不符，请先修正模型，再修改策略。云数据库防火墙、应用允许清单和负载均衡器各自可能看到不同的转换层。

两组出口地址中只有一组可以被列出

一种情况在请求发生时就可以检查，另一种不能，二者给出的保证完全不同。

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

公开的 Tor 出口清单可以获取并比对，但受清单时效和每个出口自身策略的影响，因此针对已知出口的拒绝规则是可执行、可复核的。商业 VPN 没有同等的登记表。地址会轮换，许多服务商什么都不公布，隧道也可能运行在从未属于任何 VPN 的租用云地址上。你编制的清单只是观察到的地址快照，把它扩大到托管网段只会增加不相干的工作量，并不会增加证明。

把地址当作策略输入，而不是证明

先确定规则的目的。网络限制应当保持狭窄，记录观察到的地址及其日期与理由，并在合法用户的出口变化时给他们恢复路径。访问控制需要经过认证的账户或签名令牌，因为只有这些才能把请求绑定到身份。风险评分可以把地址当作单一不可靠信号，同时接受它的误报和盲区。把规则写成产品决策是诚实的；把它写成一个隧道存在的验证则不是。

反过来，想还原 VPN 背后用户的真实地址，也同样失败：一个连接只携带一个地址，而会话之间的变化可以有多种解释。把先前的值当作历史，而不是事实。