你的云 VPN 仍然依赖托管服务商

你安装了操作系统，加固了服务，手里握着密钥，于是开始觉得这台服务器是你的。它确实属于你，就像租来的公寓属于你：门锁归你管，大楼不归你管。虚拟机监控程序、实例前面的网络，以及能够重建这一切的账号，都属于别人。这个区别决定了恢复计划必须覆盖什么，也正是自托管改变得最少的部分。

账号才是真正的控制面

托管账号管理着虚拟机、它的磁盘、快照、公网地址和网络规则。这些都可以在不登录客户机的情况下被更改，因此账号处在大多数 VPN 指南所描述的威胁模型之外。再完美的隧道配置，也扛不住一次替换磁盘的账号操作。

把账号当作独立资产来保护：独立的凭据、基于硬件的第二因素，以及真的有人去读的审计记录。把它和 VPN 服务共用同一条密码管理器记录，是让其他所有控制都变得毫无意义的错误。

要读服务商针对具体产品的责任划分，而不是泛泛的云责任。共享责任模型是说明各层如何划分的一个有用例子，其他服务商描述的是自己的边界，而不是照搬这一套。你要找的是：哪些故障该由你修，哪些你只能上报。

热迁移、宿主机维护、物理节点上的硬件故障和容量事件，都由服务商按自己的时间表处理。你可能看到重启、短暂的丢包或地址变化，却看不到原因。把实例当作固定点的设计，会把其中每一件都解释成 VPN 故障。正确的做法是让服务能够容忍实例消失，而不是去调查一个永远不会告诉你的原因。

备份属于这一层，而不是隧道。把服务器配置、身份、地址规划和允许的路由，放在不依赖实例可达性的地方，并确认在没有原磁盘的情况下也能恢复这份副本。

地址的行为值得单独检查。公网地址能否在停止、替换或删除之后保留下来，取决于它是如何分配的，而这三种操作并不能互换。在事故让这个问题变得紧急之前，先写清楚你依赖的是哪一种。

趁着一切正常就把恢复路径建好。找出服务商提供的控制台或带外访问方式，确认不依赖隧道也能连上它，并把凭据存放在坏掉的笔记本或丢失的手机带不走的地方。如果本地防火墙的改动挡住了隧道，那个控制台就是唯一的回路。

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

元数据服务会回答客户机在其他地方看不到的实例问题，而它的确切路径在不同服务商、不同平台之间各不相同，所以要对照你所运行产品的文档核实。然后对一台测试实例做一次受控重建，并计时。没有人实际执行过的恢复流程，只是一个假设。

留意重建对地址、主机密钥、磁盘身份，以及客户端所固定的一切做了什么。缓存了主机密钥的客户端在重建后会报错，而这种报错是正确行为，不是需要压制的缺陷。

运行自己的 VPN，是把信任从 VPN 运营商转移到托管服务商加上你自己。这是实实在在的变化，但并不等于去掉了第三方。如果目的是不让商业 VPN 观察流量，服务商依然可以观察实例的网络、磁盘和账单记录。

你自己的日志描述的是你的软件，并不描述服务商保留的每一条基础设施记录。反过来也一样：基础设施的可见性并不能证明服务商保留了什么。这两个问题都需要服务商的政策和你自己的配置，谁也代替不了谁。

把答案写成一份分工：哪一层出了故障，谁能修复，修复需要多久。自托管改变的是你信任谁，而这项练习有用的部分，正是确切知道你在哪一层上信任他们。