Les adresses BGP de Cloud VPN appartiennent au tunnel, pas à une carte réseau

Ouvrez la page Cloud Router du VPN et une session BGP avec une adresse dans 169.254.0.0/16 vous fixe. La réaction naturelle est de placer cette adresse quelque part sur la VM et d'attendre que la session monte. Cette réaction est fausse d'une manière précise : la paire appartient au lien logique que crée le tunnel IPsec, pas à l'interface réseau ordinaire de la machine. Rien de ce que vous ajoutez à la carte réseau ne fait transporter BGP au tunnel.

Suivez la paire dans la pile au lieu de l'ajouter à l'hôte.

Commencez là où la console affiche la paire

La page de session liste une adresse BGP du Cloud Router et une adresse de pair, toutes deux link-local pour un HA VPN IPv4. À côté se trouvent les adresses de passerelle externes qui terminent les tunnels. Ce sont des objets différents : la paire link-local vit à l'intérieur, et les adresses de passerelle vivent à l'extérieur et doivent être routables avant que quoi que ce soit d'autre ne fonctionne.

Notez les trois avant d'ouvrir un fichier de configuration, car les confondre est tout le mode de défaillance.

Descendez jusqu'au tunnel qui la porte

La paire link-local ne signifie quelque chose qu'une fois qu'une association de sécurité IPsec existe entre les deux passerelles. Côté Google, les tunnels HA VPN la créent sur les deux interfaces ; côté vous, c'est ce que le pair a négocié. Vérifiez d'abord l'association de données avec swanctl --list-sas et notez quel tunnel est actif sur quelle interface, car une session BGP saine sur un tunnel mort est impossible et un tunnel mort avec une configuration pleine d'espoir est courant.

Le paquet BGP est du trafic IP interne. Le réseau externe ne le voit jamais, donc aucun commutateur n'a besoin des deux adresses sur un même VLAN.

Configurez maintenant le pair Linux pour qu'il corresponde

Choisissez la conception de tunnel prise en charge et laissez-la décider des adresses internes. Avec une interface basée sur le routage, l'entrée de routage et les sélecteurs de trafic négociés doivent s'accorder, car un nom d'interface seul n'autorise rien. Pointez BIRD vers l'adresse locale interne et l'adresse interne du Cloud Router, définissez les numéros AS depuis la page de session et autorisez TCP 179 dans le chemin protégé. Gardez la route vers l'adresse externe lointaine sur l'uplink physique pour que le tunnel ne capture pas son propre transport.

Un tunnel qui se route lui-même est une boucle avec une poignée de main, et il ressemblera à un problème de pare-feu pendant une heure.

Vérifiez chaque étape dans l'ordre, pas le tout d'un coup

Parcourez les étapes : association de sécurité active, pair interne joignable depuis l'adresse du tunnel, session BGP établie, préfixes acceptés, puis un préfixe de charge de travail réellement utilisé. birdc show protocols répond à la troisième question et à rien d'autre, et c'est pourquoi les gens déclarent la victoire trop tôt.

Un voisin établi ne promet pas que les deux côtés ont annoncé les préfixes dont vous avez besoin, ni que ces routes ont été installées comme préférées.

Si la session est établie et que le trafic prend toujours le mauvais chemin, comparez les préfixes annoncés avec ce que la table de routage en fait. Une route plus spécifique ailleurs, ou une préférence pour un autre chemin, vous donne une session BGP fonctionnelle et aucun transfert utile.

Arrêtez-vous avant d'appliquer ceci à Router Appliance

Network Connectivity Center Router Appliance est un modèle de rattachement différent. Ses pairs Cloud Router utilisent des adresses internes issues de l'agencement VPC et sous-réseau plutôt que la paire link-local du HA VPN. Si le but réel est BGP avec une VM de routage, suivez les exigences d'interface de ce produit au lieu de copier une session link-local.

La portée link-local signifie toujours ce qu'elle dit. Le tunnel logique fournit cette adjacence, et il n'autorise pas à router des destinations link-local arbitraires à travers le VPC.