Perché BGP su una VPN non controlla il percorso del sottostrato

Due sedi fanno peering BGP attraverso un tunnel IPsec, apprendono i prefissi l’una dell’altra, e il diagramma viene rietichettato come controllo del percorso. È quell’etichetta il punto in cui nasce la confusione. La sessione scambia davvero raggiungibilità e applica davvero policy, ma non ha voce in capitolo su quale provider, cavo o router trasporti i pacchetti cifrati. Ho visto un team ricostruire un tunnel funzionante perché si aspettava che un cambio di rotta BGP spostasse il traffico su un altro percorso in fibra che la sessione non avrebbe mai potuto influenzare.

Cosa la gente presume che compri una sessione

La maggior parte dell’aspettativa nasce da come appare un cambio di rotta in laboratorio. Annunci un prefisso sul tunnel, il lato remoto lo installa e il traffico si muove. La stessa sequenza avviene su un router che ha davvero le leve di traffic engineering, quindi le due cose vengono confuse. In laboratorio le due sedi di solito condividono un solo collegamento di accesso, ed è proprio per questo che la differenza non si vede mai lì.

BGP è un protocollo di raggiungibilità. Dice a un peer che puoi consegnare pacchetti per un prefisso e lascia che ciascun lato ordini le offerte che riceve. È davvero utile attraverso un tunnel: i prefissi compaiono e scompaiono man mano che le sedi arrivano e vanno via, e puoi rifiutare un intervallo senza scrivere una rotta statica su ogni dispositivo di bordo. Ciò che non fa è mettere i router di un provider sotto il tuo controllo.

Il sottostrato porta l’intestazione esterna. Il tuo endpoint del tunnel invia pacchetti cifrati a un indirizzo peer, e la rete tra quei due indirizzi li inoltra con le rotte che i suoi operatori hanno installato. Nulla nella sessione BGP cambia quella decisione, a meno che lo stesso provider esponga un servizio supportato che lo faccia.

Cosa trasporta davvero la sessione

Lo speaker BGP apre una connessione TCP alla porta 179 del suo peer, usando i formati di messaggio e gli attributi di percorso definiti nella RFC 4271. Quando l’indirizzo del peer si trova dentro il tunnel, il tunnel deve essere attivo e quell’indirizzo raggiungibile prima che la sessione possa persino iniziare. Uno scambio IKE completato non è un vicino BGP. Le implementazioni IPsec basate su rotte lasciano passare il traffico solo quando esiste una rotta del tunnel corrispondente, e quella basata su policy ha bisogno dell’indirizzo del peer dentro il selettore protetto. Invertire questo ordine produce lo stato classico in cui il tunnel è verde e la sessione resta inattiva.

Una volta attiva la sessione, la policy decide cosa la attraversa. Liste di prefissi, filtri AS-path, un tetto massimo di prefissi e una decisione esplicita sulle rotte predefinite sono il minimo, e valgono in entrambe le direzioni. Un peer che accetta tutto ciò che riceve può consegnarti una rotta predefinita che sostituisce silenziosamente l’accesso internet locale. Le due direzioni richiedono liste separate, perché ciò che accetti da un peer e ciò che gli annunci sono decisioni diverse.

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

Poi morde l’MTU. L’incapsulamento riduce il carico utile, quindi un aggiornamento grande può bloccare una sessione che sembra perfettamente stabilita: il peer resta attivo, i prefissi non arrivano mai e nulla di evidente finisce nel log. Limita il MSS TCP sull’interfaccia del tunnel, o imposta un MTU del tunnel con spazio per l’overhead, prima di dare la colpa ai filtri.

Dove vanno ancora i pacchetti esterni

I pacchetti cifrati da una sede all’altra escono attraverso ciò che il router locale seleziona per l’indirizzo pubblico del peer. Se entrambe le sedi comprano transito dallo stesso provider, attraversano la stessa struttura metropolitana, o un lato sta dietro un NAT di livello operatore, il tunnel sopravvive a un guasto del provider solo per caso. Contare le icone dei tunnel in uno strumento di monitoraggio non ti dice nulla su questo.

La selezione della rotta e l’installazione dell’inoltro sono anch’esse eventi separati. Un prefisso può sedere nella tabella BGP come migliore e mancare comunque dalla tabella di inoltro, perché il prossimo salto non è risolvibile o vince una rotta più specifica. Quando qualcuno riferisce che BGP ha appreso il prefisso ma il traffico non scorre, la domanda utile è se è installato e verso quale prossimo salto punta.

