GCP HA VPN: a sesión BGP queda en Waiting for peer, o intercambio do par de enderezos

Unha sesión BGP que nunca chega a Established nun túnel Cloud VPN normalmente non é un problema de encamiñamento. É un problema de cableado: dous enderezos que deben reflectirse entre si introducíronse na orde equivocada, ou o par do primeiro túnel reutilizouse no segundo. O túnel en si pode estar perfectamente san mentres a sesión queda en Waiting for peer, porque IPsec e BGP son negociacións distintas entre os mesmos dous extremos. Decida cal dos dous está roto antes de reconstruír nada.

Unha pregunta resolve a maioría dos casos: ve o dispositivo par o enderezo do Cloud Router?

O estado do túnel e o estado da sesión son comprobacións distintas

IKE e ESP van primeiro. Se o túnel non está establecido, nada do seu interior importa e a conversación sobre o enderezo BGP é prematura. Lea o estado e o estado detallado do túnel e despois o estado do par BGP do router para ese mesmo túnel.

Un túnel activo mentres o seu par BGP está caído reduce a falla á sesión: enderezo do par, ASN ou TCP 179 chegando ao enderezo interno. Un túnel activo, unha sesión activa e aínda ningunha ruta na VPC é un terceiro caso. Cambiar os enderezos non axudará aí, porque a sesión xa funciona e o prefixo simplemente non se anuncia ou non se prefire. Manter eses tres casos separados é a maior parte do traballo.

Cada túnel necesita o seu propio /30, cos dous extremos cubertos

Cada túnel HA VPN recibe un /30 link-local de 169.254.0.0/16, cun enderezo na interface do Cloud Router e o outro no seu par. O campo do par debe nomear o extremo remoto, nunca o enderezo do propio router.

Dous túneles significan dúas interfaces no Cloud Router, cada unha cun /30 distinto. Reutilizar o par do túnel 0 no túnel 1 é o erro que parece ordenado nunha táboa resumo e morre no paquete OPEN.

Lea o par desde o recurso do router e non desde o resumo da consola. O resumo lista o enderezo do par nunha columna fácil de ler mal, e o ipRange da interface máis o peerIpAddress do par deben describir extremos opostos dun mesmo /30.

O intercambio adoita ocorrer durante unha reconstrución

É ao reconstruír un túnel cando os pares se cruzan. O enderezo do par do túnel antigo cópiase no campo de interface do novo, ou a nova sesión apunta ao par da sesión anterior. En calquera caso o Cloud Router envía paquetes OPEN a un enderezo que agora é el mesmo ou a un enderezo sen túnel detrás.

Anote os pares antes de abrir a consola: nome do túnel, interface, enderezo do router, enderezo do par, ASN do par. Despois cree ambos os túneles nunha soa pasada, para que o segundo non se encha cos restos do primeiro.

Outras tres razóns polas que unha sesión espera

O ASN do par é a primeira: cada lado debe configurarse co ASN do outro, e unha discrepancia chega ao par pero nunca se establece. A segunda é a devasa do propio par, que debe permitir TCP 179 na interface do túnel; unha regra IKE ou ESP non o cobre. A terceira é un par que responde desde un enderezo de orixe distinto do configurado como o seu veciño.

O rexistro do propio par é o discriminante. Se o seu resumo BGP non lista ningún veciño para ese enderezo, os paquetes non chegan e o par ou o camiño son incorrectos. Se o veciño está en Active ou Connect, os paquetes chegan e os parámetros da sesión non concordan.

Comprobe na orde na que viaxan os paquetes

Traballa cara a fóra: estado do túnel, despois estado do par BGP do router, despois o resumo BGP do par e despois as rutas. Se os dous primeiros están sans, deixe de editar o lado Cloud VPN e traballe no dispositivo par. Se o router informa que o par está caído e o seu dispositivo non ten ningún veciño, o par é incorrecto ou o porto BGP está filtrado. Unha captura de paquetes na interface do túnel do par resólveo dunha ollada, porque os paquetes OPEN ou chegan alí ou non chegan nunca.

gcloud compute routers get-status ROUTER --region=REGION imprime o estado do par xunto ao enderezo que está usando, que é exactamente o par que cómpre comparar.

Cando a sesión se estableza, confirme que o prefixo aprendido aparece na táboa de rutas da VPC e que un hóspede de cada lado responde. Despois anote os pares definitivos xunto aos nomes dos túneles, para que a próxima reconstrución parta dunha táboa fiable en lugar do resumo da consola.