把公司 Web 应用移到 VPN 之后：切换演练指南

从用户这一侧想象这次变化。有人点开收藏夹，期待熟悉的登录页，结果却收到连接错误，因为主机名现在只在隧道内应答。就这一瞬间，已经把迁移计划必须做对的每一件事都装了进去：名字、路径、证书、账号，以及它背后的操作。按下面的顺序走完这些步骤，切换就不再是一次跳跃。

第 1 步：写下用户今天在做什么

从地址栏里的主机名、端口、人们执行的操作和他们使用的账号开始。如果你说不出最重要的三项操作，就还没准备好关闭公网入口，因为验收时你会认不出哪一项坏了。

然后决定私有受众是谁。企业 VPN 上的员工只是起点，不是答案。承包商、支持人员和财务团队可能都需要这个应用，也可能并不都坐在同一个网关后面。

第 2 步：把隧道和登录分开

当用户通过 VPN 访问应用时，浏览器仍然与应用自己的端点建立 TLS 连接。证书必须与该名字匹配，应用仍然要对账号做认证。隧道不会替代其中任何一项。

迁移往往就在这里悄悄出错。有人认定私有地址不再需要有效证书，用户学会了点过警告继续，组织就用一次公网暴露换来了一堂「无视安全提示」的培训课。如果应用确实需要内部证书，就向内部机构签发，并正确分发信任。那是受控的变更；警告页不是。

授权要留在它本来所在的地方。NIST 的零信任架构摘要把这一点说得很直接：网络位置不是授予敏感操作的理由。待在隧道里，不该把只读账号变成管理员。

第 3 步：找出不是员工的调用方

打开应用的配置，列出所有与它通信的东西：身份提供方的回调 URL、支付提供方的 webhook、定时导入、监控探针、合作伙伴的 API 客户端。每一项都是有归属的依赖，每一项都会在不同时刻断掉。

为每一个必须保留的调用方确定受支持的路径。webhook 提供方无法加入你的员工 VPN，所以要么暴露一个范围很窄、自带认证的集成端点，要么改变集成模型。因为存在一个回调就把整个应用公开，是一种选择，而且通常是错误的选择。

把每个例外连同目标、允许的操作、认证方式和负责人一起写下来。给集成发放通用 VPN 账号，正是例外变成永久的方式。下次访问复核时把清单过一遍，因为集成比添加它们的项目活得更久。没有到期日的例外，就是没人真正做过的永久设计决定。

第 4 步：下线公网路由，而不只是 DNS 记录

走一遍发布链：DNS、负载均衡器监听、反向代理规则、主机防火墙，以及任何仍指向旧地址的备用名。两种地址族都要检查。如果旧的 CNAME 或 IPv6 监听仍在服务，改主 A 记录几乎证明不了什么。

同时确认私有名字在隧道内能解析，并且证书覆盖用户将要输入的名字。被迫粘贴数字地址的用户，发现的是症状，不是解决办法。

把 VPN 受众收窄到应用路径。对办公网的宽泛访问是用一个暴露决策换一个更大的暴露决策，管理界面需要自己的允许来源，而不是继承用户规则。

第 5 步：亲自走一遍验收

以获准用户的身份连接，打开收藏夹，检查证书，登录并执行一次真实操作。然后用一个本不该拥有该操作的账号去试，确认被拒绝。再从 VPN 之外的设备试，确认应用不可达。

对每个保留的集成重复一遍，并且去读提供方的投递日志，而不是假定你自己测试工具里的 200 是同一回事。VPN 登录成功不是这些结果中任何一项的证据。

第 6 步：演练糟糕的那一天

决定隧道中断时会发生什么：工作停下来，或者另一种获准的访问方式接手。无论选哪种，都写下来并测试一次，因为把紧急重新公开当作未记录的恢复手段，最终一定会有人在压力下这么干。

为维护网关和应用的管理员保留恢复访问，并写明负责人和移除日期。把变更及其回退条件记在同一个地方，这样失败的迁移不会把本该修复它的人锁在外面。

切换之后，打补丁、账号生命周期、应用授权和审计仍然是你的事。隧道收窄了入口，它没有接手其中任何一项工作。