在 AWS Transit Gateway 上用一条站点到站点 VPN 连接多个 VPC

本季度有两个 VPC 需要办公室网络，而预算正是在第二条隧道上崩掉的。AWS Transit Gateway 可以充当共享路由中枢：VPN 只挂接一次，每个 VPC 都挂到同一个中枢上。此后本地网络通过一条连接就能到达每一个已挂接的 VPC。这改变了路由决策归谁所有，而这正是大多数设计搞错的部分。

VPN 挂接和 VPC 挂接是同一个网关上的不同对象，因此路由关系必须随后再建。

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

为什么对等连接不是大家期待的那条捷径

诱人的替代方案是把 VPN 终结在 VPC A 上，再把 VPC B 对等连接到它。普通的 VPC 对等连接不提供经由 A 的 VPN 连接的两端互穿。对端只能到达对等连接本身提供的地址，而 VPN 边缘并不在其中有。中转是中枢给的，对等连接给的只是一对。

这条限制是对等连接的属性，不是可以调高的配额。

关联和传播做的是不同的工作

在中转网关内部，关联决定用哪张路由表去查找从某个挂接进来的流量。传播决定哪些表会收到某个挂接学到或连上的前缀。同一个挂接可以只关联一张表，同时向多张表传播。把这两件事搞混，设计最后就会得到没人计划过的可达性。

全互联的小型中枢是简单情形。

把每个挂接都放进同一张表，VPN 和两个 VPC 前缀就干净地解析出来。这同时允许了组织可能从未打算过的 VPC 互通，因为共享表中没有分支这个概念。

工作负载的路由住在别处

每个工作负载子网仍然需要自己的、通往中转网关的路由，用来指向既定的本地前缀。那些 VPC 路由表与中转网关自身的表是彼此独立的对象。加上需要的前缀，并保留已有路由，而不是用一条新的默认路由替换每个目标。子网路由同样不会向客户设备通告任何东西。

动态路由还是静态路由要刻意选择；对等连接两者都不提供。

隔离分支又不丢掉本地访问

当 A 和 B 都能到达办公室、但彼此之间不应互通时，就把表拆开。VPN 挂接所关联的表放 VPC 前缀。VPC 挂接所关联的表放本地前缀，其中没有把 A 和 B 连起来的路由。这种关系由传播产生，所以你永远不必接受每一条默认关联。

这是路由隔离，不是应用层授权。

安全组、网络 ACL、主机防火墙以及每个服务自己的权限仍然决定哪些流量被放行。如果需要检查，就明确设计它受支持的路径，而不是假定中枢会去做。

中枢修不好的东西

地址规划仍然不能重叠，因为中枢不允许一个前缀指向两个工作负载。每个 VPC 挂接都需要其工作负载所期望的可用区覆盖。使用 BGP 时，客户设备回到每个必需前缀的路由必须与设计及其导入策略一致。缺一条通告看起来就完全像隧道坏了。

VPN 连接和中转网关现在是共享基础设施。

规划隧道冗余、设备容量、监控和维护时，要围绕所有依赖的 VPC，而不是把每一个都当作独立连接。

从现有的虚拟私有网关方案迁移也值得同样明确的计划。先建好挂接和策略，迁移一条受控的工作负载路径，并在下线旧路径之前确认被允许和被拒绝的关系。集中化在让网络团队有一处管理共享连接时有帮助，在把谁可以到达谁藏在一张大表后面时则有害。