转发的 VPN 端口：访问者和服务商分别能看到什么

转发端口让陌生人通过服务商的公网地址找到一条通往服务的路径。这一处改动同时影响曝光度和可识别性，而两者都不会公布服务运营者的名字。把两者分开，可以避免把它们混为一谈的两种相反错误：把'转发'当成匿名，或把转发当成身份认定。三个问题能把它们干净地分开，而答案来自不同的证据。

三个对象，三个不同的问题

把公网地址与在它背后应答的应用程序分开，再把这两者与运营它的人或组织分开。每一个都有自己的受众和证据。混在一起，就会得出听起来整齐、实际错误的结论。

按这个顺序逐一看。第一个是可达性问题，第二个是应用身份问题，第三个是归因问题，而前两个只能部分回答第三个。当有人问端口转发是否私密时，要问清他指的是三者中的哪一个。答案确实不同，而政策页面通常只谈其中一个。

访问者能在不同端点之间关联什么

访问者连上端点，看到应用合法展示的内容：'主机名'、证书名、登录页、已发布的内容。即使常用的访问地址藏在隧道背后，这些细节仍然能识别出该服务。两个展示同一命名站点的端点，为观察者提供了把它们关联起来的依据。这种行为不算泄露，因为应用本来就是设计成被看见的。

两个端点的证书、重定向和页面内容相互吻合，是它们属于同一服务的有力信号。在别的记录把两者连起来之前，这仍然是对服务的陈述，而不是对人的陈述。

IETF 的隐私指引描述了持久标识符如何让交互可以被长期关联。关联并不等于归因，因为一个服务可能由多人管理，地址也可能在互不相关的订阅者之间转移。正是这一区分，让关联结论不至于变成指控。

转发服务商必须知道什么

要投递入站连接，服务商的系统必须持有公网入口与内部目标之间的有效关系。这一运行事实不同于访问者看到的东西，也不同于服务商选择保留的东西。读政策页面时要把这两个问题分开，因为一个是无法避免的，另一个是决定。声明不保留浏览历史，并不说明映射历史。

历史映射、账号关联或连接记录是否留存，属于服务商实际政策与实现的问题。转发并不能证明每一类都被记录。要具体问：映射撤销后哪些字段还在，保留多久。

入站可达性还与客户端的出站路由、DNS 和故障行为分开。增加一条映射，并不能说明客户端其余流量如何出去。

映射持续多久会改变曝光

映射可能持续一个会话、一次预约，或按会改变它的服务商政策而定。既不应假定永久分配，也不应假定持续轮换；读产品文档写明的行为，并记录你观察到的。相隔一周的两次观察，比产品页上任何营销话术都更能说明'轮换'。把观察到的间隔写在笔记里端点旁边，因为间隔本身就是曝光的一部分。

生命周期会改变哪些关联是可能的。稳定的端点会让针对单一服务的长期追踪成为可能，而轮换的端点让每次观察都更难与上一次拼接。两种属性都不能保证服务商的记录，也都不能替代决定服务本身公开什么。

有意识地公开，然后关好两扇门

确认服务商允许你需要的协议，确认目标监听器正是你想要的那个，并确认主机与应用层的控制仍限制访问。发布之前，先看看服务会向陌生人展示什么。下面两条命令展示访问者会收到的证书和响应头。

openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/

公开某样东西，并不等于可以暴露它的管理页面，也不等于可以放弃应用登录；翻译也不会给本来就没有 TLS 的服务加上 TLS。无论流量以何种方式到达，都要保留加密协议及其服务器身份校验。然后检查响应头，因为一条'横幅'或一个调试页面可能向陌生人透露超出服务本意的东西。两条命令返回的，正是观察者得到的同一视角。

让服务退役意味着两道关闭，而不是一道：先通过所有者撤销映射，再把监听器和授权作为两件事分别处理。一个被加进书签的端点停止应答，并不会吊销凭证，也不会收回已经交付的信息。