La route GCP VPN ne fonctionne que dans une région : vérifiez le routage dynamique

La charge de travail américaine atteint le préfixe du bureau via le HA VPN sans problème, tandis que la charge européenne dans le même VPC ne reçoit rien du tout. Son table de routage ne contient aucune entrée pour ce préfixe, aucun tunnel n'est tombé et aucune règle de pare-feu n'a changé. Le tunnel et sa session BGP sont sains dans les deux sens. Un VPC qui couvre plusieurs régions n'est pas la même chose que ses routes apprises qui couvrent plusieurs régions, et cet écart explique tout le symptôme.

Deux propriétés sont confondues ici : où se trouvent les sous-réseaux et où un saut suivant appris peut être utilisé.

D'où vient la portée régionale

Cloud Router installe les routes apprises avec une portée qui suit le mode de routage dynamique du VPC. En mode régional, une route apprise dans une région n'est utilisable que par les ressources de cette région, c'est pourquoi la table européenne est vide au lieu d'afficher un saut suivant cassé. En mode global, les routes apprises éligibles deviennent disponibles pour les ressources de chaque région du VPC. Lisez la valeur actuelle avant de changer quoi que ce soit, car le régional est la valeur par défaut. Le réglage se trouve sur le réseau, pas sur le tunnel ni sur le routeur.

La commande d'inventaire est en lecture seule et y répond en une ligne :

gcloud compute networks describe VPC_NAME --format='value(routingConfig.routingMode)'

Exécutez-la dans le projet hôte lorsque le VPC est partagé. Le réseau appartient à ce projet, et un rôle de lecteur dans le projet de charge peut même ne pas afficher la configuration de routage. Une réponse rapide du mauvais projet est pire que pas de réponse.

Le changement est une commande et une direction

Le basculement est une modification du plan de contrôle à l'échelle du VPC, pas un contournement par VM : gcloud compute networks update VPC_NAME --routing-mode=GLOBAL. Il est aussi irréversible, car un réseau réglé sur global ne peut pas revenir au régional. Vérifiez encore une fois le nom du projet et du réseau avant de l'exécuter, puisque la commande ne demande pas de confirmation. Le changement mérite une note de maintenance et l'accord du propriétaire du réseau, pas une expérience rapide sur un VPC partagé.

Chaque attachement Cloud Router, VPN et Interconnect de ce réseau hérite aussitôt de la nouvelle portée. Cela inclut les attachements que personne n'a mentionnés dans la demande de changement. Les régions qui n'avaient jamais eu la route auparavant commencent à la recevoir dès que le changement prend effet, c'est pourquoi il n'y a pas de déploiement progressif pour ce basculement.

Global est une portée, pas une garantie

L'éligibilité et la préférence sont distinctes de la portée. Une route qui entre en conflit avec un préfixe plus spécifique, perd la sélection du meilleur chemin ou est filtrée par une politique se comporte exactement comme avant. Le mode global élargit l'endroit où une route peut être utilisée, mais ne décide pas quelle route gagne. Une route apprise peut être dans la portée et perdre malgré tout face à un chemin statique ou plus spécifique sur le même VPC.

Cette distinction compte parce que le changement de mode est facile à blâmer plus tard. Si le sous-réseau européen n'a toujours pas de route après le basculement, la question est de savoir si la route existe et est éligible, pas si la portée a pris effet. Les conflits de préfixes et la santé du saut suivant sont les deux choses à lire ensuite.

Le côté distant annonce lui aussi différemment

Le comportement d'annonce suit le même réglage. Avec le comportement par défaut, un routeur en mode régional annonce les sous-réseaux de sa propre région, tandis que le mode global annonce les sous-réseaux du VPC plus largement. Changer le mode modifie donc non seulement ce que vos propres régions peuvent utiliser, mais aussi ce que le côté distant installe.

Une liste d'annonces personnalisée ne s'élargit pas lorsque le mode change. Si le routeur local conserve une liste de plages écrite à la main, le préfixe européen y reste absent. Le chemin de retour reste cassé dans ce cas même si la route sortante existe désormais. Vérifiez ce que le côté distant a installé plutôt que ce que vous avez exporté.

Ce que le mode ne réparera jamais

Le routage global n'accorde pas d'accès à l'internet public, de transit entre VPC non liés ni de routes statiques manquantes. Il ne modifie ni les règles de pare-feu ni IAM, donc une connexion refusée par la politique reste refusée.

Ces échecs se ressemblent vus de l'intérieur d'une charge de travail et n'ont rien à voir avec la portée des routes.

Testez depuis la région distante vers le service réel, puis confirmez que la réponse revient par le tunnel prévu. Notez le mode, la configuration d'annonce et la destination testée. Si le test échoue encore, comparez la table BGP du routeur distant à la liste des routes du VPC avant de toucher à nouveau au mode. Le prochain rapport interrégions partira alors de faits et non d'un changement de mode.