Come distinguere un loop di routing da una rotta che sfarfalla sui siti VPN
Un loop di routing e una rotta instabile causano la stessa perdita intermittente. Tre controlli sui gateway li distinguono prima che cambiate qualsiasi cosa.
Due siti, un tunnel e un prefisso remoto che risponde per un po' e poi tace. Il riflesso è chiamarlo loop di routing, e a volte è esattamente quello. Ma un loop e una rotta instabile producono la stessa lamentela e richiedono riparazioni opposte: uno è una decisione di inoltro che non termina mai, l'altra è un prefisso che continua a lasciare la tabella. Tre osservazioni li separano, e potete raccoglierle tutte e tre dalla riga di comando del gateway prima di toccare un filtro o riavviare un tunnel.
Un loop si decide salto per salto. Il sito A sceglie B come prossimo salto per la destinazione, B sceglie A per la stessa destinazione, e il pacchetto scade sul TTL dopo due andate e ritorni. Uno sfarfallio invece è deciso dal protocollo di routing: il prefisso viene ritirato, reinstallato o sostituito da un prossimo salto alternativo, così alcuni pacchetti non hanno alcuna rotta mentre altri seguono una rotta perfettamente buona.
I tre controlli che risolvono la questione
Non serve una cattura dei pacchetti per prendere la prima decisione. Servono lo stato del prefisso su entrambe le estremità, il prossimo salto che ciascun lato sceglie e un numero di salti che si ripete o no. Se il prefisso resta installato con lo stesso prossimo salto mentre il traffico fallisce, il loop vive nel percorso di inoltro. Se il prefisso sparisce e ritorna, il guasto è sopra l'inoltro e la riparazione spetta al protocollo di routing, non a una rotta statica.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
Un avvertimento prima di iniziare. Se leggete questo attraverso il tunnel che fa loop, la vostra sessione muore nel momento in cui cambiate la rotta. Aprite una console o un percorso di gestione che non dipenda dal prefisso che state per riparare.
Controllo uno: il prefisso è stabile o si agita
Chiedete al kernel cosa ha installato, non cosa promette il file di configurazione. Su un gateway Linux, ip route get 10.20.30.40 esegue la stessa ricerca del percorso di inoltro, incluse le tabelle delle policy, mentre ip route show 10.20.30.0/24 mostra la voce stessa. ip monitor route trasmette ogni cambiamento nel momento in cui avviene, che è il modo più rapido per vedere un prefisso arrivare e andarsene.
Su un router con FRR o BIRD, la tabella di inoltro non è quella interessante. show ip bgp 10.20.30.0/24 restituisce il percorso scelto e il suo tempo di attività; un tempo di attività che si azzera ogni pochi minuti è uno sfarfallio che potete nominare, non un loop. show ip bgp summary mostra lo stato dei vicini e i conteggi dei prefissi, così un peer che cade di continuo toglie la colpa al percorso di inoltro.
Annotate la risposta prima di cambiare qualsiasi cosa. Stabile per dieci minuti mentre i ping fallivano, e sparito quattro volte in dieci minuti, portano a passi successivi diversi. Il secondo caso rende irrilevante ogni teoria sulla rotta statica.
Controllo due: il prossimo salto punta di nuovo nel tunnel di arrivo
Un loop richiede che due gateway siano d'accordo. Nel sito che riceve il pacchetto, guardate la rotta che il pacchetto userà per uscire: ip route get 10.20.30.40 from 10.10.5.20 con l'indirizzo di origine reale, perché una regola di policy può rispondere diversamente dalla tabella principale. Poi ripetete la ricerca nel sito che lo ha inviato. Se ciascun lato sceglie l'altro come prossimo salto per lo stesso prefisso, il loop è dimostrato e nessuna cattura aggiungerà nulla.
La causa è quasi sempre un annuncio che non avrebbe dovuto attraversare il tunnel. Una rotta predefinita redistribuita nel tunnel, un aggregato che copre la sottorete del sito remoto stesso o una rotta statica verso il peer per sicurezza creano tutti lo stesso prossimo salto reciproco. Il tunnel può essere pienamente stabilito e portare comunque il traffico in cerchio; le note sull'inoltro di strongSwan descrivono il lato di routing di quel requisito.
WireGuard merita una nota propria, perché non c'è alcun annuncio da incolpare. wg show elenca gli AllowedIPs di ogni peer, e il kernel accetta una destinazione per un peer solo se cade dentro quell'intervallo. Un loop lì è un intervallo di AllowedIPs sovrapposto o una rotta statica che punta indietro attraverso l'interfaccia, quindi la riparazione vive in quei due punti e in nessun altro.
Controllo tre: leggete il numero di salti, non le stelle
traceroute -n -I 10.20.30.40 e mtr -n -r -c 20 10.20.30.40 mostrano entrambi il percorso, e la modalità ICMP spesso sopravvive a un filtraggio che si mangia le sonde UDP. Un loop sembra una breve sequenza ripetuta degli stessi due indirizzi di gateway con il TTL che sale ogni volta. Una caduta sembra stelle dopo l'ultimo gateway che ha risposto, e un solo salto silenzioso non è prova di nulla.
Quando il percorso è ambiguo, leggete il TTL sul filo. tcpdump -ni any -vv icmp su entrambi i gateway mostra il TTL di ogni pacchetto e l'indirizzo di origine di ogni risposta di tempo superato. Se un pacchetto raggiunge il sito remoto con un TTL inferiore al numero di salti che il percorso può contenere, qualcosa aggiunge salti che traceroute non vi mostra, e questo accade quando il firewall di un sito risponde alle sonde a nome di un altro.
Riparate il proprietario del prefisso, poi verificate entrambe le direzioni
Decidete quale sito origina la destinazione e quali percorsi di transito sono ammessi, poi cambiate l'annuncio o la rotta statica presso quel proprietario. Correggere il sito ricevente è tentante e di solito sbagliato: nasconde il loop per un prefisso e lascia il cattivo annuncio al suo posto per il successivo. Le etichette di rotta, le liste di distribuzione e le regole di split-horizon esistono per fermare questo alla fonte, e costano meno di un filtro che corrisponde a un solo prefisso.
Dopo il cambiamento, verificate separatamente andata e ritorno, perché un loop può essere sostituito da un buco nero senza alcun miglioramento visibile del sintomo. Eseguite ip route get da entrambe le estremità, inviate traffico da un host che non è il gateway, e lasciate ip monitor route in funzione per almeno un timer di mantenimento così che uno sfarfallio non venga scambiato per una riparazione.
Prima di cambiare qualsiasi cosa, confermate questi cinque punti: il prefisso è stabile o si agita, il prossimo salto su entrambe le estremità punta a un tunnel, il numero di salti si ripete o no, un solo sito possiede il prefisso, e avete un percorso di gestione che sopravvive al cambiamento. Se uno dei cinque è sconosciuto, gli altri quattro sono congetture.