Pourquoi votre session BGP n’apparaît pas dans la table de routage de la VPC

L’histoire qui revient sans cesse, c’est qu’un démon de routage sur une appliance VPN EC2 apprendra à la VPC ses préfixes distants dès que BGP montera. La moitié est vraie. La session monte, et rien ne change dans la table de routage de la VPC à cause de cela, ce qui explique que le premier symptôme soit généralement un sous-réseau qui envoie silencieusement le trafic dans un trou noir.

Deux choses différentes sont confondues ici : le peering avec un serveur de routage et l’installation de routes dans une table.

Le mythe : montez BGP et la VPC apprendra les préfixes

BGP est une conversation entre deux interlocuteurs, et dans cette conception les interlocuteurs sont le démon de routage de votre appliance et un point de terminaison VPC Route Server qu’AWS place dans un sous-réseau qui vous appartient. Cette conversation transporte des préfixes. Elle ne touche pas la table de routage de vos sous-réseaux de charge, car ces tables n’apprennent que par la propagation, qui doit être activée sur chacune. Tant que ce n’est pas fait, la fabrique de la VPC ne sait rien de ce que l’appliance sait.

Les étapes de configuration sont séparées pour une raison : associer, créer le point de terminaison, appairer, puis activer la propagation.

Route Server est un plan de contrôle, pas un tunnel

Route Server ne chiffre, ne transmet et n’inspecte pas un seul paquet. Il existe pour échanger BGP avec l’appliance et remettre les préfixes obtenus aux tables de routage configurées pour les recevoir. Le plan de données est inchangé : les paquets sortent toujours par l’interface réseau de l’appliance, traversent son VPN et reviennent par le même chemin.

Cela signifie que la vérification de source et de destination sur l’instance de transfert compte toujours, car l’instance transfère désormais du trafic adressé à quelqu’un d’autre.

Les groupes de sécurité et les contrôles de sous-réseau s’appliquent aussi au flux transféré. Route Server ne forcera pas une appliance qui jette le trafic à le transmettre, et il ne réparera pas une route de retour manquante côté distant.

La propagation est par table de routage, pas par VPC

Associer le serveur de routage à la VPC et activer la propagation sur une table de routage sont deux décisions, et seule la seconde change ce que fait un sous-réseau. Une VPC avec six tables de routage peut recevoir un préfixe propagé dans une et pas dans les cinq autres, ce qui est exactement correct pour un sous-réseau concentrateur et exactement ce qui produit le résultat déroutant de « fonctionne à moitié ». Même là où la propagation est active, une route concurrente peut gagner, car la sélection de route de la VPC préfère le préfixe le plus long et, à longueur égale, préfère une route statique à une route propagée. Cette préférence est appliquée en silence.

Vérifiez la table effective du sous-réseau concerné plutôt que la liste des préfixes annoncés par l’appliance. L’API répond directement à cette question : aws ec2 associate-route-server et aws ec2 enable-route-server-propagation --route-table-id <id> sont les deux étapes que les gens oublient, et aws ec2 describe-route-tables --route-table-ids <id> indique si le préfixe est bien arrivé comme entrée de route server.

L’appliance transporte toujours chaque paquet

Annoncer la joignabilité n’est pas la même chose que l’avoir. Une session BGP peut rester établie alors que le VPN de l’appliance est en panne, et une annonce statique qui ne change jamais continue d’attirer le trafic vers un chemin mort. Route Server prend en charge la détection de défaillance comme BFD, mais cela teste la vivacité du pair, pas la santé de tout ce qui se trouve derrière.

Liez l’annonce à la vraie route distante : annoncez le préfixe quand le tunnel et le réseau distant sont opérationnels, et retirez-le quand ils ne le sont pas.

Retirez un préfixe et regardez ce qui se passe

Testez par étapes, et faites de la dernière étape un retrait. Confirmez que l’annonce arrive, que le préfixe apparaît dans chaque table prévue, que l’appliance est le prochain saut, que le transfert traverse le tunnel actif et que l’extrémité distante répond. Retirez ensuite un préfixe de test, ou fermez un tunnel approuvé, et observez si le trafic se déplace là où la conception le dit. Notez les tables avant et après pendant que le test est encore ouvert.

Déplacer une route vers une seconde appliance ne déplace pas les sessions qu’elle portait, car l’état NAT et pare-feu reste sur le premier équipement.

Pour un ensemble fixe d’une douzaine de préfixes, les routes statiques dans les tables de la VPC restent la réponse la moins chère. Route Server gagne sa place lorsque la liste des préfixes change vraiment et que la politique de retrait est quelque chose que vous pouvez expliquer à la personne d’astreinte.