GCP HA VPN: la sesión BGP se queda en Waiting for peer, el intercambio de direcciones

Una sesión BGP que nunca alcanza Established en un túnel de Cloud VPN normalmente no es un problema de enrutamiento. Es un problema de cableado: dos direcciones que deben reflejarse mutuamente se introdujeron en el orden equivocado, o el par del primer túnel se reutilizó en el segundo. El túnel en sí puede estar perfectamente sano mientras la sesión se queda en Waiting for peer, porque IPsec y BGP son negociaciones distintas entre los mismos dos extremos. Decida cuál de los dos está roto antes de reconstruir nada.

Una pregunta resuelve la mayoría de los casos: ¿ve el dispositivo par la dirección del Cloud Router?

El estado del túnel y el de la sesión son comprobaciones distintas

IKE y ESP van primero. Si el túnel no está establecido, nada de su interior importa y la discusión sobre la dirección BGP es prematura. Lea el estado y el estado detallado del túnel y después el estado del par BGP del router para ese mismo túnel.

Un túnel activo cuyo par BGP está caído reduce el fallo a la sesión: dirección del par, ASN o TCP 179 llegando a la dirección interna. Un túnel activo, una sesión activa y aún ninguna ruta en la VPC es un tercer caso. Cambiar las direcciones no ayudará ahí, porque la sesión ya funciona y el prefijo simplemente no se anuncia o no se prefiere. Mantener esos tres casos separados es la mayor parte del trabajo.

Cada túnel necesita su propio /30, con ambos extremos rellenos

Cada túnel de HA VPN recibe un /30 link-local de 169.254.0.0/16, con una dirección en la interfaz del Cloud Router y la otra en su par. El campo del par debe nombrar el extremo remoto, nunca la dirección del propio router.

Dos túneles implican dos interfaces en el Cloud Router, cada una con un /30 distinto. Reutilizar el par del túnel 0 en el túnel 1 es el error que parece ordenado en una tabla resumen y muere en el paquete OPEN.

Lea el par desde el recurso del router y no desde el resumen de la consola. El resumen muestra la dirección del par en una columna fácil de leer mal, y el ipRange de la interfaz más el peerIpAddress del par deben describir extremos opuestos de un mismo /30.

El intercambio suele ocurrir durante una reconstrucción

Reconstruir un túnel es donde se cruzan los pares. La dirección del par del túnel antiguo se copia en el campo de interfaz del nuevo, o la nueva sesión apunta al par de la sesión anterior. En cualquier caso el Cloud Router envía paquetes OPEN a una dirección que ahora es él mismo o a una dirección sin túnel detrás.

Anote los pares antes de abrir la consola: nombre del túnel, interfaz, dirección del router, dirección del par, ASN del par. Luego cree ambos túneles de una vez, para que el segundo no se rellene con los restos del primero.

Otras tres razones por las que una sesión espera

El ASN del par es la primera: cada lado debe configurarse con el ASN del otro, y una discrepancia llega al par pero nunca se establece. La segunda es el cortafuegos del propio par, que debe permitir TCP 179 en la interfaz del túnel; una regla IKE o ESP no lo cubre. La tercera es un par que responde desde una dirección de origen distinta de la configurada como su vecino.

El registro del propio par es el discriminante. Si su resumen BGP no lista ningún vecino para esa dirección, los paquetes no llegan y el par o la ruta están mal. Si el vecino está en Active o Connect, los paquetes llegan y los parámetros de la sesión no coinciden.

Verifique en el orden en que viajan los paquetes

Trabaje hacia fuera: estado del túnel, luego estado del par BGP del router, luego el resumen BGP del par y luego las rutas. Si los dos primeros están sanos, deje de editar el lado de Cloud VPN y trabaje en el dispositivo par. Si el router informa que el par está caído y su dispositivo no tiene ningún vecino, el par está mal o el puerto BGP está filtrado. Una captura de paquetes en la interfaz del túnel del par lo resuelve de un vistazo, porque los paquetes OPEN o llegan allí o no llegan nunca.

gcloud compute routers get-status ROUTER --region=REGION imprime el estado del par junto a la dirección que está usando, que es exactamente el par que necesita comparar.

Cuando la sesión se establezca, confirme que el prefijo aprendido aparece en la tabla de rutas de la VPC y que un host de cada lado responde. Después anote los pares definitivos junto a los nombres de los túneles, para que la próxima reconstrucción parta de una tabla fiable en lugar del resumen de la consola.