Perché traceroute muore in una sola direzione attraverso un tunnel VPN

L’output di traceroute che si completa in una direzione e stampa righe di asterischi nell’altra sembra un inoltro asimmetrico, e di solito non lo è. Ogni salto mostrato richiede che la sonda arrivi, che un router decida di rispondere e che la risposta torni indietro e venga abbinata alla sonda. Spezzate uno qualsiasi di questi anelli e la riga diventa un asterisco, mentre il tunnel continua a trasportare dati.

La traccia è una prova sulla diagnostica prima di essere una prova sul trasporto. La domanda che vale la pena porsi è quale dei tre anelli ha fallito, e la risposta viene dai pacchetti, non dalla forma dell’output.

Un asterisco è una risposta mancante, non un salto mancante

Traceroute avanza verso l’esterno inviando sonde il cui TTL scade un router più in là a ogni giro. Un router che scarta una sonda scaduta dovrebbe restituire un messaggio ICMP Time Exceeded che nomina se stesso, e lo strumento stampa quel nome. Ciò che lo strumento aspetta davvero è che quel messaggio arrivi entro un timeout. Se il router risponde da un altro indirizzo sorgente, limita la frequenza con cui genera errori o scarta la sonda senza una parola, il giro non produce nulla di stampabile.

Nessuno di questi esiti dice che il percorso di andata è rotto. Un asterisco è un rapporto su posta senza risposta, non su una strada vuota.

Il metodo della sonda decide quale filtro incontrate

Il metodo predefinito su Linux è di solito una porta di destinazione UDP con numero alto, tracert su Windows invia echi ICMP, e a Linux si può ordinare di usare ICMP o TCP invece. Ognuno di questi appare come un tipo diverso di traffico a un firewall con stato o a un gruppo di sicurezza cloud. Confrontare una traccia UDP da un lato con una traccia ICMP dall’altro confronta due esperimenti diversi. Fissate il metodo, la famiglia di indirizzi, l’indirizzo sorgente e il timeout prima di chiamare i risultati una differenza.

Per un confronto equo, eseguite la traccia dagli host che trasportano davvero il traffico e non da un gateway che inoltra per loro conto. Una traccia generata dal router usa il proprio indirizzo sorgente e la propria politica di uscita, che possono essere più severe di qualunque cosa veda un client. Annotate l’invocazione esatta perché la persona successiva possa ripeterla.

Il valore del timeout è l’altra metà dell’esperimento, ed è facile ometterlo dalle note. Un’attesa di due secondi su un percorso congestionato riporta asterischi dove un’attesa di cinque secondi riporta salti. Mantenete il valore identico tra le esecuzioni perché il confronto resti sulla rete.

Il percorso di ritorno è una rotta a sé

Un errore ICMP è un pacchetto ordinario con la propria sorgente e destinazione, e ha bisogno di una rotta di ritorno verso il tracer. Se la politica del tunnel trasporta i prefissi della LAN ma non l’indirizzo del router che ha generato l’errore, il messaggio parte per un percorso che non può raggiungervi. Il filtraggio delle risposte può scartarlo anche quando la rotta esiste, perché il pacchetto arriva da un indirizzo inatteso su un’interfaccia inattesa. È un disallineamento nel piano diagnostico e non un guasto dell’applicazione.

Allargare ogni selettore finché la traccia si completa rende l’immagine più bella e la politica peggiore. Riparate l’indirizzo diagnostico specifico, oppure accettate l’asterisco e provate l’applicazione in un altro modo.

Confermate il tunnel con una richiesta reale

Un handshake TCP sulla porta propria del servizio esercita inoltro, routing di ritorno e filtraggio nella direzione che conta. I comandi qui sotto girano su entrambe le estremità e confrontano ciò che ciascun lato riesce ad aprire. Sostituite la porta del servizio e il nome dell’interfaccia del tunnel con quelli della vostra configurazione.

traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state established

Leggete prima le due esecuzioni di traceroute: se l’esecuzione ICMP mostra salti e quella TCP no, la differenza è nel metodo, non nel percorso. Poi prendete il risultato di curl come risposta a livello applicativo, perché uno scambio completato con un codice di stato sensato significa che i percorsi di andata e di ritorno funzionano per il traffico reale. L’elenco dei socket mostra se la connessione è stabilita, cosa che nessuna traccia può dirvi.

Un tunnel che trasporta una sessione interattiva in entrambe le direzioni mentre un traceroute stampa asterischi è sano e semplicemente poco fotogenico. Conservate l’output dei comandi di ciascun lato come registrazione, e trattate i salti mancanti come una domanda aperta sulla diagnostica e non come un verdetto sulla VPN.