多租户 VPN：共享网关、每租户还是每主机
隧道不是租户隔离。请从身份映射、路由和退役三个角度，比较共享网关、按租户划分的网关和按主机建立的连接。
先决定由谁来接纳客户，以及是什么阻止该客户触达其他租户的资源。这是两个决定，而选择 IPsec、WireGuard 或某个网状产品，对两者都没有回答。一条完美建立的隧道，仍可能让每个租户都能到达其他所有租户；把两者当成一件事来评审，就会批准错误的设计。先写出“客户到资源”的对应关系：管理员、支持访问、共享服务，以及必须保持拒绝的路径。
从对应关系开始，而不是从产品开始
这张对应关系是第一份产物，下面每个选项只是在决定由谁来守住边界、边界放在哪里。让它可评审：每个客户一行、每项共享服务一行，并把被拒绝的路径逐条写清。
没人读得懂的对应关系，就是没人会执行的对应关系。
单一接纳点及其映射问题
每种放置方式都由同一个运营问题决定，而表格就是全部比较。
| Placement | The question it lives or dies on |
|---|---|
| One shared gateway | How does an admitted identity end up limited to its own resources and its own routing context? |
| A gateway per tenant | Who owns each gateway, its credentials, its policy, its updates and its eventual retirement? |
| A connection per hosted machine | How do enrollment, per-machine policy and replacement work at fleet scale? |
共享网关把接纳集中起来，也把风险集中到一处：租户身份与其策略之间的关联。组或隧道地址必须解析为正确的资源权限，而给每个客户贴不同标签，本身拦不住任何东西。当平台支持且设计完整时，独立的路由上下文可以容纳重叠的前缀。普通的共享路由表无法仅因为背后的人拥有不同账户，就区分两个相同的目的前缀。
这就是大多数设计的检验点。两个都在内部使用 10.0.0.0/8 编号的租户，需要的是分离的路由状态，而不是命名约定。
按租户划分网关，买到的是边界与系统
每个客户一个网关，能让某些管理边界容易解释，因为该客户的接纳与策略放在一起。它也会成倍增加需要凭据、补丁、监控和归属的系统。它并不强制某种规定的公网地址安排：端点共享、地址转换和协议解复用，取决于实现实际支持什么。
先数系统和人数，再数安全收益。比团队能打补丁的数量多出四个网关的设计，在实践中并不更隔离。
如果租户数量每个月都在变，这个模型需要的是自动化方案，而不是模板。
按主机连接会把工作量转移
在每台托管主机上建立连接，并不会消除运维工作，而是把它搬进主机的生命周期。注册、按主机策略、密钥轮换和更换都成为交付的一部分，并且与主机本身在同一时间窗内失效。对少数位于不同网络的长寿命主机，这往往合适；对已经搞不清哪个镜像跑在哪里的机群，则很少合适。
在每个选项下都指名由谁负责身份签发、更新、访问移除、监控和恢复。然后问：某个客户离开的那一天会发生什么。
退役也应纳入比较
大多数比较跳过了退役。移除一个租户，应当让其凭据失效、撤下其策略、释放其地址与路由状态，并且不触碰其他任何人。NIST 的零信任架构指南在这里是合适的参考，因为它把认证与授权放在资源上，而不是信任某个网络位置，这一点在客户自己的网段内部同样适用。
在权衡协议基准之前，先权衡允许与拒绝的流量、重叠地址的处理方式，以及退役流程。然后再选择与所选边界相匹配的传输方式与认证方法。更老的产品名称，或者“所有企业都必须统一到某一种协议”的说法，这些都决定不了。你最先写下的对应关系才能决定。