Il tunnel regge, la rotta è sparita: separare due guasti VPN

Un host diventa irraggiungibile mentre l’interfaccia del tunnel continua a dichiararsi attiva, e le due osservazioni non sono in contraddizione. Qualcosa ha rimosso il percorso usato dal traffico: un vicino ha ritirato il suo prefisso, una rotta statica monitorata è stata rimossa, o un’altra rotta è diventata preferita. L’associazione di sicurezza può restare del tutto sana in tutti e tre i casi. Separare gli eventi significa chiedere quale strato è cambiato per primo, non se la VPN ha fallito.

Tre fasi che sembrano un solo evento

Una decisione di routing ha tre fasi. Il prefisso viene ricevuto, selezionato come migliore e installato nella tabella di inoltro. Ogni fase può fallire da sola, e il guasto appare identico dal lato dell’applicazione. Un prefisso appreso ma che ha perso la selezione è indistinguibile da uno che non è mai arrivato quando l’unica prova che guardate è la tabella di inoltro.

Per questo la prima domanda è quale fase si è rotta, non quale protocollo ha colpa. La risposta decide di chi è l’incidente e quale strumento userà il controllo successivo.

Leggete prima la rotta installata

Chiedete al kernel dove va davvero il traffico verso la destinazione guasta. ip route get stampa il prossimo salto, l’interfaccia e l’indirizzo sorgente che il kernel userebbe, e risponde per una destinazione invece che per l’intera tabella. Se la risposta nomina il tunnel, la tabella di inoltro crede ancora che il percorso esista e il problema sta sopra.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Una risposta «unreachable» significa che non è installata alcuna rotta, il che punta a un ritiro o a un’installazione mancante. Una risposta che nomina un’interfaccia fisica significa che il traffico ha lasciato il tunnel senza che nessuno lo decidesse, e il controllo successivo è la preferenza che ha vinto. Una risposta che nomina il tunnel mentre i pacchetti continuano a sparire punta più avanti nel percorso, al filtraggio o al lato remoto.

Poi guardate la visione del protocollo stesso

Un demone di routing tiene più di una tabella, e il confronto interessante è tra loro. Per BGP, lo stato della sessione vicina, l’annuncio ricevuto e la rotta installata sono tre prove separate. Un prefisso può restare nella tabella ricevuta e non raggiungere mai il kernel perché vince una rotta con distanza amministrativa più breve. Controllate tutte e tre prima di concludere che l’altro lato ha smesso di annunciare.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

Il riepilogo dice se la sessione è stabilita, la vista per prefisso dice se il prefisso è stato accettato, e la ricerca nel kernel dice se è stato installato. Leggerle in quest’ordine evita di confondere uno sfarfallio di sessione con un ritiro, e un ritiro con un rifiuto per policy.

Quando gli orologi non concordano

Mettete il log del tunnel, il log di routing e il primo guasto dell’applicazione su un’unica linea temporale usando i loro fusi orari reali. Se la perdita del vicino arriva per prima, il tunnel ha trascinato giù la rotta con sé. Se arriva prima il ritiro, il routing è cambiato e il tunnel ha reagito dopo. Sono incidenti diversi con proprietari diversi, e l’ordine è tutto il risultato.

Un minuto di deriva dell’orologio basta a ribaltare quella conclusione, quindi confermate il fuso orario e lo scostamento prima di fidarvi della sequenza. I dispositivi che registrano in ora locale senza scostamento sono la fonte abituale di una linea temporale sicura ma sbagliata.

Recupero senza loop

Dopo un ritiro due percorsi possono essere idonei: quello che il protocollo seleziona e quello che fissate a mano. Solo il primo è una decisione che la rete continua a prendere per voi, per questo una rotta manuale è un tampone e non un piano di recupero. Un annuncio alternativo non conserva nemmeno lo stato del firewall o del NAT per una sessione già stabilita, quindi i nuovi flussi possono funzionare mentre l’originale resta rotto. Confermate quale backup deve diventare attivo e se il sito remoto accetterà un percorso di ritorno attraverso di esso.

Non installate una sostituzione statica permanente prima di aver capito perché è avvenuto il ritiro. Quella scorciatoia può fissare il traffico su un percorso guasto o aggirare silenziosamente una policy di routing deliberata, e seppellisce la causa originale sotto una nuova configurazione. Riprovate l’applicazione una volta ripristinata la rotta, e confermate che il prefisso scelto abbia un percorso dati funzionante e non solo una voce in una tabella.