Per què BGP sobre una VPN no controla el camí de la capa inferior

Dos llocs emparellen BGP a través d’un túnel IPsec, aprenen els prefixos de l’altre i el diagrama es reetiqueta com a control de camí. Aquesta etiqueta és on comença la confusió. La sessió sí que intercanvia accessibilitat i sí que aplica política, però no té cap veu sobre quin proveïdor, cable o encaminador transporta els paquets xifrats. He vist un equip reconstruir un túnel que funcionava perquè esperaven que un canvi de ruta BGP mogués el trànsit cap a un altre camí de fibra que la sessió mai no podia influir.

Què suposa la gent que compra una sessió

La major part de l’expectativa ve de com es veu un canvi de ruta en un laboratori. Anuncieu un prefix pel túnel, el costat llunyà l’instal·la i el trànsit es mou. La mateixa seqüència passa en un encaminador que sí que té comandaments d’enginyeria de trànsit, i per això les dues coses es confonen. Al laboratori tots dos llocs solen compartir un sol enllaç d’accés, i és exactament per això que la diferència no hi apareix mai.

BGP és un protocol d’accessibilitat. Diu a un parell que podeu lliurar paquets per a un prefix i permet que cada costat ordeni les ofertes que rep. Això és genuïnament útil a través d’un túnel: els prefixos apareixen i desapareixen a mesura que els llocs arriben i se’n van, i podeu refusar un rang sense escriure una ruta estàtica a cada dispositiu de vora. El que no fa és posar els encaminadors d’un proveïdor sota el vostre control.

La capa inferior transporta la capçalera exterior. El vostre extrem del túnel envia paquets xifrats a una adreça de parell, i la xarxa entre aquestes dues adreces els reenvia amb les rutes que hi hagin instal·lat els seus operadors. Res de la sessió BGP no canvia aquesta decisió, tret que el mateix proveïdor exposi un servei suportat que ho faci.

Què transporta realment la sessió

El parlant BGP obre una connexió TCP al port 179 del seu parell, fent servir els formats de missatge i els atributs de camí definits a RFC 4271. Quan l’adreça del parell viu dins del túnel, el túnel ha d’estar aixecat i aquesta adreça ha de ser abastable abans que la sessió pugui començar. Un intercanvi IKE completat no és un veí BGP. Les implementacions d’IPsec basades en rutes només deixen passar trànsit quan existeix una ruta de túnel coincident, i la basada en política necessita l’adreça del parell dins del selector protegit. Fer-ho al revés produeix l’estat clàssic en què el túnel és verd i la sessió queda aturada.

Un cop la sessió està aixecada, la política decideix què la travessa. Les llistes de prefixos, els filtres d’AS-path, un sostre de prefix màxim i una decisió explícita sobre les rutes per defecte són el mínim, i s’apliquen en tots dos sentits. Un parell que accepta tot el que rep us pot lliurar una ruta per defecte que substitueix silenciosament l’accés local a Internet. Les dues direccions necessiten llistes separades, perquè el que accepteu d’un parell i el que li anuncieu són decisions diferents.

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

Després mossega l’MTU. L’encapsulament redueix la càrrega útil, així que una actualització gran pot encallar una sessió que sembla perfectament establerta: el parell continua aixecat, els prefixos no arriben mai i no cau res òbviament al registre. Limiteu el MSS de TCP a la interfície del túnel, o fixeu un MTU de túnel amb espai per a la sobrecàrrega, abans de culpar els filtres.

On van encara els paquets exteriors

Els paquets xifrats d’un lloc a l’altre surten per allò que l’encaminador local selecciona per a l’adreça pública del parell. Si tots dos llocs compren trànsit al mateix proveïdor, creuen la mateixa instal·lació metropolitana o un costat seu darrere d’un NAT d’operador, el túnel sobreviu a una fallada del proveïdor només per accident. Comptar icones de túnel en una eina de monitoratge no us diu res sobre això.

La selecció de ruta i la instal·lació del reenviament també són esdeveniments separats. Un prefix pot seure a la taula BGP com a millor i tot i així faltar de la taula de reenviament, perquè el següent salt no es pot resoldre o guanya una ruta més específica. Quan algú informa que BGP ha après el prefix però el trànsit no flueix, la pregunta útil és si està instal·lat i a quin següent salt apunta.

