在不合并合作伙伴的前提下集中管理伙伴 VPN 接入

这个提议是合理的：五条伙伴隧道散落在十几台笔记本上，五套客户端版本，五份服务台脚本，还有一位了解它们如何咬合的工程师。把它们搬到受控的接入层可以解决终端散乱的问题。与此同时，它也在你的架构里造出一个新对象——一项共享接入服务，如今需要有自己的授权模型；而所有人都低估的失败，是一台启用了全部隧道的中心设备悄悄变成从未同意做邻居的组织之间的中转网络。那个风险是设计选择，不是硬件自己会做的事。下面这些工作，就是我在不接受意外副作用的前提下保留便利的做法。

从每个伙伴已经签署的合同开始

在做任何配置之前，先确认该伙伴是否根本允许共享网关或站点连接。个人远程接入账号、设备状态要求或交互式 MFA 流程，可能无法迁移到无人值守的共享隧道；而把员工塞进一个复制出来的客户端身份，正是那种能一直撑到伙伴审计日志时才暴露的捷径。对每条获准的连接，记录目标网段、私有 DNS 域、获授权的内部来源、认证责任人，以及隧道失效时该怎么办。请伙伴以书面形式确认这条共享连接，包括他们将接受的来源网段。口头批准往往在他们的安全团队换人的那一周就变了意思。

那份记录就是交付物。如果你为某一个伙伴写不出来，那这个伙伴就还没准备好被集中管理。

按上下文路由，而不是只看目的地址

两个伙伴最终会用到同一个私有网段，因为每个组织都从同一个 RFC 1918 空间里挑。一张普通路由表无法只凭目的地址选出正确的伙伴，所以重叠的网段需要独立的路由上下文，或另一种商定的设计。RFC 4364 中的转发域模型说明了这种分离为何重要，而一次部署并不需要跑 MPLS，才能要求网关平台具备同样的性质。

向平台问一个直白的问题：两个伙伴能否共用同一个目的前缀，却仍能按会话来自哪个员工上下文来区分？如果答案是否定的，这条限制对设计的约束胜过任何厂商的功能清单。

在答案是肯定的地方，路由上下文就成了你要记录和测试的东西，因为它在 traceroute 里是看不见的。

决定员工输入什么、伙伴记录什么

有些伙伴工作适合在应用代理里完成，或在属于该伙伴上下文中的远程工作区里完成。另一些工作需要从获批的员工网段获得带路由的网络访问，两者在远端产生的源地址和审计痕迹都不同。共享的转换后源地址可以满足白名单，同时掩盖了哪台设备做了什么，所以要保留可靠的员工与会话对应记录，并保留应用层认证，而不是把网关地址当作身份——那很方便，直到伙伴问起这是谁做的。

然后从员工那边走一遍一个真实任务：他们点什么、被要求输入什么、伙伴若要一条日志会看到什么。如果这一趟走不通、无法复现，设计就还没完成。

明确拒绝伙伴之间的中转

共享硬件永远不应意味着共享信任。把这条拒绝作为一条有指定责任人的刻意规则加进去，而不是当作漏配的意外，并用一条本来会成功的请求从两个方向测试它。测试之所以重要，是因为一个仅仅「不存在」的许可，会被下一个为修无关投诉而加路由的工程师恢复。

把这条拒绝写在伙伴记录里、紧挨着各项许可，这样意图能扛过人员变动。

把它当成共享服务来运营，而不是一台更大的笔记本

隧道续期、凭据轮换、容量和网关更换现在全都成了共享服务的变更，这意味着它们需要单台笔记本从来不需要的排期和沟通路径。伙伴证书在周六过期，不再是一个用户的故障，而是该伙伴所有会话同时中断。

只有当被拒绝的跨伙伴请求按预期失败、被允许的员工请求以正确的源到达正确的目的时，才接受这一层。消除笔记本冲突而保持每个伙伴的边界完整，才是全部意义所在；一个每个办公桌都能到达每个远端前缀的设计，只是把问题挪了地方。

维护一张小表：伙伴、上下文、允许的网段和责任人。出事故时，这会是所有人第一个要的东西。