串联两道 VPN 网关：每一道究竟在决定什么

把两个 VPN 串联起来，通常被当作额外加密来卖，而这恰恰是它最不重要的一项功能。真正的产品是第二个授权决定，由另一位所有者针对另一组资源作出。如果两个阶段接受同一份凭据、抵达同一批目标，内层网关就只是多了一层延迟的装饰。要判断第二个决定是否值得它的运维成本，得先点明每道网关究竟在验证什么。

一条隧道，然后是第二个决定

外层网关回答一个宽泛的问题：这是否是已批准的员工设备，它能否抵达一般内部网络。内层网关回答一个更窄的问题：这个身份是否带有维护权限，它能否抵达这些具体的管理端点。这是两个不同的问题、不同的所有者，任何一方都不蕴含另一方。两道网关之间存在通路，并不等于有权使用第二道背后的东西。抵达远端入口只证明某条路由可用，仅此而已。

这条原则很老，却仍被忽视：网络位置本身不能作为任何理由。 NIST 零信任架构摘要 把这一点说得很清楚，拒绝由连接来源或网络归属推导出的隐式信任。用在这里，抵达内层入口只是使用其资源的前提条件，从来不是使用它们的许可。

写下每道网关验证什么

对每个阶段，记录它检查的身份、它放行的目标，以及可以跳过它的条件。外层网关可以合理地放行普通内部服务加上内层网关的监听端，别的都不行。内层网关可以要求角色声明，并且只放行变更记录里点名的管理地址。远端应用对那个角色能执行哪些操作保有最终发言权，因此这条链只是增加了一道网关，并没有取代应用自身的授权。

两处遗漏会悄悄毁掉设计。如果外层域已经能直达每一个敏感目标，内层网关就是可选项而非必需项。如果还有公开监听端或第二条私有路由提供同样的访问，预期路径就只是若干选项之一。还要为每套规则指定所有者，并让它们的契约点名目标服务、允许的源身份、私有 DNS、地址转换，以及交接失败时由谁应答。外层网络中受信任的地址，绝不能替代内层域的授权。

测试拒绝的情形，而不是顺利路径

成功穿过两道网关的连接证明不了什么，因为那正是上线时人人都测过的情形。有意思的是某一道放行、另一道拒绝的情形。其中三种就能覆盖大部分风险，每一种都有可核对的预期结果，而不必靠争论。

在一般访问已获批准、敏感角色缺失时，普通工作必须继续，同时敏感目标被拒绝。两道都批准时，可达集合应当就是变更记录里点名的维护端点，不能更宽。若权限在会话中途被撤销，约定好的会话策略必须生效，而不能连带拆掉无关的一般访问。这次撤销是立即结束现有会话，还是等到下一次重新认证，属于契约本应写明的策略决定。写验收用例的人，不该是事故中负责解释它们的人。

curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"

数一数你新增的依赖

每多一个阶段，就多一个可能故障的组件，以及一条必须正确嵌套在外层隧道里的路由。部分故障时，外层路径还在，内层却不可达，于是用户看到健康的 VPN 图标，旁边的服务却永远不响应。

要在故障情形下检查路由与阻断规则，而不只是正常情形。外层隧道推送的默认路由可能把内层网关自己的地址也吞进去，让第二阶段变成一条连上又掉线的连接。记录内层隧道缺席期间什么必须保持阻断，因为绕开它发生的意外回退，比干脆的中断更糟。两跳使用同一种探测形式，这样每一跳都是被测量出来的，而不是被假设的。两个“已连接”状态指示，既证明不了嵌套，也证明不了隔离。

第二道网关买不到的东西

要问两道网关是否共用同一份凭据、同一个证书颁发机构或同一个管理平面。如果共用，它们也共用最重要的失效模式，而第二阶段付出的代价，超过它表面上带来的独立性。分开的密码学会话，并不会造出分开的行政管控。

只要内层网关还在强制一项你能陈述并测试的要求——比如外层域从不检查的某个角色——就保留它。当它唯一的工作只是拿同一批目标重新认证同一个身份时，就撤掉它。无论哪种选择，都要把要求、所有者和失效行为一起记录下来，好让下一次评审争论的是要求，而不是图。