La resposta honesta per a una revisió de disseny és una llista de dependències compartides: circuit d’accés, proveïdor superior, instal·lació i qualsevol dispositiu amb estat al camí de tornada. Una sessió a través del túnel no pot eliminar una dependència sobre la qual no seu.

Tres decisions que val la pena separar

Quan un disseny ho barreja, cada conversa sobre una caiguda va en cercles. Separeu-ho primer sobre el paper i després mapau cada decisió al dispositiu que realment l’aplica.

Cada fila té un propietari diferent. La primera és una negociació, la segona és configuració als vostres dispositius, la tercera és sobretot la xarxa d’algú altre. Una sol·licitud de canvi que anomena la fila que toca és molt més fàcil d’aprovar que una que diu problema de BGP.

Modes de fallada per als quals val la pena planificar

Acceptar la ruta resumida d’un parell és la ferida autoinfligida més comuna. Algú anuncia un agregat curt per simplificar l’intercanvi, el costat llunyà l’accepta i el trànsit per a rangs que no són darrere del túnel segueix el túnel i mor. Filtreu pels prefixos exactes esperats, o feu servir una llista de prefixos amb els límits correctes, i no accepteu mai un agregat nu perquè fa que la sessió sembli ordenada.

El moment del retirament és el segon. La detecció depèn dels temporitzadors de manteniment, de BFD si l’heu activat, de la detecció de parell mort del túnel i de la rapidesa amb què el costat llunyà deixa d’anunciar. Les sessions existents són un problema a part: una ruta nova pot restaurar connexions noves mentre les sessions TCP establertes continuen usant adreces antigues, i els tallafocs amb estat o el NAT del camí poden tenir entrades que ja no coincideixen. Poseu la recuperació de l’aplicació als criteris d’acceptació en lloc de suposar que un canvi de ruta ho arregla tot.

La tercera és l’asimetria del camí de tornada. El trànsit pot arribar pel túnel i tornar per un enllaç de proveïdor que mai no havia de transportar-lo, cosa que es veu com a àudio unidireccional, encaixades de mans fallides o un tallafoc que descarta les respostes. Comproveu tots dos sentits per separat.

Què escriure al contracte i com verificar-ho

Demaneu per escrit els prefixos permesos: qui està autoritzat a originar cada rang, si es permet una ruta per defecte i quines famílies d’adreces admet el servei de túnel. La RFC 8212 va fer de la política explícita d’importació i exportació l’expectativa per a eBGP en les implementacions que la segueixen, així que un parell que encara depèn d’acceptar-ho tot implícitament val la pena qüestionar-lo.

Després verifiqueu des del dispositiu i no des del diagrama. Ordres útils en encaminadors d’estil 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

Afegiu dues observacions que la taula d’encaminament no us pot donar. Captureu a la interfície exterior per confirmar quina adreça apunten realment els paquets encapsulats, per exemple tcpdump -ni eth0 udp port 51820 per a un túnel WireGuard, o un filtre ESP per a IPsec. Després traceu cap a l’adreça pública del parell i compareu els salts amb una traça dins del túnel; si tots dos segueixen la mateixa cadena de proveïdor, la vostra redundància viu en la política d’encaminament i no a la xarxa.

Finalment, proveu un retirament a propòsit. Baixeu el túnel durant una finestra de manteniment, anoteu quant de temps el prefix continua instal·lat, què passa amb les sessions existents i si el costat llunyà cau a una ruta que realment acceptaríeu. Aquest exercici diu més del disseny que qualsevol diagrama.

Una ruta no és una autorització. Els prefixos que acordeu intercanviar no diuen res sobre quins usuaris poden arribar a quin servei darrere del túnel, així que manteniu l’autenticació, els serveis permesos i els tallafocs dels amfitrions exactament on eren. Un parell abastable tampoc no és permís per a trànsit il·limitat ni per originar adreces arbitràries, i aquesta mena d’autoritat pertany al contracte com a qüestió comercial, no a una línia de política BGP.

• Nomeu els prefixos que cada costat pot originar i els que mai no ha d’acceptar.
• Limiteu l’MSS al túnel i confirmeu que les actualitzacions grans arriben de veritat.
• Lliste les dependències compartides de la capa inferior, no el nombre de túnels.
• Cronometreu un retirament real i anoteu què fa l’aplicació.