Las direcciones BGP de Cloud VPN van dentro del túnel, no en la tarjeta de red

Abra la página de Cloud Router para la VPN y una sesión BGP con una dirección en 169.254.0.0/16 le devuelve la mirada. La reacción natural es poner esa dirección en algún lugar de la VM y esperar a que la sesión suba. Esa reacción es incorrecta de una manera concreta: el par pertenece al enlace lógico que crea el túnel IPsec, no a la interfaz de red ordinaria de la máquina. Nada de lo que añada a la NIC hará que el túnel transporte BGP.

Siga el par hacia abajo por la pila en lugar de añadirlo al host.

Empiece donde la consola muestra el par

La página de la sesión enumera una dirección BGP de Cloud Router y una dirección de par, ambas link-local para una HA VPN IPv4. Junto a ellas están las direcciones de puerta de enlace externas que terminan los túneles. Son objetos distintos: el par link-local vive dentro, y las direcciones de puerta de enlace viven fuera y deben ser enrutables antes de que nada más funcione.

Anote las tres antes de abrir un archivo de configuración, porque confundirlas es todo el modo de fallo.

Baje hasta el túnel que lo transporta

El par link-local solo significa algo cuando existe una asociación de seguridad IPsec entre las dos puertas de enlace. En el lado de Google los túneles de HA VPN la crean en las dos interfaces; en su lado es lo que haya negociado el par. Compruebe primero la asociación de datos con swanctl --list-sas y anote qué túnel está activo en qué interfaz, porque una sesión BGP sana sobre un túnel muerto es imposible y un túnel muerto con una configuración esperanzada es lo habitual.

El paquete BGP es tráfico IP interior. La red exterior nunca lo ve, así que ningún conmutador necesita ambas direcciones en una VLAN.

Ahora configure el par Linux para que coincida

Elija el diseño de túnel admitido y deje que decida las direcciones interiores. Con una interfaz basada en rutas, la entrada de enrutamiento y los selectores de tráfico negociados tienen que coincidir, porque un nombre de interfaz por sí solo no permite nada. Apunte BIRD a la dirección local interior y a la dirección interior de Cloud Router, fije los números AS de la página de la sesión y permita TCP 179 dentro de la ruta protegida. Mantenga la ruta a la dirección exterior lejana en el enlace físico para que el túnel no capture su propio transporte.

Un túnel que se enruta a sí mismo es un bucle con un apretón de manos, y durante una hora parecerá un problema de cortafuegos.

Compruebe cada etapa en orden, no todo a la vez

Recorra las etapas: asociación de seguridad activa, par interior alcanzable desde la dirección del túnel, sesión BGP establecida, prefijos aceptados y luego un prefijo de carga de trabajo realmente usado. birdc show protocols responde la tercera pregunta y nada más, y por eso la gente declara la victoria demasiado pronto.

Un vecino establecido no promete que ambos lados hayan anunciado los prefijos que necesita, ni que esas rutas se hayan instalado como preferentes.

Si la sesión está establecida y el tráfico sigue tomando el camino equivocado, compare los prefijos anunciados con lo que la tabla de enrutamiento hace con ellos. Una ruta más específica en otro lugar, o una preferencia por otro camino, le da una sesión BGP funcionando y ningún reenvío útil.

Deténgase antes de aplicar esto a Router Appliance

Network Connectivity Center Router Appliance es un modelo de conexión distinto. Sus pares de Cloud Router usan direcciones internas de la disposición de VPC y subred en lugar del par link-local de HA VPN. Si el objetivo real es BGP con una VM de enrutamiento, siga los requisitos de interfaz de ese producto en lugar de copiar una sesión link-local.

El ámbito link-local sigue significando lo que dice. El túnel lógico proporciona esta adyacencia, y no autoriza a enrutar destinos link-local arbitrarios por la VPC.