应用使用 mTLS 和 SSO 后，还需要站点 VPN 吗？
走一遍应用登录永远覆盖不到的通道，再判断访问私有网络是多余的，还是仍是通往主机的唯一路径。
你用 mTLS 登录，仪表盘加载完成，而“站点 VPN 已经多余”的说法听起来还算有道理，直到凌晨两点你需要恢复数据库。应用的 TLS 边界只描述了一条通道。主机、数据库、备份目标和云账号各自拥有自己的入口路径、自己的身份和自己的审批人，而这些都不在成功登录的覆盖范围内。
从登录页面向外走
像普通用户那样登录，写下请求经过的每一跳：浏览器、边缘、应用监听器、会话存储、后端 API。每一跳都有负责人和一项认证决策。现在为给主机打补丁的人、为编写夜间备份的任务，再走一遍。这两条路径往往在第一跳就分岔。
这个分岔正是值得回答的问题。只有当第二条路径上的每条通道都有独立成立的门禁与授权策略时，站点 VPN 才是多余的。
应用登录永远覆盖不到的五条通道
下表是清点模板，不是部署检查单。第二列请填入你自己的环境今天真正执行的做法。
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
共享同一个身份提供商并不会把这些授权合并。能提交 API 请求的用户，并不因此有权替换虚拟机磁盘，或用应用的凭据恢复数据库。NIST 在零信任架构摘要中正是因此把资源认证与授权同网络位置分开。
能读取工单的支持工程师，并不因此有权在其背后的主机上打开控制台。
替代路径保持关闭，路径才算真实
把可达性限制在私有管理监听器上，是站点 VPN 的正当替代，前提是限制被真正执行，而不只是画在图上。常见的失败是一个没人记得的替代监听器：仍绑定在所有接口上的服务、为承包商打开的安全组规则、可从互联网访问的管理端口。
检查监听器，而不是看拓扑图。在主机上，用 ss -ltnp 列出真正绑定的东西，并确认管理端口位于私有地址。在云控制台里，读取工作负载子网的入站规则，看看任何管理用途的东西上有没有 0.0.0.0/0。然后从私有路径之外发起连接测试，因为只有这个测试能回答问题。
SSH 上一条对全世界开放的规则，就能推翻隧道设计的全部论证。
先画地图，再比较方案
对清点表的每一行，记录谁审批身份、谁更新访问规则、谁在人员离开时移除凭据、谁在路径本身中断时负责恢复。每行四个名字，就足以暴露那些答案只是共享账号和三年前的 wiki 页面的行。
然后为每条通道各验证一次放行和一次拒绝。放行证明预期身份能沿预期路径到达资源。拒绝证明相似身份不能，而这正是人们常跳过的一项测试，替代监听器因此才熬得过审计。把所提方案与这些结果比较，而不是与应用从未真正验证过的 TLS 配置比较。
站点 VPN 仍然值得保留的地方
当资源自身没有逐请求认证时，隧道或窄网关才是正确答案：数据库维护端口、备份目标、虚拟机管理控制台、带外管理。这些监听器信任网络，所以必须由网络来认证调用方。
这不是唯一答案。在资源层面终止授权的网关可以比整段子网的隧道更窄，并且留下比共享跳板机更好的审计痕迹。
工作顺序：完成清点、关闭替代路径、为每一行验证一次拒绝，然后才下线隧道。如果某一行无法给出拒绝，就保留私有路径，直到它能给出为止。