如何将 SaaS 流量路由到正确的客户 VPN

某 SaaS 平台连接十几个客户网络，其中两家客户都使用 10.20.0.10 作为主数据库。在任务中收到该地址的工作线程无法判断任务指的是哪个数据库，而共享路由表会乐呵呵地把它发给前缀所指向的任意隧道。解决办法不是增加隧道，而是确定租户身份从何处进入路径，以及地址规划需要哪种隔离模型。三个条件决定选择：客户前缀是否重叠、错误可能扩散多远，以及由谁运营连接器。

两个客户数据库，一个目标地址

IP 地址是位置，不是身份。请求必须携带服务器验证过的租户，而该租户必须在解析目标之前选择网络上下文。

若不然，故障是悄无声息的。连接成功，查询运行，答案却来自错误客户的数据库，因为路由表只有一条 10.20.0.10 的记录。DNS 让它更糟：在租户 A 的上下文中解析过的缓存名称，可能被为租户 B 运行的任务重用。数据包中没有任何东西能区分二者，因此再多的重试逻辑也无法修复。

先决定隔离模型

在比较产品之前先写下这三个条件。重叠决定一个地址空间能否共享；影响半径决定路由错误是支持工单还是安全事件；运营归属决定你能否为每个租户运营一套连接器集群。

如果前缀不重叠且策略允许受控枢纽，那么一个带每租户路由表的 Transit Gateway 是可行的。挂载关联选择从该挂载进入的流量使用哪张路由表，传播决定哪些路由出现在表中。一个只关联自己的表、只传播自己前缀的租户挂载，可以到达枢纽而不会到达其他任何地方。这是路由决策，只要没人向共享表添加默认路由，它就保持正确。

如果前缀重叠，仅靠路由无法将它们分开。你需要为每个租户提供独立的网络上下文，或制定一种让每个客户空间含义明确的转换方案。

Transit Gateway 的隔离究竟意味着什么

关联和传播是两个关键开关，而且很容易混淆。关联回答来自此挂载的数据包在哪张表中查找；传播回答哪些表学习到此挂载的路由。隔离来自让两者都按租户区分，而不是来自创建更多挂载。

默认的全互通配置很方便，但并不是隔离。独立的路由表限制了连通性，但无法让同一个不变的目标地址在同一路由上下文中具有两种含义。如果应用在知道租户之前就解析 10.20.0.10，路由层已经丢失了它需要的信息。

AWS 于 2026 年十月 23 日为 Transit Gateway 和 Cloud WAN 增加了挂载级 1:1 NAT，这改变了受支持挂载在重叠问题上的答案。Transit Gateway NAT 文档介绍了保留主机位的静态、无状态、等前缀 IPv4 映射。在围绕它设计之前，请检查受支持的挂载类型和区域限制。

将任务绑定到经过验证的租户

每个任务都应携带服务器验证过的租户身份，该身份应选择管理员拥有的连接记录。记录中列明已批准的网络上下文、服务地址、凭据引用以及允许的操作。不受信任的请求绝不能提供自己的 VPN 标识、网关或私有目标，因为有效登录并不等于有权探查每个已连接客户的地址空间。

在隔离连接器设计中，租户 A 的工作会进入 A 专属连接器，该连接器运行在 A 的 VPC 中，只能访问 A 已获批准的资源。同一主机上的独立容器本身并不能创造这种隔离；网络命名空间、路由和出口策略必须实现它。连接器还需要限定在租户范围内的凭据和队列，因为私有路由并不限定共享密钥或共享工作项。只要网络上下文和凭据按租户而非按主机选择，共享的应用工作线程就没有问题。

健康检查应指明租户和阶段：隧道已建立、路由存在、真实服务请求成功，是三种不同的信号。把隧道是否在线的数量汇总起来，会掩盖那个连接器损坏的客户。

测试必须失败的路径

上线前运行三项测试。允许的 A 操作必须成功，允许的 B 操作必须成功，而故意指向 B 的连接器或其转换别名的 A 任务必须以失败关闭的方式失败。然后断开一条隧道，确认任务只对该租户失败，而不会回落到另一位客户的同号子网。恢复也应测试，因为过期的路由或缓存的凭据可能比故障存活得更久。

架构可以是带隔离连接器的共享工作线程，也可以是完全分离的租户资源。不变式是一样的：经过验证的租户上下文选择路由和凭据，任何路由变更都不会授予跨租户的应用权限。