自己运行 VPN 服务器时，你把信任交给了谁

自托管把运营者角色交给你：你选择软件、配置、更新计划，以及你自己的服务记录什么。它没有做的是把其他各方从连接中移除。你的接入网络仍在运送数据包，你的托管商仍在运行机器，解析器仍在回答查询，目的地仍会看到一个请求。弄清楚这其中究竟哪一项被你改变了，才是整件事的关键。

第 1 步：盘点各方

列出真实部署中的每一方：你的设备、你接入的网络、VPN 主机、DNS 解析器和目标服务。对每一方，记下它能观察到什么，以及哪些设置由你控制。

这张表比任何关于匿名的说法都有用，因为它显示了控制权究竟在哪里发生了变化。你控制主机的配置和日志。你不控制接入网络对你连接的看法，也不控制目的地会记录关于你账户的什么。

对家庭出口而言，被覆盖的流量通常经由该家庭的接入连接离开。你的目的地看到的出口地址就是这个住户的地址，这是拓扑事实，而不是软件的缺陷。如果你想改变的正是那个地址，家用服务器做不到。你需要别处的出口。

第 2 步：写下你得到了什么

你可以查看已部署的配置、决定哪些设备可以加入、设定诊断策略，并保留你所选择的记录。当你维护它们时，这些才是真正的控制，也是自托管诚实的理由。

它们也是有条件的。未被使用的默认设置和未经验证的备份不是协议提供的属性，而是意图。把控制项和证明它的检查一起写下来，否则它就不算数。

第 3 步：接受维护清单

清单很短，也很不宽容：保护管理员账户、保护服务器密钥、签发并吊销客户端身份、保持备份、移除丢失的设备，并保留一条不依赖失效隧道的恢复路径。

吊销值得单独一行。一个你已从配置中移除却从未吊销的设备，仍持有有效凭据，差别只在有人使用它们时才显现。用旧材料尝试连接，来检验移除是否生效。

备份也需要同样的对待。在备用主机上恢复一个，并确认隧道以相同的身份启动。从未恢复过的备份只是一个文件，不是恢复计划。

第 4 步：放下匿名的假设

运行服务器不会让你的浏览器变得匿名。网站仍会收到账户信息和 Cookie，而 HTTPS 在它自己的路径上保护应用数据，与隧道无关。

还有一个更微妙的影响：只被你使用的地址可能成为与你的使用挂钩的稳定信号。商业出口与陌生人共享，这在某方面不利于隐私，在另一方面却有利。你自己的地址是唯一的，这就把取舍颠倒了过来。

如果目标是难以被关联，自托管可能让它更容易而不是更难。在花一个晚上之前，先决定你真正想要哪种属性。唯一性是一种成本，不是特性，而它在大多数自托管文章里都不出现。把它写进第 1 步的各方表格，取舍就变得可见了。

第 5 步：基于明确理由做出选择

对自己网络的私有访问、对配置的控制、特定的路由需求，或独立于厂商的政策，都是好理由。写下适用的那一个，并设计能证明它有效的测试。

然后验证那些无聊的部分：主机打过补丁了吗，旧密钥清掉了吗，保留策略与你记录的一致吗，故障后你能恢复服务吗？这四个答案比协议名称更能描述信任模型。

第 6 步：规划退出方式

提前决定你将如何迁出该主机：配置放在哪里、客户端配置如何重新签发，以及你保留的记录会怎样。没有退出计划的自托管服务会变成你无法移除的依赖。

AWS 共享责任模型 即使在 AWS 之外也是有用的模板，因为它逼出同一个问题：哪一层是你的，哪一层属于别人。为第 1 步的每一方回答它，信任模型就不再是口号。