Por que BGP sobre unha VPN non controla a ruta da capa inferior

Dous emprazamentos emparellan BGP a través dun túnel IPsec, aprenden os prefixos do outro e o diagrama reetiquétase como control de ruta. Ese rótulo é onde comeza a confusión. A sesión si intercambia accesibilidade e si aplica política, pero non ten voz sobre que provedor, cable ou router transporta os paquetes cifrados. Vin un equipo reconstruír un túnel que funcionaba porque esperaban que un cambio de ruta BGP movese o tráfico a outra ruta de fibra que a sesión nunca podería influír.

Que supón a xente que compra unha sesión

A maior parte da expectativa vén de como se ve un cambio de ruta nun laboratorio. Anuncias un prefixo polo túnel, o lado remoto instálao e o tráfico móvese. A mesma secuencia ocorre nun router que si ten mandos de enxeñaría de tráfico, así que as dúas cousas confúndense. No laboratorio ambos os emprazamentos adoitan compartir unha soa ligazón de acceso, e é xustamente por iso que a diferenza nunca aparece alí.

BGP é un protocolo de accesibilidade. Dille a un par que podes entregar paquetes para un prefixo e permite que cada lado ordene as ofertas que recibe. Iso é xenuinamente útil a través dun túnel: os prefixos aparecen e desaparecen segundo os emprazamentos chegan e vanse, e podes rexeitar un rango sen escribir unha ruta estática en cada dispositivo de bordo. O que non fai é pór os routers dun provedor baixo o teu control.

A capa inferior transporta a cabeceira exterior. O teu extremo do túnel envía paquetes cifrados a un enderezo de par, e a rede entre eses dous enderezos reenvíaos coas rutas que instalasen os seus operadores. Nada na sesión BGP cambia esa decisión, agás que o mesmo provedor expoña un servizo soportado que o faga.

Que transporta realmente a sesión

O falante BGP abre unha conexión TCP ao porto 179 do seu par, usando os formatos de mensaxe e os atributos de ruta definidos en RFC 4271. Cando o enderezo do par vive dentro do túnel, o túnel debe estar levantado e ese enderezo debe ser alcanzable antes de que a sesión poida sequera comezar. Un intercambio IKE completado non é un veciño BGP. As implementacións de IPsec baseadas en rutas só deixan pasar tráfico cando existe unha ruta de túnel coincidente, e a baseada en política necesita o enderezo do par dentro do selector protexido. Facelo ao revés produce o estado clásico no que o túnel está verde e a sesión queda inactiva.

Unha vez levantada a sesión, a política decide que a cruza. As listas de prefixos, os filtros de AS-path, un teito de prefixos máximo e unha decisión explícita sobre as rutas por defecto son o mínimo, e aplícanse en ambos os sentidos. Un par que acepta todo o que recibe pode entregarche unha ruta por defecto que substitúe en silencio o acceso local a Internet. Os dous sentidos necesitan listas separadas, porque o que aceptas dun par e o que lle anuncias son decisións 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

Despois morde a MTU. A encapsulación reduce a carga útil, así que unha actualización grande pode atascar unha sesión que parece perfectamente establecida: o par segue levantado, os prefixos nunca chegan e non cae nada obvio no rexistro. Limita o MSS de TCP na interface do túnel, ou fixa unha MTU de túnel con espazo para a sobrecarga, antes de culpar os filtros.

A onde van aínda os paquetes exteriores

Os paquetes cifrados dun emprazamento a outro saen por aquilo que o router local selecciona para o enderezo público do par. Se ambos os emprazamentos compran tránsito ao mesmo provedor, cruzan a mesma instalación metropolitana ou un lado está detrás dun NAT de operador, o túnel sobrevive a un fallo do provedor só por accidente. Contar iconas de túnel nunha ferramenta de monitorización non che di nada sobre iso.

A selección de ruta e a instalación do reenvío tamén son sucesos separados. Un prefixo pode sentar na táboa BGP como o mellor e aínda así faltar na táboa de reenvío, porque o seguinte salto non é resoluble ou gaña unha ruta máis específica. Cando alguén informa de que BGP aprendeu o prefixo pero o tráfico non flúe, a pregunta útil é se está instalado e a que seguinte salto apunta.

