Perché le rotte a costo uguale rendono difficili da vedere i guasti VPN
Quando più tunnel condividono lo stesso costo, ogni flusso può prendere un altro. Un ping riuscito non dice nulla sul percorso che la vostra applicazione usa davvero.
Un utente segnala che l’applicazione interna funziona da una macchina e fallisce da un’altra, mentre il ping eseguito dal gateway riesce in entrambi i casi. Con più tunnel a costo uguale, non è una contraddizione. Ogni flusso viene collocato sul proprio salto successivo, quindi la vostra sonda e la sessione dell’utente possono semplicemente usare percorsi diversi. La procedura seguente riproduce quella scelta prima di modificare qualcosa.
Un ping, più percorsi possibili
Quando una rotta ha più di un salto successivo allo stesso costo, il router deve sceglierne uno per pacchetto. La maggior parte delle implementazioni calcola un hash dei campi del pacchetto, di norma gli indirizzi di origine e destinazione insieme al protocollo e alle porte, così le risposte restano sullo stesso percorso. Applicazioni diverse, o persino connessioni diverse di una stessa applicazione, producono hash diversi.
Ecco perché una diagnosi dal gateway dimostra così poco. La sonda del gateway ha i propri indirizzi e le proprie porte, e quindi il proprio hash. Può finire sul tunnel sano mentre l’utente continua a finire su quello guasto.
Come la piattaforma sceglie un salto successivo
Riproducete la scelta invece di indovinarla. Chiedete al kernel quale rotta userebbe per la stessa origine e destinazione della sessione che fallisce. Quella ricerca include campi che una semplice ricerca di destinazione ignora. Eseguitela anche da un client che funziona e confrontate le due risposte:
ip route get 10.20.5.7 from 10.20.0.14Le versioni più recenti di iproute2 accettano anche il protocollo e la porta di destinazione, cosa che conta quando l’hash li include. Confrontate quell’output con la stessa ricerca da un client che funziona, e la differenza è la prova che vi mancava.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Seguite il flusso che fallisce, non la tabella di routing
La tabella di routing elenca entrambi i tunnel e per definizione sembra corretta. La domanda è cosa fa ciascun tunnel con il pacchetto una volta scelto. Verificate che entrambi portino gli stessi prefissi protetti, lo stesso permesso di inoltro e un percorso di ritorno che raggiunge lo stesso client.
Fate attenzione ai dispositivi con stato nel mezzo. Se una richiesta esce da un tunnel e la risposta torna dall’altro, un firewall o un NAT che non ha mai visto il flusso originale la scarterà. Entrambi i tunnel inoltrano il traffico correttamente, e la connessione fallisce comunque.
Controllate anche l’MTU per percorso. Un percorso con un incapsulamento in più riduce la dimensione utilizzabile, e un trasferimento che riesce su un tunnel si blocca sull’altro esattamente alla dimensione in cui quello più piccolo si rompe.
Confrontate un percorso alla volta
Dove il progetto consente manutenzione, mettete fuori servizio un tunnel e ripetete l’attività dell’utente. Se il guasto sparisce, il problema appartiene al percorso rimosso, e il passo successivo è confrontare la sua configurazione con quella del vicino invece di riesaminare la tabella di routing.
Confrontate l’applicazione reale, non ping ripetuti. Annotate se il guasto segue un particolare salto successivo, una dimensione di pacchetto o una transizione dopo la riconnessione, perché questi tre schemi indicano riparazioni diverse.
Infine, annotate perché i percorsi sono considerati equivalenti e come un guasto dovrebbe metterne uno fuori servizio. Il multipath è sicuro solo quando i percorsi sono davvero intercambiabili, e questa è un’affermazione di progetto che vale la pena verificare invece di dare per scontata.