Por qué BGP sobre una VPN no controla la ruta de la capa inferior

Dos sedes emparejan BGP a través de un túnel IPsec, aprenden los prefijos de la otra y el diagrama se reetiqueta como control de ruta. Esa etiqueta es donde empieza la confusión. La sesión sí intercambia accesibilidad y sí aplica política, pero no tiene voz sobre qué proveedor, cable o router transporta los paquetes cifrados. He visto a un equipo reconstruir un túnel que funcionaba porque esperaban que un cambio de ruta BGP moviera el tráfico a otra ruta de fibra que la sesión nunca podría influir.

Qué supone la gente que compra una sesión

La mayor parte de la expectativa viene de cómo se ve un cambio de ruta en un laboratorio. Anuncias un prefijo por el túnel, el lado remoto lo instala y el tráfico se mueve. La misma secuencia ocurre en un router que sí tiene mandos de ingeniería de tráfico, así que ambas cosas se confunden. En el laboratorio ambas sedes suelen compartir un solo enlace de acceso, y es justo por eso que la diferencia nunca aparece ahí.

BGP es un protocolo de accesibilidad. Le dice a un par que puedes entregar paquetes para un prefijo y permite que cada lado ordene las ofertas que recibe. Eso es genuinamente útil a través de un túnel: los prefijos aparecen y desaparecen según las sedes llegan y se van, y puedes rechazar un rango sin escribir una ruta estática en cada dispositivo de borde. Lo que no hace es poner los routers de un proveedor bajo tu control.

La capa inferior transporta la cabecera exterior. Tu extremo del túnel envía paquetes cifrados a una dirección de par, y la red entre esas dos direcciones los reenvía con las rutas que hayan instalado sus operadores. Nada en la sesión BGP cambia esa decisión, salvo que el mismo proveedor exponga un servicio soportado que lo haga.

Qué transporta realmente la sesión

El hablante BGP abre una conexión TCP al puerto 179 de su par, usando los formatos de mensaje y los atributos de ruta definidos en RFC 4271. Cuando la dirección del par vive dentro del túnel, el túnel debe estar levantado y esa dirección debe ser alcanzable antes de que la sesión pueda siquiera empezar. Un intercambio IKE completado no es un vecino BGP. Las implementaciones de IPsec basadas en rutas solo dejan pasar tráfico cuando existe una ruta de túnel coincidente, y la basada en política necesita la dirección del par dentro del selector protegido. Hacerlo al revés produce el estado clásico en el que el túnel está verde y la sesión queda inactiva.

Una vez levantada la sesión, la política decide qué la cruza. Las listas de prefijos, los filtros de AS-path, un techo de prefijos máximo y una decisión explícita sobre las rutas por defecto son el mínimo, y se aplican en ambos sentidos. Un par que acepta todo lo que recibe puede entregarte una ruta por defecto que sustituye en silencio el acceso local a Internet. Los dos sentidos necesitan listas separadas, porque lo que aceptas de un par y lo que le anuncias son decisiones distintas.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Después muerde la MTU. La encapsulación reduce la carga útil, así que una actualización grande puede atascar una sesión que parece perfectamente establecida: el par sigue levantado, los prefijos nunca llegan y no cae nada obvio en el registro. Limita el MSS de TCP en la interfaz del túnel, o fija una MTU de túnel con espacio para la sobrecarga, antes de culpar a los filtros.

A dónde van todavía los paquetes exteriores

Los paquetes cifrados de una sede a otra salen por lo que el router local selecciona para la dirección pública del par. Si ambas sedes compran tránsito al mismo proveedor, cruzan la misma instalación metropolitana o un lado está detrás de un NAT de operador, el túnel sobrevive a un fallo del proveedor solo por accidente. Contar iconos de túnel en una herramienta de monitorización no te dice nada sobre eso.

La selección de ruta y la instalación del reenvío también son sucesos separados. Un prefijo puede sentarse en la tabla BGP como el mejor y aun así faltar en la tabla de reenvío, porque el siguiente salto no es resoluble o gana una ruta más específica. Cuando alguien informa de que BGP aprendió el prefijo pero el tráfico no fluye, la pregunta útil es si está instalado y a qué siguiente salto apunta.

