向 AWS VPN 添加本地子网：VGW 与 Transit Gateway 的区别

现有的 Site-to-Site VPN 承载 10.60.0.0/16，同一个本地网关后面又出现了 10.70.0.0/16 的新服务网络，于是有人问是否需要代理。通常并不需要：路由路径可以承载该前缀，但前提是三件事同时对齐，而具体是哪三件取决于你已经在运行的 AWS 架构。虚拟专用网关只有一道路由表边界，中转网关则多出一道。宣告对了而路由表错了，得到的会话看起来健康，却什么也送不到。

宣告一个网关真正能够送达的前缀

在宣告有意义之前，本地网关必须先有新网络的前往路由。通过 BGP 宣告 10.70.0.0/16 只是告诉 AWS 该网段的数据包发往哪里，并不会创建让该网段在另一端可达的本地转发路径。确认网关上有指向持有该前缀的设备的路由，并且该设备已配置为对这些地址作出响应。接下来是导出策略与可接受的前缀上限，因为被会话过滤掉的前缀根本到不了 AWS。

聚合路由与更具体的网段要有意为之。两个方向都出现的重叠路径是设计决策，而不是以后才发现的细节。

路径一：虚拟专用网关的边界

使用虚拟专用网关时，AWS VPN 路由文档描述了两种分发方式：静态路由与 BGP 宣告，两者都取决于应用实际使用的子网路由表。当你控制整个网段时，传播很方便；当你希望目标被并列列出时，显式路由更容易推理。无论哪种情况，检查都一样：具体应用子网的路由表里是否有通往该 VPN 目标、覆盖新前缀的有效路径，并且能否胜过更具体的条目？

健康的 BGP 会话只能证明通道存在，并不能说明某个子网路由表是否接收了这条路由。

路径二：中转网关多出一张表

中转网关把同一个问题拆成两个。VPC 子网必须把目的地送到中转网关挂载，然后中转网关路由表必须为同一前缀选中该 VPN 挂载。关联与传播的选择决定了哪些挂载网络能收到路由，因此前缀可能被 VPN 正确宣告，却始终到不了那张从未关联到正确路由表的 VPC。

常见的故障是一张表里有这条路由，另一张表里没有，而两边团队都确信自己这边是对的。比较这两种架构时，多出来的这道边界就是全部差别：需要查看的地方更多，对谁能收到路由的控制也更精确。

路由传播也不会把前缀给每个挂载，它只分发给配置为接收该前缀的路由表。

回程路径是独立的策略决策

到达的流量只是交换的一半。新的本地网络需要经由正确的网关回到 AWS 源前缀的路由，两端的安全策略都必须允许这对源与目的。如果隧道用流量选择器协商保护范围，新前缀就必须落在其中，否则数据包在查询任何路由表之前就被丢弃。

地址重叠是另一个陷阱。彼此不重叠、归属明确的网段会让事情简单；重叠网段意味着需要转换或重新设计，而这两者都不是同一套做法的可互换变体。

用新网络中的源和应用子网中的目的测试一次，再反向重复一次。单向测试只能证明一个方向。

代理真正是更好边界的场合

当需求是一个狭窄的服务接口、当应用本来就期待这种架构，或者当网络路径无法在不做你不想要的转换的情况下承载该前缀时，代理才有其位置。它并不是没人检查过的路由表条目的备选方案。

按这个顺序判断：本地转发、宣告、路由表边界、回程策略。先修好第一个不通过的地方，然后再问路由路径到底是不是正确答案。