一、跨账号TGW路由重叠：一个被忽视的暗礁与跨账号TGW路由表重叠
故障定位思路
如果你正在处理跨账号TGW路由表重叠，先别急着照搬网上的参数。在混合云与多账号架构日益普及的今天，跨账号VPC互联已成为企业上云的标配。AWS Transit Gateway（TGW）和阿里云Transit Router（TR）作为中心枢纽，极大简化了网络拓扑。然而，当不同账号下的VPC使用重叠CIDR（如多个VPC都使用10.0.0.0/16），或通过TGW共享路由时，路由表冲突就变成了隐形的网络杀手。许多团队在规划阶段只关注IP地址段是否冲突，却忽略了TGW路由表自身的管理规则——这才是导致跨账号互联中断的真正元凶。
本文围绕“跨账号TGW路由表重叠”这一核心痛点，从路由传播原理、优先级决策链、常见陷阱等维度展开，并结合真实踩坑案例，给出可落地的避坑指南。无论你是AWS还是阿里云用户，这套分析框架都能帮你减少90%的路由冲突问题。
进阶阅读：此处可内链到“跨账号TGW路由表重叠性能优化”指南。
延伸阅读：此处可内链到“跨账号TGW路由表重叠配置案例”相关文章。
二、路由重叠的底层原理：一张表看懂TGW的决策逻辑
2.1 TGW路由表的核心结构
TGW本质上是一个可扩展的路由器，每个TGW实例可以关联多个路由表。每个路由表内部包含两类路由：
- 静态路由：手动写入的固定条目，优先级最高。
- 传播路由：通过VPC附件、VPN、Direct Connect等自动学习的路由，受传播策略控制。
在多账号场景下，每个账号通常拥有独立的TGW路由表，并通过资源共享（如AWS Resource Access Manager）或跨账号授权来实现互通。当不同账号的VPC附件向TGW路由表传播相同前缀的CIDR时，路由重叠便发生了。
2.2 路由优先级与最长前缀匹配
TGW遵循标准的IP路由决策：先按最长前缀匹配原则选出精确段，若多条路由匹配同一前缀，则根据管理距离（Static < Propagated）和传播来源（VPC附件 vs VPN）进一步筛选。但这里有一个容易被忽视的细节：当多条传播路由来自不同账号的VPC附件，且路由前缀完全相同时，TGW不会自动合并或负载均衡，而是随机选择一条生效。这意味着同一时刻，只能有一个VPC的流量能正确送达，其他账号的相同网段流量将被错误引导或丢弃。
举个典型例子：账号A的VPC-A使用10.1.0.0/16，账号B的VPC-B也使用10.1.0.0/16，两者都挂载到同一TGW并启用路由传播。TGW路由表里会同时存在两条目的地为10.1.0.0/16的传播路由，但实际转发表中只会保留其中一条（通常是先传播进来的那条）。此时，从其他VPC发往10.1.0.0/16的流量会被全部发往账号A的VPC，账号B的VPC彻底失联。
2.3 跨账号场景下的额外限制
- 传播隔离：AWS中，TGW路由表的传播规则可以精细到附件级别。但在跨账号下，如果管理员未正确配置传播白名单，同一TGW路由表可能被迫接受来自多个账号的重叠CIDR，引发冲突。
- 路由黑洞：当重叠CIDR的传播路由被更高优先级的路由（如静态路由）覆盖时，流量可能被引向不存在的目标，造成黑洞。
- 阿里云Transit Router的差异：阿里云TR支持路由策略（Route Policy），可以通过设置优先级、匹配条件来手动解决重叠，但默认行为下同样遵循最长前缀匹配，且不同账号的相同前缀路由不保证负载均衡。
三、避坑实战：从检测到防御的五步法——跨账号TGW路由表重叠
3.1 第一步：事前检测——用自动化工具扫雷
在VPC挂载TGW之前，强烈建议使用脚本或工具自动比对所有参与账号的VPC CIDR。AWS用户可以利用AWS Config规则或自定义Lambda函数，定期检查不同账号下VPC的CIDR重叠情况，并发送告警。阿里云用户则可以通过资源编排（ROS）或运维编排（OOS）实现类似功能。关键检查项包括：
- 所有VPC的私有IP段（包括主CIDR和附加CIDR）是否存在交集。
- 是否使用了默认VPC的172.31.0.0/16（极易与其他段重叠）。
- VPN或专线对端的本地网段是否与云上已有段冲突。
3.2 第二步：设计阶段——强制唯一CIDR规划
避免重叠最根本的方式是统一规划。建议企业建立“IP地址管理（IPAM）”平台，为每个账号、每个VPC分配全局唯一的CIDR。例如，使用RFC 1918中的分段：10.0.0.0/8可以按账号编号切分（账号1：10.1.0.0/16，账号2：10.2.0.0/16…），并通过策略禁止跨账号使用相同段。如果历史遗留问题无法更改CIDR，则必须考虑网络隔离：将重叠的VPC放在不同的TGW路由域，或使用更精细的传播规则。
3.3 第三步：TGW路由表设计——分段与转发分离
在AWS中，建议为每个账号创建独立的TGW路由表，而不是所有账号共享一张。通过勾选“传播”时仅允许特定VPC附件向特定路由表传播，可以有效隔离冲突段。阿里云TR则可以通过“路由表关联”功能，将不同账号的VPC绑定到不同的路由策略。核心原则是：同一路由表内，不能出现两条指向不同下一跳但目的地完全相同且均为传播类型的路由。若业务必须路由重叠CIDR，则必须使用更精确的子网前缀区分，或用静态路由手动指定下一跳。
3.4 第四步：运维监控——实时捕获路由变化
即使初始设计完美，后续新增VPC或修改路由表也可能引入重叠。建议开启TGW路由表的变更日志（AWS CloudTrail 或阿里云ActionTrail），并结合指标监控（如丢包率、路由表条目数异常），一旦发现路由条目发生变化就触发审计。当检测到重叠时，系统应该自动发出告警并阻止变更（可通过服务控制策略SCP实现）。
3.5 第五步：应急恢复——快速切换路由
如果已发生路由重叠导致故障，可采取以下步骤恢复：
- 暂停重叠的VPC附件传播（先移除一个附件的传播，让路由表恢复正常）。
- 使用静态路由手动指向正确的下一跳（注意静态路由优先级高于传播路由，可以精确控制）。
- 如果无法更改CIDR，考虑使用NAT或代理网关来避免直接路由冲突。
相关阅读：此处可内链到“跨账号TGW路由表重叠常见问题”专题。
补充参考：此处可内链到“跨账号TGW路由表重叠故障排查实例”。
想继续深入：此处可内链到“跨账号TGW路由表重叠优化清单”文章。
四、总结与最佳实践
验证与回滚
跨账号TGW路由表重叠的本质是：同一路由表中的多条传播路由竞争相同前缀，但TGW只能选择一条生效。避免此问题的核心是：规划唯一CIDR、隔离路由域、精细控制传播、以及持续监控。对于已经存在重叠的存量网络，可以采用“网段转换+路由策略重定向”的方案逐步迁移，切勿直接删除原有路由引发更大范围中断。
最后，无论是AWS还是阿里云，都建议在VPC互联方案设计阶段，将路由重叠检测作为必须项纳入Checklist。通过自动化工具与人工审核结合，可以将路由冲突导致的故障率降到最低。毕竟，云网络的高可用不只靠架构冗余，更依赖对路由底层规则的敬畏。真正做好跨账号TGW路由表重叠，靠的不是参数堆砌，而是持续验证。
延伸阅读