A resposta honesta para unha revisión de deseño é unha lista de dependencias compartidas: circuíto de acceso, provedor superior, instalación e calquera dispositivo con estado na ruta de volta. Unha sesión a través do túnel non pode eliminar unha dependencia sobre a que non se asenta.

Tres decisións que paga a pena separar

Cando un deseño mestura estas cousas, cada conversación sobre unha caída dá voltas. Sepáraas primeiro sobre o papel e logo asigna cada unha ao dispositivo que realmente a aplica.

Cada fila ten un dono distinto. A primeira é unha negociación, a segunda é configuración nos teus dispositivos, a terceira é sobre todo a rede doutro. Unha solicitude de cambio que nomea a fila que toca é moito máis fácil de aprobar que unha que di problema de BGP.

Modos de fallo para os que paga a pena planificar

Aceptar a ruta resumida dun par é a ferida autoinxerida máis común. Alguén anuncia un agregado curto para simplificar o intercambio, o lado remoto acéptao e o tráfico de rangos que non están detrás do túnel segue o túnel e morre. Filtra polos prefixos exactos esperados, ou usa unha lista de prefixos cos límites correctos, e non aceptes nunca un agregado espido porque fai que a sesión pareza ordenada.

O momento da retirada é o segundo. A detección depende dos temporizadores de mantemento, de BFD se o activaches, da detección de par morto do túnel e da rapidez con que o lado remoto deixa de anunciar. As sesións existentes son un problema aparte: unha ruta nova pode restaurar conexións novas mentres as sesións TCP establecidas seguen usando enderezos obsoletos, e os cortafuegos con estado ou o NAT do camiño poden manter entradas que xa non coinciden. Pon a recuperación da aplicación nos criterios de aceptación en lugar de supor que un cambio de ruta arranxa todo.

A terceira é a asimetría da ruta de volta. O tráfico pode chegar polo túnel e volver por unha ligazón de provedor que nunca estivo pensada para transportalo, o que se manifesta como audio unidireccional, apertos de man fallidos ou un cortafuegos que descarta as respostas. Comproba ambos os sentidos por separado.

Que escribir no contrato e como verificalo

Pide por escrito os prefixos permitidos: quen está autorizado a orixinar cada rango, se se permite unha ruta por defecto e que familias de enderezos admite o servizo de túnel. A RFC 8212 converteu a política explícita de importación e exportación na expectativa para eBGP nas implementacións que a seguen, así que un par que aínda depende de aceptar todo implicitamente merece que se lle pregunten.

Logo verifica desde o dispositivo e non desde o 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

Engade dúas observacións que a táboa de rutas non pode darte. Captura na interface exterior para confirmar a que enderezo apuntan realmente os paquetes encapsulados, por exemplo tcpdump -ni eth0 udp port 51820 para un túnel WireGuard, ou un filtro ESP para IPsec. Logo traza cara ao enderezo público do par e compara os saltos cunha traza dentro do túnel; se ambos seguen a mesma cadea de provedor, a túa redundancia vive na política de rutas e non na rede.

Por último, proba unha retirada a propósito. Baixa o túnel durante unha ventá de mantemento, anota canto tempo permanece instalado o prefixo, que ocorre coas sesións existentes e se o lado remoto cae a unha ruta que aceptarías de verdade. Ese exercicio di máis do deseño que calquera diagrama.

Unha ruta non é unha autorización. Os prefixos que acordas intercambiar non din nada sobre que usuarios poden alcanzar que servizo detrás do túnel, así que mantén a autenticación, os servizos permitidos e os cortafuegos dos equipos exactamente onde estaban. Un par alcanzable tampouco é permiso para tránsito ilimitado nin para orixinar enderezos arbitrarios, e ese tipo de autoridade pertence ao contrato como cuestión comercial, non a unha liña de política BGP.

• Nomea os prefixos que cada lado pode orixinar e os que nunca debe aceptar.
• Limita o MSS no túnel e confirma que as actualizacións grandes chegan de verdade.
• Enumera as dependencias compartidas da capa inferior, non o número de túneles.
• Cronometra unha retirada real e anota que fai a aplicación.