Una cache delle rotte VPN nasconde la tua modifica? Controlla tre cose

Svuotare la cache delle rotte è il primo istinto quando una modifica non ha effetto, e su Linux moderno è fatica sprecata: la cache globale delle rotte IPv4 è stata rimossa anni fa, quindi ip route show cache non stampa nulla e non c’è nulla da cancellare. Lo stato che ti inganna vive uno strato più in alto: in un socket, una mappatura NAT, un resolver o un network manager che ha riapplicato il vecchio profilo. Tre domande separano questi casi: il percorso sbagliato viene da un flusso nuovo o da una connessione vecchia, la tua piattaforma mette in cache le rotte o no, e lo stato è nel routing o sopra di esso. Rispondi prima di reimpostare un’interfaccia.

Primo controllo: il percorso vecchio viene da un flusso nuovo?

Una connessione stabilita conserva la rotta con cui è stata creata. Per questo una sessione SSH sul tunnel sopravvive a un cambio della tabella di routing mentre una nuova sessione prende subito il nuovo percorso, e per questo «la modifica non ha fatto nulla» spesso significa «il vecchio socket la trattiene ancora». Prova con un processo nuovo, non con la finestra che hai già aperta.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

L’ultimo comando stampa l’indirizzo che la nuova connessione ha realmente raggiunto, ed è il modo più economico di vedere il percorso reale senza fidarsi di una finestra di stato. Confrontalo con l’indirizzo sorgente che lo spazio dei nomi o l’interfaccia avrebbero dovuto usare.

Se un flusso nuovo prende il percorso corretto e quello vecchio non si riprende, smetti di guardare il routing. La rotta era giusta; la sessione era vecchia.

Secondo controllo: la tua piattaforma tiene davvero una cache delle rotte?

Su Linux la risposta è no, nel senso che intendono la maggior parte delle guide. Non c’è una cache delle destinazioni globale da buttare, e la voce per socket che conserva una rotta scelta viene rilasciata con il socket. La sezione cache del manuale di ip-route descrive un comportamento storico, non qualcosa che puoi svuotare su un kernel attuale.

Le altre piattaforme sono diverse, ed è qui che copiare i consigli va storto. Windows tiene una cache delle destinazioni che puoi pulire con netsh interface ip delete destinationcache. BSD e macOS espongono ricerche per destinazione tramite route -n get, e le loro cache scadono secondo il proprio calendario. Un comando che funziona su una di queste non fa assolutamente nulla su Linux, ed è per questo che la stessa correzione sembra fallire per metà di chi la prova.

Una tabella NAT o conntrack non è una cache delle rotte, anche se produce lo stesso sintomo. Un flusso tradotto prima della tua modifica conserva la sua traduzione, e conntrack -L lo mostrerà molto dopo che la politica di routing è avanzata. È uno stato obsoleto, ma cancellare le rotte non lo toccherà.

Terzo controllo: lo stato è nel routing o sopra di esso?

Leggi la ricerca attuale prima di leggere qualsiasi altra cosa: ip route get per la destinazione, poi lo stesso comando con from e l’indirizzo sorgente, poi ip rule show. Se questi tre concordano con ciò che intendevi, il routing non è lo strato da correggere, e l’osservazione obsoleta è venuta da altrove.

Tre sospetti comuni siedono sopra il routing. Un network manager può reinstallare una rotta da un profilo salvato pochi secondi dopo che l’hai cancellata, così la tua modifica sembra tornare; controlla nmcli connection show --active e lo stato dell’unità prima di modificare di nuovo la tabella. La cache di un resolver restituisce un indirizzo vecchio, che sembra un guasto di routing finché non interroghi lo stesso nome con uno strumento che aggira la cache. Il pool di connessioni di un’applicazione tiene un socket funzionante verso la vecchia destinazione e non chiede mai al kernel una nuova decisione.

Cosa ti permettono di concludere le tre risposte

Metti insieme le risposte e la riparazione di solito si enuncia da sola. Un flusso nuovo che prende il percorso sbagliato su una piattaforma senza cache delle rotte significa che la politica è davvero errata, quindi leggi le regole e la tabella installate dal tunnel. Un flusso nuovo che prende il percorso giusto mentre la vecchia sessione si blocca significa che il problema è l’applicazione o il socket. Rotte corrette con un’osservazione rotta in entrambi i casi significano che lo stato è sopra il routing.

Resisti all’aggiornamento generico. Riavviare lo stack di rete o cancellare ogni rotta su una macchina la cui rotta predefinita è il tunnel può tagliare proprio la connessione che stai usando per ripararla, e distrugge l’evidenza che ti avrebbe detto quale strato ha fallito.

Se devi davvero pulire qualcosa, pulisci la cosa più piccola che corrisponde alla diagnosi: i socket di un processo, una voce conntrack, la cache del resolver. Poi ripeti lo stesso test del flusso nuovo e annota cosa è cambiato.

Tieni i tre stati separati nelle tue note

Configurazione salvata, ricerca attuale e flusso osservato sono tre fatti diversi, e fonderli ne «la cache» è ciò che rende il guasto difficile da riprodurre. Annota il profilo o l’unità che possiede la rotta, l’output di ip route get, e l’origine e la destinazione della connessione reale.

Annota accanto la piattaforma e la versione del client, perché un rimedio che pulisce una cache delle destinazioni di Windows non è un rimedio applicabile a un host Linux, e una procedura copiata tra i due insegna la lezione sbagliata. Quando passi il problema a qualcun altro, quelle tre righe gli permettono di riprodurre lo stato guasto invece di indovinare.