VGW 的 BGP 通告与 VPC 路由表：谁改变了什么

VPC 子网路由表中缺失的前缀和客户路由器上缺失的前缀是两种不同的故障，而只有其中一种能在 AWS 路由表内部修复。虚拟专用网关通告与其 VPC 关联的 CIDR 块；子网路由表则决定工作负载把应答发往哪里。 把第二种当成改变第一种的办法 是这类诊断中最常见的错误岔路。请按顺序执行下列检查，并把两个方向分开。

在读任何表之前，先确认连接类型

站点到站点 VPN 要么终结于虚拟专用网关，要么终结于中转网关，资源 ID 决定了适用哪种路由模型。先读它们：aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'。答案会告诉你，下一张要检查的表是 VPC 路由表还是中转网关路由表。

如果 VPN 挂在中转网关上，就不要再把 VPC 路由表当成控制平面。在那里，VPC 表指向网关挂载点，而关联与传播发生在中转网关路由表中。把两种视角混在一起，会让你对错误的对象得出笃定的结论。

从 AWS 到办公室的方向是通告

对于 VGW 挂载，网关通过 BGP 向客户网关通告与其 VPC 关联的 CIDR 块。新增一条单独的子网路由，或把路由指向对等 VPC、指向某个设备，都不会增加另一个关联 CIDR，也不会出现在那份通告里。如果办公室缺少前缀，请在编辑任何路由表之前，先把收到的路由列表与 VPC 关联做比较。

这条简单规则有例外，所以要把它限定在适用范围里。VPN CloudHub 部署可以在客户网关之间重新通告站点前缀，中转网关也遵循自己的传播规则。VGW 只通告自己 VPC 这个说法是有用的默认值，而不是覆盖你将遇到的所有拓扑的定律。

从办公室到 AWS 的方向是传播加选择

在反方向上，VGW 学到了办公室的前缀，但仅凭这一点并不能让工作负载动起来。子网路由表要么为挂载启用了传播，要么带有一条指向同一目的地的静态路由。当同一前缀两者都存在时，静态路由获胜，而最长前缀匹配会在两者之前执行。

读取来源，而不是假定它：aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'。来源为 EnableVgwRoutePropagation 的条目来自 BGP；来源为 CreateRoute 的条目由人手动输入，在有人删除它之前会一直获胜。

把两个方向分开的操作手册

在改动任何东西之前，先在 AWS 侧记录四个事实：挂载类型、关联的 VPC CIDR、该前缀对应的子网路由来源，以及隧道和 BGP 的状态。同一条 describe 调用会返回 VgwTelemetry，其中带有每条隧道已接受的路由数量，这能告诉你 AWS 究竟有没有接受任何路由。然后把它与客户设备实际安装的内容做比较。存在于 BGP 中却不在转发表里的前缀，是本地导入或最优路径的问题，而不是 AWS 路由表的问题。

如果子网表里完全没有这个前缀，就启用传播或添加静态路由，然后在传播间隔之后重新读取同一条查询，而不是假定改动是立即生效的。如果前缀存在而流量仍然失败，就别动控制平面，转向数据路径。

在那里不要改动什么

不要为了修一个缺失的前缀，就去拨动无关路由表上的传播开关；也不要为了掩盖一个缺失的 CIDR 而添加默认路由。这两种改动都会扩大影响范围，并让下一次诊断更难。把改动限制在为该工作负载子网服务的那张表上。

数据路径与这些全部无关。安全组是有状态的，网络 ACL 不是；主机防火墙或非对称回程路径可能丢掉路由已经正确投递的流量。被通告的聚合路由也不授权其中的每一项服务，所以要在策略边界上限制访问，而不是依赖某个地址是否恰巧出现在 BGP 通告里。

把每次路由表查询的前后状态保存在变更记录里。如果这次改动让情况变糟，就恢复之前的表并撤销路由，因为无法验证的回滚不过是猜测。