Onion 服务与 VPN 服务：不同的访问模型

人们常把 Onion 服务和只能通过 VPN 访问的服务说成同一种想法的两种形式：藏起端口，分享秘密地址。它们的区别在于地址绑定什么、谁能抵达、以及请求到达之前要发生什么。一个是 Tor 内部的会合点，另一个是私有网络内的路由。把两者当作可以互换，会做出既不私密也难以维护的设计。

误区：两种设计只是同一扇暗门

共同点真实但很薄：两种设计都不把管理界面放在可直接访问的公网端口上。其余一切都会分道扬镳。Onion 地址由服务自身的密钥派生，因此名字绑定到身份；VPN 地址只是你被允许进入的某个网络里的地址。一个把服务藏在覆盖层里，另一个把你放进私有拓扑。把后者当成前者的同义词，正是混乱的起点。

这两点都不是应用本身的安全控制。隐藏位置不会修补它背后的软件，私有路由也不会给登录页添加认证。两种设计仍然需要应用自身的权限，也仍然需要有专人负责更新与恢复。

Onion 地址的 v3 版本编码了服务的公钥，因此没有人能为自己无法控制的服务挑选地址。客户端通过 Tor 连接到会合点，服务从自己一侧抵达同一位置；没有任何普通出口节点把这条连接送到服务。名字就是身份，不是 DNS 记录。

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

所以为 onion 名字添加路由或 hosts 条目毫无用处。查询不是机制；Tor 客户端及其电路才是机制。如果服务面向小范围人群，onion 客户端授权可以在接受连接前要求密钥，但那仍然不是应用登录。公布地址同样是有意为之，因为任何得知它的人都可能尝试连接，除非你做了限制。

如果采用 onion 设计的唯一原因是回避配置认证，那就停下来。覆盖层不会提供这一点，而这件事你迟早仍要做。

VPN 把设备接入网络，并给它一条通往网关或子网的路由。网关背后的服务看到来自隧道地址池的地址，并施加自己拥有的授权。路由不说明用户是谁，只说明数据包可以去哪里。

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

这种模型适合设备受管的已知群体，因为网关可以强制设备状态，网络也可以被审计。它不适合匿名或临时访客，那些人得先被登记。已连接用户能读到什么，仍然由应用自身的登录决定。把可达性与权限混为一谈，正是 VPN 最终会把整个子网交给任何能连接的人的方式。

如果受众未知或不断变化，就停下来。为了展示一个页面而把陌生人登记进私有网络，相比发布服务是很大的承诺。

当受众是技术人群、服务完全不该有公网地址、且你能接受 Tor 客户端的要求时，选择 onion 模型。当受众是你管理其设备、并希望在网络层记录其访问的确定群体时，选择 VPN 模型。两种选择都不会消除应用认证、补丁或恢复路径的需要。两者也不会自动在对你用户有意义的层面上更私密。

在两种设计里都写下谁能抵达服务、如何识别他们，以及凭据丢失时会发生什么。onion 服务的答案包括它的客户端授权密钥和地址本身；VPN 的答案包括账户、设备和网关策略。这是两份不同的清单，只有一份会对下一任管理员显而易见。

比较在应用开始的地方结束。隐藏地址和私有路由是传输层的选择，应用仍需决定请求能做什么。把这些决定放进各自独立的文档，两种设计就都不会悄悄接管对方的工作。