Un VPN cloud a besoin de BGP : pourquoi les autres protocoles de routage échouent

L'association de sécurité IPsec est montée, les compteurs du tunnel bougent et le trafic vers le préfixe cloud disparaît. L'exploitant tente alors d'activer OSPF sur le routeur client, en attendant que le voisin se forme, et rien ne se passe. Le tunnel n'a jamais été la pièce manquante : un VPN cloud géré expose un contrat de routage défini, et sur les grandes plateformes ce contrat est BGP. Tant qu'une session n'existe pas et qu'un préfixe n'est pas accepté, le tunnel n'est qu'un chemin chiffré sans destinations derrière lui.

Le tunnel est monté et la route manque

L'achèvement des phases 1 et 2 prouve que les pairs s'accordent sur la protection, pas que l'un ou l'autre sait où envoyer le trafic. Ce sont des machines d'état distinctes avec des modes de défaillance distincts.

Posez trois questions dans l'ordre : le préfixe a-t-il été annoncé, a-t-il été accepté par le pair et a-t-il été installé pour le transfert ? Un préfixe annoncé puis filtré est un problème de politique. Un préfixe jamais annoncé est un problème de session ou de configuration. Un préfixe accepté mais non installé est un problème de sélection de route, et chaque réponse pointe une partie différente de la configuration.

Ce que le fournisseur vous fournit réellement

Une passerelle VPN gérée n'est pas un routeur sans restrictions. Le fournisseur vous donne une passerelle avec des adresses de pair prises en charge, un réglage de système autonome, des limites de préfixes et un comportement de défaillance défini. Cette surface est le produit.

Google Cloud documente le routage dynamique BGP pour HA VPN, avec Cloud Router qui apprend les routes des pairs et fournit des routes dynamiques personnalisées éligibles au VPC. AWS Site-to-Site VPN documente un choix entre routage statique et dynamique, et décrit les contrôles de vivacité BGP comme utiles au basculement de tunnel tout en prenant en charge les contrôles d'état pour les appareils sans BGP. Le comportement d'une plateforme ne doit pas être déduit du nom de produit de l'autre.

La conséquence pratique est que vous choisissez d'abord le mode géré, puis que vous lisez les paramètres pris en charge. Une conception qui suppose un type d'adjacence que le service n'offre pas n'est pas un problème de configuration à résoudre sur le routeur client.

La protection du tunnel et l'accessibilité sont des tâches distinctes

IPsec protège le trafic sélectionné pour le tunnel. BGP fournit l'information d'accessibilité qui rend un préfixe éligible. Un tunnel qui fonctionne ne prouve pas que le préfixe attendu a été annoncé, accepté ou installé.

Imaginez une agence qui annonce 10.42.0.0/16 via deux chemins de tunnel éligibles. Retirez un chemin utilisable et le choix de route peut changer sans que personne ne modifie la route de chaque charge de travail. La détection, la sélection de route et la reprise de l'application ne sont pas instantanées et ne sont pas identiques d'un déploiement à l'autre : le test de basculement doit donc observer toute la séquence et non le premier paquet qui passe.

Lorsqu'un préfixe cloud est injoignable, vérifiez l'état de la session et les routes apprises avant de toucher à la cryptographie. Une SA montée sans route derrière elle est la forme la plus courante de ce symptôme.

Où les hypothèses OSPF se brisent

OSPF, IS-IS ou un autre protocole à l'intérieur d'un tunnel IPsec est parfaitement possible sur une appliance auto-hébergée, où vous possédez les deux extrémités et la conception du transfert. Ce fait ne dit rien d'un service géré qui n'offre que BGP comme mode de routage dynamique.

Si une conception proposée exige une adjacence que le service ne prend pas en charge, changez l'architecture délibérément. Les options incluent une appliance auto-hébergée dans le VPC, le routage statique là où le service le prend en charge, ou un autre produit de connectivité. Configurer le protocole sur le seul routeur client ne peut pas ajouter un pair côté cloud qui n'existe pas, et ne fera pas apparaître le préfixe.

Ne transposez pas la réponse d'un fournisseur sur la passerelle d'un autre. Les mêmes mots, comme routage dynamique ou basculement de tunnel, peuvent décrire des mécanismes et des limites différents.

Lisez l'exigence du service, puis concevez

Avant la première ligne de configuration, notez les adresses des voisins, les numéros de système autonome, les préfixes que vous annoncerez et accepterez, les limites de routes et le comportement attendu lorsqu'un tunnel tombe. Ces cinq éléments constituent le contrat sur lequel vous concevez.

Vérifiez ensuite dans le même ordre : session établie, préfixe reçu, route présente dans la table de routage du VPC et flux réel vers une adresse de service. Répétez après un basculement forcé, car une session qui se rétablit peut revenir avec un autre jeu de routes. Si la conception dépend d'une convergence inférieure à la seconde, mesurez-la au lieu de la supposer.

Conservez le contrat de service avec l'enregistrement du changement. Quand quelqu'un demandera plus tard pourquoi le tunnel ne peut pas exécuter OSPF, la réponse est une frontière de produit, non une limitation de protocole, et l'enregistrement devrait le dire.