GCP HA VPN : session BGP bloquée sur Waiting for peer, l'inversion du couple d'adresses

Une session BGP qui n'atteint jamais Established sur un tunnel Cloud VPN n'est généralement pas un problème de routage. C'est un problème de câblage : deux adresses qui doivent se répondre ont été saisies dans le mauvais ordre, ou le couple du premier tunnel a été réutilisé sur le second. Le tunnel lui-même peut être parfaitement sain alors que la session reste sur Waiting for peer, car IPsec et BGP sont des négociations distinctes entre les deux mêmes extrémités. Décidez laquelle des deux est en panne avant de reconstruire quoi que ce soit.

Une question règle la plupart des cas : le dispositif pair voit-il seulement l'adresse du Cloud Router ?

État du tunnel et état de la session sont deux vérifications différentes

IKE et ESP viennent d'abord. Si le tunnel n'est pas établi, rien de ce qu'il contient n'a d'importance et la discussion sur l'adresse BGP est prématurée. Lisez l'état et l'état détaillé du tunnel, puis l'état du pair BGP du routeur pour ce même tunnel.

Un tunnel qui est up alors que son pair BGP est down circonscrit la panne à la session : adresse du pair, ASN, ou TCP 179 qui arrive sur l'adresse interne. Un tunnel up, une session up, et toujours aucune route dans le VPC est un troisième cas. Changer les adresses n'y aidera pas, car la session fonctionne déjà et le préfixe n'est simplement pas annoncé ou pas préféré. Distinguer ces trois cas représente l'essentiel du travail.

Chaque tunnel a besoin de son propre /30, avec les deux extrémités renseignées

Chaque tunnel HA VPN reçoit un /30 link-local pris dans 169.254.0.0/16, une adresse sur l'interface du Cloud Router et l'autre sur votre pair. Le champ pair doit désigner l'extrémité distante, jamais l'adresse du routeur lui-même.

Deux tunnels signifient deux interfaces sur le Cloud Router, chacune avec un /30 différent. Réutiliser le couple du tunnel 0 sur le tunnel 1 est l'erreur qui paraît propre dans un tableau récapitulatif et meurt dans le paquet OPEN.

Lisez le couple depuis la ressource du routeur plutôt que depuis le résumé de la console. Le résumé affiche l'adresse du pair dans une colonne facile à mal lire, et l'ipRange de l'interface plus le peerIpAddress du pair doivent décrire les extrémités opposées d'un même /30.

L'inversion se produit généralement lors d'une reconstruction

C'est en reconstruisant un tunnel que les couples se croisent. L'adresse du pair de l'ancien tunnel est copiée dans le champ interface du nouveau, ou la nouvelle session pointe vers le pair de la précédente. Dans les deux cas, le Cloud Router envoie des paquets OPEN vers une adresse qui est désormais lui-même ou vers une adresse sans tunnel derrière elle.

Notez les couples avant d'ouvrir la console : nom du tunnel, interface, adresse du routeur, adresse du pair, ASN du pair. Créez ensuite les deux tunnels d'un seul passage, pour que le second ne soit pas rempli avec les restes du premier.

Trois autres raisons pour lesquelles une session attend

L'ASN du pair vient en premier : chaque côté doit être configuré avec l'ASN de l'autre, et une divergence atteint le pair sans jamais s'établir. La deuxième est le pare-feu du pair lui-même, qui doit autoriser TCP 179 sur l'interface du tunnel ; une règle IKE ou ESP ne le couvre pas. La troisième est un pair qui répond depuis une adresse source différente de celle configurée comme son voisin.

Le journal du pair est le discriminant. Si son résumé BGP ne liste aucun voisin pour cette adresse, les paquets n'arrivent pas et le couple ou le chemin sont faux. Si le voisin reste en Active ou Connect, les paquets arrivent et les paramètres de session ne concordent pas.

Vérifiez dans l'ordre où voyagent les paquets

Travaillez vers l'extérieur : état du tunnel, puis état du pair BGP du routeur, puis résumé BGP du pair, puis les routes. Si les deux premiers sont sains, cessez de modifier le côté Cloud VPN et travaillez sur le dispositif pair. Si le routeur signale le pair comme down et que votre dispositif n'a aucun voisin, le couple est faux ou le port BGP est filtré. Une capture de paquets sur l'interface du tunnel du pair tranche en un coup d'œil, car les paquets OPEN y arrivent ou n'y arrivent jamais.

gcloud compute routers get-status ROUTER --region=REGION affiche l'état du pair à côté de l'adresse qu'il utilise, soit exactement le couple que vous devez comparer.

Une fois la session établie, confirmez que le préfixe appris apparaît dans la table de routage du VPC et qu'un hôte de chaque côté répond. Notez ensuite les couples définitifs à côté des noms de tunnel, afin que la prochaine reconstruction parte d'un tableau fiable et non du résumé de la console.