Quando le rotte del tunnel diviso si sovrappongono: quale prefisso vince

Due profili di tunnel diviso, due prefissi privati e un host che entrambi rivendicano. Il sintomo raramente è un guasto netto: un servizio funziona il lunedì, va in timeout dopo che il secondo client si riconnette e funziona di nuovo dopo un riavvio. L’ordine in cui hai connesso i client non decide l’esito, e nemmeno l’ordine delle righe nell’interfaccia del client. Esegui questi controlli in ordine e fermati al primo che non regge, perché i successivi hanno senso solo quando i precedenti sono veri.

1. Annota la destinazione e l’origine

Parti dall’indirizzo esatto verso cui va la richiesta che fallisce, non dal nome dell’host e non dal nome dell’applicazione. Risolvi il nome una volta, annota ogni risposta e scegli quella che il flusso che fallisce usa davvero. Poi annota l’indirizzo locale dello stesso flusso, perché l’indirizzo di origine può cambiare quale regola di politica corrisponde e quindi quale tabella viene consultata.

Una richiesta verso uno di più record A può fallire mentre un indirizzo fratello riesce, il che sembra un tunnel instabile e in realtà sono due percorsi diversi. Se la destinazione è un nome con più risposte, prova ogni risposta separatamente prima di cambiare qualcosa.

2. Chiedi al kernel quale rotta ha scelto

Non leggere la tabella delle rotte e dedurne la risposta. Poni la stessa domanda che pone lo stack, con lo stesso indirizzo di origine: ip route get 10.20.4.10 from 10.8.0.2 su Linux, oppure Find-NetRoute -RemoteIPAddress 10.20.4.10 in PowerShell. L’output indica la rotta che verrebbe davvero usata, e spesso non è quella che ti aspettavi leggendo la tabella.

Tra le rotte che corrispondono, di solito vince il prefisso più specifico: un /24 batte un /16 per un indirizzo che sta in entrambi. Tra corrispondenze di pari lunghezza vince la metrica più bassa, e una rotta installata su un collegamento abbassato viene saltata. Due tunnel che annunciano lo stesso /24 con la stessa metrica sono un caso diverso: il kernel conserva entrambe le rotte e sceglie tra loro, quindi il risultato può alternarsi invece di seguire l’ordine in cui i client si sono connessi. È esattamente la situazione che produce lo schema lunedì funziona e martedì no, e riconnettersi in un ordine diverso non lo cambia.

3. Verifica se una regola di politica ha reindirizzato la ricerca

Prima che la tabella delle rotte venga consultata, il kernel percorre le sue regole di politica. Una regola può inviare il traffico da una data origine, utente o marcatura del firewall a una tabella completamente diversa, quindi il prefisso vincente nella tabella principale potrebbe non essere mai consultato per quel flusso. ip rule show le elenca in ordine di valutazione, e ip route show table 100 mostra che cosa contiene davvero la tabella selezionata.

Qui si nascondono due trappole. Una regola che punta a una tabella vuota produce una ricerca che ricade sulla regola successiva, quindi la regola sembra non fare nulla. L’altra è il numero di priorità stesso: le regole si leggono in ordine crescente, e i valori predefiniti sono 0 local, 32766 main e 32767 default. Una regola con numero inferiore a 32767 viene consultata prima della regola predefinita che cattura tutto. Una regola con numero superiore a 32767 sta dietro di essa e viene raggiunta solo quando nessuna tabella precedente risponde, cosa che una normale rotta predefinita in main impedisce, quindi in pratica non viene mai raggiunta e non fa nulla in silenzio mentre sembra installata. Se il client ha scritto una regola e una rotta, controlla entrambe, e controllale di nuovo dopo una riconnessione, perché un profilo riscritto può aggiungere una seconda regola con priorità diversa.

4. Distingui un pareggio di instradamento da un piano di indirizzi duplicato

A volte il prefisso non è affatto il problema. Due sedi che usano entrambe 192.168.1.0/24 significano che lo stesso indirizzo identifica due host diversi e nessuna rotta può distinguerli. Una rotta verso l’host per una delle due risposte funziona solo finché l’altra sede risponde per lo stesso nome, e allora l’eccezione diventa silenziosamente il difetto.

L’indizio è che l’indirizzo di destinazione è identico sui due percorsi e cambia solo il proprietario previsto. È una decisione di piano di indirizzi, non una regolazione dell’instradamento: rinumera un lato, metti un lato dietro un gateway che traduce, oppure raggiungi la seconda sede tramite un proxy che risolve i propri nomi. Abbassare una rotta predefinita o impilare eccezioni per gli host sposta solo la collisione altrove.

5. Conferma che il resolver sia d’accordo con la rotta

Un nome che si risolve nell’indirizzo privato sbagliato produce tutti i sintomi di un conflitto di instradamento e nessuna delle sue cause. Confronta la risposta che l’host riceve con l’indirizzo che la destinazione usa davvero, e controlla quale resolver ha risposto. Se il tunnel spinge un resolver, il client dovrebbe installarlo per i flussi che usano il tunnel; se non lo fa, l’host continua a chiedere al resolver locale, che può rispondere da un dominio di ricerca o da un record in cache.

Interroga il resolver direttamente e annota il server che ha risposto. Una risposta in cache con TTL breve può anche spiegare perché la prima richiesta dopo una riconnessione si comporta diversamente dalla quinta.

6. Riconnetti, ispeziona lo stato applicato, poi prova entrambi i flussi

Dopo una correzione, riconnetti e ispeziona che cosa ha davvero installato il client invece di fidarti dell’editor dei profili. Rileggi le regole, le tabelle e la risposta di ip route get che ne deriva. Un secondo client può reinstallare la propria rotta alla connessione e ricreare il conflitto, ed è per questo che il controllo dello stato deve avvenire dopo la connessione dell’ultimo client, non prima.

Prova due flussi, non uno: la richiesta che prima falliva e una risorsa che dovrebbe usare l’altro tunnel. Spostare tutto il traffico privato su una sola connessione farà passare il primo test mentre romperà il secondo, e solo un test appaiato lo rileva. Annota ogni eccezione che mantieni, con la destinazione e il motivo, così la persona successiva può distinguere una rotta verso l’host voluta da una rimasta.