La VPN en la nube necesita BGP: por qué fallan los demás protocolos de enrutamiento

La asociación de seguridad IPsec está activa, los contadores del túnel se mueven y el tráfico hacia el prefijo de la nube desaparece. El operador intenta entonces habilitar OSPF en el router del cliente, esperando que se forme el vecino, y no ocurre nada. El túnel nunca fue la pieza que faltaba: una VPN en la nube gestionada expone un contrato de enrutamiento definido, y en las plataformas grandes ese contrato es BGP. Hasta que exista una sesión y se acepte un prefijo, el túnel es solo una ruta cifrada sin destinos detrás.

El túnel está activo y falta la ruta

Completar la fase 1 y la fase 2 demuestra que los extremos coinciden en la protección, no que alguno sepa adónde enviar el tráfico. Son máquinas de estado separadas con modos de fallo separados.

Formule tres preguntas en orden: ¿se anunció el prefijo?, ¿lo aceptó el par?, ¿se instaló para el reenvío? Un prefijo anunciado y filtrado es un problema de política. Un prefijo que nunca se anunció es un problema de sesión o de configuración. Un prefijo aceptado pero no instalado es un problema de selección de ruta, y cada respuesta apunta a una parte distinta de la configuración.

Qué le entrega realmente el proveedor

Una puerta de enlace VPN gestionada no es un router sin restricciones. El proveedor le entrega una puerta de enlace con direcciones de par admitidas, un ajuste de sistema autónomo, límites de prefijos y un comportamiento de fallo definido. Esa superficie es el producto.

Google Cloud documenta el enrutamiento dinámico BGP para HA VPN, con Cloud Router aprendiendo las rutas de los pares y suministrando rutas dinámicas personalizadas elegibles a la VPC. AWS Site-to-Site VPN documenta una elección entre enrutamiento estático y dinámico, y describe las comprobaciones de vitalidad BGP como útiles para la conmutación por error del túnel, a la vez que admite comprobaciones de estado para dispositivos sin BGP. El comportamiento de ninguna plataforma debe inferirse del nombre de producto de la otra.

La consecuencia práctica es que primero se elige el modo gestionado y después se leen los parámetros admitidos. Un diseño que supone un tipo de adyacencia que el servicio no ofrece no es un problema de configuración que se resuelva en el router del cliente.

La protección del túnel y la alcanzabilidad son tareas separadas

IPsec protege el tráfico seleccionado para el túnel. BGP aporta la información de alcanzabilidad que hace elegible un prefijo. Un túnel que funciona no demuestra que el prefijo esperado se haya anunciado, aceptado o instalado.

Imagine una sucursal que anuncia 10.42.0.0/16 por dos caminos de túnel elegibles. Retire un camino utilizable y la elección de ruta puede cambiar sin que nadie edite la ruta de cada carga de trabajo. La detección, la selección de ruta y la recuperación de la aplicación no son instantáneas y no son idénticas entre despliegues, así que la prueba de conmutación debe observar toda la secuencia y no el primer paquete que pasa.

Cuando un prefijo de la nube no es alcanzable, revise el estado de la sesión y las rutas aprendidas antes de tocar la criptografía. Una SA activa sin ninguna ruta detrás es la forma más común de este síntoma.

Dónde se rompen las suposiciones sobre OSPF

OSPF, IS-IS u otro protocolo dentro de un túnel IPsec es totalmente posible en un dispositivo autogestionado, donde usted posee ambos extremos y el diseño de reenvío. Ese hecho no dice nada sobre un servicio gestionado que solo ofrece BGP como modo de enrutamiento dinámico.

Si un diseño propuesto necesita una adyacencia que el servicio no admite, cambie la arquitectura de forma deliberada. Las opciones incluyen un dispositivo autogestionado en la VPC, enrutamiento estático donde el servicio lo admita, o un producto de conectividad distinto. Configurar el protocolo solo en el router del cliente no puede añadir un par del lado de la nube que no existe, y no hará aparecer el prefijo.

No traslade la respuesta de un proveedor a la puerta de enlace de otro. Las mismas palabras, como enrutamiento dinámico o conmutación por error del túnel, pueden describir mecanismos y límites distintos.

Lea el requisito del servicio y después diseñe

Antes de la primera línea de configuración, anote las direcciones de los vecinos, los números de sistema autónomo, los prefijos que anunciará y aceptará, los límites de rutas y el comportamiento esperado cuando falle un túnel. Esos cinco elementos son el contrato con el que diseña.

Después verifique en el mismo orden: sesión establecida, prefijo recibido, ruta presente en la tabla de rutas de la VPC y un flujo real hacia una dirección de servicio. Repita tras una conmutación forzada, porque una sesión que se restablece puede volver con un conjunto de rutas distinto. Si el diseño depende de una convergencia inferior al segundo, mídala en lugar de suponerla.

Conserve el contrato del servicio junto con el registro de cambios. Cuando alguien pregunte más adelante por qué el túnel no puede ejecutar OSPF, la respuesta es una frontera de producto, no una limitación del protocolo, y el registro debería decirlo.