GCP BYOIP : l’annonce publique n’est pas une route privée
Partager un préfixe BYOIP entre le site et le cloud exige deux plans. Séparez l’annonce publique, la délégation et le prochain saut privé.
Une partie d’un bloc public reste sur site et une partie passe dans Google Cloud. Cette phrase décrit deux plans, pas un : un plan d’annonce sur internet et un plan de transfert privé. Les traiter comme un seul problème de routage, c’est là que les conceptions BYOIP échouent.
Les objets concernés répondent à des questions différentes, et un seul d’entre eux porte sur l’endroit où vont les paquets ensuite.
Trois objets, trois questions
Un préfixe annoncé publiquement est l’unité que Google annonce sur internet en votre nom. Un préfixe délégué publiquement décrit comment l’espace importé est attribué aux ressources Cloud prises en charge. Une route VPC, y compris celle apprise via Cloud Router depuis un VPN, sélectionne un prochain saut privé. Chacun a sa propre portée, sa propre API et son propre message d’erreur.
La version en tableau est plus courte.
| Object | Question it answers |
|---|---|
| Public advertised prefix | Which authorized range Google announces publicly |
| Public delegated prefix | How imported space is allocated to Cloud resources |
| VPN or Cloud Router route | Which private next hop carries a destination |
Seule la troisième ligne concerne le transfert à l’intérieur de votre réseau.
Ce que couvre l’avertissement de chevauchement BYOIP
La documentation BYOIP de Google traite le préfixe annoncé comme une unité d’annonce et signale les annonces externes qui se chevauchent, y compris un sous-préfixe annoncé hors de Google. Cet avertissement concerne le plan d’annonce publique. Ce n’est pas une affirmation sur chaque route privée que vous pourriez ajouter.
Déléguer une allocation plus petite à l’intérieur d’un préfixe importé ne vous autorise pas, en soi, à annoncer le reste depuis une autre origine.
Posez la question en termes de qui annonce quoi. Si Google annonce tout le préfixe importé, une seconde origine qui annonce un sous-préfixe crée exactement le chevauchement que la documentation signale, aussi propres que paraissent vos routes VPC.
Ce que décide une route privée
Un préfixe appris via un VPN n’est pas une annonce internet, et aucune quantité de BGP n’en fera une. C’est une entrée dans une table de routes VPC qui indique quel tunnel ou quelle passerelle doit transporter le trafic vers cette destination. Que cette entrée soit éligible, sélectionnée ou utilisable dépend des règles de routage propres au VPC.
La correspondance du préfixe le plus long s’applique à l’intérieur de la table de routes, si bien qu’une route VPN plus longue peut l’emporter localement sans rien changer en bordure publique.
Partager un préfixe : la décision qui vient en premier
Si l’architecture exige que la moitié du bloc soit annoncée depuis un centre de données et l’autre moitié depuis Google, tranchez le plan d’annonce avant d’importer quoi que ce soit. Confirmez quelles plages Google peut annoncer, lesquelles restent annoncées ailleurs, et si les deux se chevauchent. Concevez ensuite le chemin privé de chaque destination et son chemin de retour. Si les fournisseurs ne prennent pas en charge le partage que vous voulez, changez le partage plutôt que d’espérer qu’un préfixe VPN plus long annule une décision de bordure publique.
Cet ordre compte parce que le second plan ne peut pas réparer le premier.
Vérifiez les deux plans séparément
Vérifiez le côté public avec gcloud compute public-advertised-prefixes list et confirmez les plages et leur état. Vérifiez le côté privé avec gcloud compute routes list et gcloud compute routers get-status, qui montre ce que BGP a réellement échangé.
Un jeu de sorties vous dit ce que voit internet. L’autre vous dit où va votre trafic. Aucun ne remplace l’autre.