La risposta onesta per una revisione di progetto è un elenco di dipendenze condivise: circuito di accesso, provider a monte, struttura e qualsiasi dispositivo con stato sul percorso di ritorno. Una sessione attraverso il tunnel non può rimuovere una dipendenza su cui non si appoggia.

Tre decisioni che vale la pena separare

Quando un progetto mescola queste cose, ogni conversazione su un guasto gira in tondo. Separale prima sulla carta, poi mappa ciascuna al dispositivo che la applica davvero.

Ogni riga ha un proprietario diverso. La prima è una negoziazione, la seconda è configurazione sui tuoi dispositivi, la terza è per lo più la rete di qualcun altro. Una richiesta di modifica che nomina la riga che tocca è molto più facile da approvare di una che dice problema BGP.

Modalità di guasto per cui vale la pena pianificare

Accettare la rotta di riepilogo di un peer è la ferita autoinflitta più comune. Qualcuno annuncia un aggregato corto per semplificare lo scambio, il lato remoto lo accetta, e il traffico per gli intervalli che non stanno dietro il tunnel segue il tunnel e muore. Filtra sui prefissi esattamente attesi, o usa una lista di prefissi con i limiti giusti, e non accettare mai un aggregato nudo perché fa sembrare la sessione ordinata.

Il momento del ritiro è il secondo. Il rilevamento dipende dai timer di mantenimento, da BFD se l’hai abilitato, dal rilevamento del peer morto del tunnel e da quanto in fretta il lato remoto smette di annunciare. Le sessioni esistenti sono un problema separato: una nuova rotta può ripristinare nuove connessioni mentre le sessioni TCP stabilite continuano a usare indirizzi obsoleti, e firewall con stato o NAT sul percorso possono tenere voci che non corrispondono più. Metti il recupero dell’applicazione nei criteri di accettazione invece di presumere che un cambio di rotta sistemi tutto.

La terza è l’asimmetria del percorso di ritorno. Il traffico può arrivare dal tunnel e tornare su un collegamento del provider che non era mai destinato a trasportarlo, il che si manifesta come audio unidirezionale, handshake falliti o un firewall che scarta le risposte. Controlla entrambe le direzioni separatamente.

Cosa scrivere nel contratto, e come verificarlo

Chiedi per iscritto i prefissi consentiti: chi è autorizzato a originare ogni intervallo, se è ammessa una rotta predefinita e quali famiglie di indirizzi supporta il servizio tunnel. La RFC 8212 ha reso la policy esplicita di import ed export l’aspettativa per eBGP nelle implementazioni che la seguono, quindi un peer che si affida ancora al comportamento implicito di accettare tutto merita una domanda.

Poi verifica dal dispositivo invece che dal diagramma. Comandi utili su router in stile 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

Aggiungi due osservazioni che la tabella di routing non può darti. Cattura sull’interfaccia esterna per confermare quale indirizzo i pacchetti incapsulati prendono davvero di mira, per esempio tcpdump -ni eth0 udp port 51820 per un tunnel WireGuard, o un filtro ESP per IPsec. Poi traccia verso l’indirizzo pubblico del peer e confronta i salti con una traccia dentro il tunnel; se entrambi seguono la stessa catena di provider, la tua ridondanza vive nella policy di routing e non nella rete.

Infine, prova un ritiro di proposito. Abbassa il tunnel durante una finestra di manutenzione, annota quanto tempo il prefisso resta installato, cosa succede alle sessioni esistenti e se il lato remoto ricade su una rotta che accetteresti davvero. Quell’esercizio dice più del progetto di qualsiasi diagramma.

Una rotta non è un’autorizzazione. I prefissi che concordi di scambiare non dicono nulla su quali utenti possono raggiungere quale servizio dietro il tunnel, quindi tieni autenticazione, servizi consentiti e firewall degli host esattamente dove erano. Un peer raggiungibile non è nemmeno permesso di transito illimitato o di originare indirizzi arbitrari, e quel tipo di autorità appartiene al contratto come questione commerciale, non a una riga di policy BGP.

• Nomina i prefissi che ciascun lato può originare, e quelli che non deve mai accettare.
• Limita il MSS sul tunnel e conferma che gli aggiornamenti grandi arrivino davvero.
• Elenca le dipendenze condivise del sottostrato, non il numero di tunnel.
• Cronometra un ritiro reale e annota cosa fa l’applicazione.