La respuesta honesta para una revisión de diseño es una lista de dependencias compartidas: circuito de acceso, proveedor superior, instalación y cualquier dispositivo con estado en la ruta de vuelta. Una sesión a través del túnel no puede eliminar una dependencia sobre la que no se asienta.

Tres decisiones que merece la pena separar

Cuando un diseño mezcla estas cosas, cada conversación sobre una caída da vueltas. Sepáralas primero sobre el papel y luego asigna cada una al dispositivo que realmente la aplica.

Cada fila tiene un dueño distinto. La primera es una negociación, la segunda es configuración en tus dispositivos, la tercera es sobre todo la red de otro. Una solicitud de cambio que nombra la fila que toca es mucho más fácil de aprobar que una que dice problema de BGP.

Modos de fallo para los que merece la pena planificar

Aceptar la ruta resumida de un par es la herida autoinfligida más común. Alguien anuncia un agregado corto para simplificar el intercambio, el lado remoto lo acepta y el tráfico de rangos que no están detrás del túnel sigue el túnel y muere. Filtra por los prefijos exactos esperados, o usa una lista de prefijos con los límites correctos, y no aceptes nunca un agregado desnudo porque hace que la sesión parezca ordenada.

El momento de la retirada es el segundo. La detección depende de los temporizadores de mantenimiento, de BFD si lo activaste, de la detección de par muerto del túnel y de la rapidez con que el lado remoto deja de anunciar. Las sesiones existentes son un problema aparte: una ruta nueva puede restaurar conexiones nuevas mientras las sesiones TCP establecidas siguen usando direcciones obsoletas, y los cortafuegos con estado o el NAT del camino pueden mantener entradas que ya no coinciden. Pon la recuperación de la aplicación en los criterios de aceptación en lugar de suponer que un cambio de ruta lo arregla todo.

La tercera es la asimetría de la ruta de vuelta. El tráfico puede llegar por el túnel y volver por un enlace de proveedor que nunca estuvo pensado para transportarlo, lo que se manifiesta como audio unidireccional, apretones de manos fallidos o un cortafuegos que descarta las respuestas. Comprueba ambos sentidos por separado.

Qué escribir en el contrato y cómo verificarlo

Pide por escrito los prefijos permitidos: quién está autorizado a originar cada rango, si se permite una ruta por defecto y qué familias de direcciones admite el servicio de túnel. La RFC 8212 convirtió la política explícita de importación y exportación en la expectativa para eBGP en las implementaciones que la siguen, así que un par que aún depende de aceptar todo implícitamente merece que se le pregunte.

Luego verifica desde el dispositivo y no desde el diagrama. Comandos útiles en routers de estilo FRR:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Añade dos observaciones que la tabla de rutas no puede darte. Captura en la interfaz exterior para confirmar a qué dirección apuntan realmente los paquetes encapsulados, por ejemplo tcpdump -ni eth0 udp port 51820 para un túnel WireGuard, o un filtro ESP para IPsec. Luego traza hacia la dirección pública del par y compara los saltos con una traza dentro del túnel; si ambos siguen la misma cadena de proveedor, tu redundancia vive en la política de rutas y no en la red.

Por último, prueba una retirada a propósito. Baja el túnel durante una ventana de mantenimiento, anota cuánto tiempo permanece instalado el prefijo, qué ocurre con las sesiones existentes y si el lado remoto cae a una ruta que aceptarías de verdad. Ese ejercicio dice más del diseño que cualquier diagrama.

Una ruta no es una autorización. Los prefijos que acuerdas intercambiar no dicen nada sobre qué usuarios pueden alcanzar qué servicio detrás del túnel, así que mantén la autenticación, los servicios permitidos y los cortafuegos de los equipos exactamente donde estaban. Un par alcanzable tampoco es permiso para tránsito ilimitado ni para originar direcciones arbitrarias, y ese tipo de autoridad pertenece al contrato como cuestión comercial, no a una línea de política BGP.

• Nombra los prefijos que cada lado puede originar y los que nunca debe aceptar.
• Limita el MSS en el túnel y confirma que las actualizaciones grandes llegan de verdad.
• Enumera las dependencias compartidas de la capa inferior, no el número de túneles.
• Cronometra una retirada real y anota qué hace la aplicación.