Annonces BGP du VGW face à la table de routage du VPC : qu'est-ce qui change quoi

Un préfixe absent de la table de routage d'un sous-réseau du VPC et un préfixe absent sur le routeur du client sont deux pannes différentes, et une seule des deux se répare à l'intérieur des tables de routage AWS. La passerelle privée virtuelle annonce les blocs CIDR associés à son VPC ; la table de routage du sous-réseau décide où une charge de travail envoie sa réponse. Traiter le second comme un moyen de changer le premier est le faux pas le plus courant de ce diagnostic. Exécutez les vérifications ci-dessous dans l'ordre et gardez les deux directions séparées.

Nommez le rattachement avant de lire la moindre table

Un VPN de site à site se termine soit sur une passerelle privée virtuelle, soit sur une passerelle de transit, et les ID de ressources décident quel modèle de routage s'applique. Lisez-les d'abord : aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. La réponse vous dit si la prochaine table à inspecter est une table de routage de VPC ou une table de routage de passerelle de transit.

Si le VPN est rattaché à une passerelle de transit, cessez de traiter la table de routage du VPC comme le plan de contrôle. Là, la table du VPC pointe vers le rattachement de la passerelle, et l'association et la propagation ont lieu dans la table de routage de la passerelle de transit. Mélanger les deux vues produit des conclusions assurées sur le mauvais objet.

La direction d'AWS vers le bureau est une annonce

Pour un rattachement VGW, la passerelle annonce les blocs CIDR associés à son VPC à la passerelle du client via BGP. Ajouter une route de sous-réseau individuelle, ou diriger une route vers un VPC appairé ou un équipement, n'ajoute pas un autre CIDR associé et n'apparaît pas dans cette annonce. Si le bureau manque d'un préfixe, comparez la liste des routes reçues avec les associations de VPC avant de modifier la moindre table de routage.

La règle simple a des exceptions, gardez-la donc dans son périmètre. Un montage VPN CloudHub peut réannoncer des préfixes de site entre passerelles clientes, et une passerelle de transit suit ses propres règles de propagation. L'affirmation selon laquelle un VGW n'annonce que son propre VPC est une valeur par défaut utile, pas une loi qui couvre toutes les topologies que vous rencontrerez.

La direction du bureau vers AWS est propagation plus sélection

Dans la direction inverse, le VGW apprend le préfixe du bureau, mais cela seul ne déplace pas une charge de travail. La table de routage du sous-réseau doit soit avoir la propagation activée pour le rattachement, soit porter une route statique vers la même destination. Quand les deux existent pour un préfixe, la route statique l'emporte, et la correspondance du préfixe le plus long s'exécute avant l'une comme l'autre.

Lisez l'origine plutôt que de la supposer : aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Une entrée dont l'origine est EnableVgwRoutePropagation vient de BGP ; une entrée dont l'origine est CreateRoute a été saisie par un humain et continuera de l'emporter jusqu'à ce que quelqu'un la supprime.

Un runbook qui garde les deux directions séparées

Notez quatre faits côté AWS avant de changer quoi que ce soit : le type de rattachement, les CIDR associés du VPC, l'origine de la route de sous-réseau pour le préfixe concerné, ainsi que l'état du tunnel et de BGP. Le même appel describe renvoie VgwTelemetry avec un nombre de routes acceptées par tunnel, ce qui vous dit si AWS a accepté des routes. Comparez ensuite avec ce que l'équipement client a réellement installé. Un préfixe présent dans BGP mais absent de la table de transfert est un problème d'import local ou de meilleure route, pas un problème de table de routage AWS.

Si la table du sous-réseau n'a pas du tout le préfixe, activez la propagation ou ajoutez une route statique, puis relisez la même requête après l'intervalle de propagation au lieu de supposer que le changement a été immédiat. Si le préfixe existe et que le trafic échoue toujours, laissez le plan de contrôle tranquille et passez au chemin de données.

Ce qu'il ne faut pas changer pendant que vous y êtes

Ne basculez pas la propagation sur des tables de routage sans rapport pour corriger un préfixe manquant, et n'ajoutez pas de route par défaut pour masquer un seul CIDR absent. Les deux changements élargissent la portée de l'impact et rendent le diagnostic suivant plus difficile. Limitez la modification à la table qui dessert le sous-réseau de charge de travail concerné.

Le chemin de données est distinct de tout cela. Les groupes de sécurité sont à état, les ACL réseau ne le sont pas, et un pare-feu d'hôte ou un chemin de retour asymétrique peut supprimer du trafic que le routage a livré correctement. Un agrégat annoncé n'autorise pas non plus chaque service qu'il contient, alors restreignez l'accès à la frontière de politique au lieu de vous fier à la présence fortuite d'une adresse dans une annonce BGP.

Conservez l'avant et l'après de chaque requête sur la table de routage dans le journal des changements. Si le changement aggrave les choses, restaurez les routes précédentes et confirmez avec la même requête, car un retour arrière que vous ne pouvez pas vérifier n'est qu'une supposition.