在更改 GCE 上的 VPN 之前准备串行恢复通道

同一网卡上的第二个 SSH 窗口不是恢复通道。它与你即将更改的路由、防火墙规则和守护进程共用同一套配置，所以它恰好在最需要的时刻失效。在 Compute Engine VM 上编辑 VPN 路由之前，请分别证明三件事：你有权使用串行控制台、你能读到它的输出、来宾系统确实会给你一个登录。下面的检查按这个顺序进行，从最省事的开始，这样缺失的权限会在造成影响之前就被发现。

第 1 步：确认云端权限

写明确切的 VM、项目和区域，然后检查组织批准的串行访问策略。管理员需要相应权限，并且必须在现行的项目和组织管控下为该实例启用交互式串行访问。

不要为了准备一台机器而削弱组织策略，或在整个项目范围内打开控制台访问。请让所有者实验前就安排好被允许的机制，而不是在故障期间才处理。

第 2 步：证明你能读取输出

读取串行输出是最省事的检查，它能在不触碰来宾登录的情况下验证传输通道：

gcloud compute instances get-serial-port-output VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

替换标识符并使用被允许的端口。启动消息和控制台输出说明通道可用。它们不能证明你能拿到 shell。正因如此，这一步才与下一步分开。

第 3 步：证明你能获得交互式登录

连接命令打开的是真实会话，而不是预览：

gcloud compute connect-to-serial-port VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

把它当作实时控制台。输入凭据前先确认目标端点，因为每次按键都会落到实例上。

看似完整的计划正是在这里崩溃。云端权限是一道边界，Linux 登录提示是另一道边界，通过前者并不能说明后者。

第 4 步：准备来宾会接受的凭据

Google 提供的 Linux 镜像默认不启用本地密码登录。因此串行会话可能到达登录提示后就停在那里，等待一个没人设置过的凭据。

必须存在并测试过经批准的恢复账户，或你的部署所用的任何有文档的来宾登录方式。能在网络上使用的 SSH 密钥并不会自动满足控制台密码提示，所以要检查实际的 OS Login 和密钥配置，而不是假定它覆盖了这种情况。

妥善保密恢复凭据。把 root 密码贴进公开的 startup-script 示例，是另一起迟早会发生的事故。

第 5 步：记录所有者和回滚方案

在更改任何东西之前，保留可用的网络配置，并写下由谁管理、涉及哪个 VPN 服务以及如何执行回滚。从可用的会话中抓取当前路由、规则和服务状态。

正是这份记录把恢复通道变成真正的修复，因为控制台只给你一个提示符。要在更改之前写，而不是事后凭记忆补。从 wiki 复制来的回滚不算回滚。那只是一个带版本号的猜测。

第 6 步：更改后验证

已有的 SSH 会话可能在被策略禁止新建连接时仍然存活，所以要用全新的普通管理会话测试。然后单独测试你改动过的 VPN 行为。

在两项检查都通过之前保持恢复通道畅通，之后按访问策略关闭它。如果 SSH 已经丢失且没有准备控制台登录，就不要再把串行访问当作安全网，而要启动经授权的账户恢复或实例修复流程。另起一台 VM 当跳板主机，既修不好来宾路径，也补不上缺失的凭据。