Cosa mostra Traceroute? Come leggere i risultati

Traceroute sembra offrire più certezze di quante ne dia davvero. L'output presenta righe ordinate e numerate, ma si tratta di osservazioni ricavate da una serie di sonde, non di una mappa perfetta di Internet.

Traceroute mostra gli hop di livello 3 che rispondono tra una sorgente e una destinazione, insieme a campioni dei tempi di andata e ritorno dalla sorgente a ciascun hop. Non garantisce che ogni router sia visibile, non misura il ritardo tra due hop adiacenti e non dimostra la perdita di pacchetti. Una risposta mancante può semplicemente indicare che un dispositivo ha scelto di non rispondere alla sonda.

Cosa mostra effettivamente traceroute

Un traceroute classico tenta di rivelare il percorso una risposta alla volta. Per ogni hop visibile, può riportare un numero di hop, un indirizzo IP, un nome host opzionale e uno o più campioni di tempo di andata e ritorno. Il modello IETF per le misurazioni traceroute li identifica come campi dei risultati comuni.

Le parole da tenere presenti sono che rispondono. Una riga rappresenta un'interfaccia che ha risposto a una sonda, non necessariamente un intero router fisico e certamente non tutti i dispositivi che hanno gestito il traffico. Due indirizzi con lo stesso numero di hop possono essere interfacce alternative che rispondono su un percorso con bilanciamento del carico. Il dispositivo che non compare in una riga può comunque inoltrare i pacchetti correttamente.

È quindi meglio leggere traceroute come un'osservazione del percorso da una determinata sorgente, in un dato momento e con uno specifico metodo di sondaggio. Eseguilo più tardi, tramite una VPN o da un'altra rete e il risultato può cambiare. È un comportamento normale dell'instradamento, non necessariamente un guasto.

Il piccolo accorgimento del TTL dietro ogni hop

Il meccanismo è intelligente. In IPv4, ogni pacchetto inoltrato porta un valore Time to Live, solitamente trattato come un limite di hop. Un router lo riduce prima dell'inoltro. Quando il valore scade, il router può restituire un messaggio ICMP Time Exceeded invece di inoltrare il pacchetto.

Traceroute invia inizialmente una o più sonde con TTL 1, che scadono al primo hop instradato. Il gruppo successivo usa TTL 2 e può raggiungere un hop più lontano. Il processo prosegue finché la destinazione risponde o lo strumento raggiunge il massimo configurato. IPv6 usa un campo chiamato proprio Hop Limit, ma il principio di individuazione è simile. I dettagli dei protocolli sono documentati in RFC 5388 e nella specifica IPv6.

La risposta di destinazione dipende dall'implementazione. Una traccia tradizionale basata su UDP spesso termina quando la destinazione segnala che la porta scelta non è raggiungibile. Finestre tracert utilizza le sonde ICMP Echo e termina quando la destinazione risponde. Esistono anche varianti basate su TCP. Questo è il motivo per cui due programmi traceroute possono intraprendere lo stesso viaggio di base inviando diversi tipi di sonde.

Come leggere una riga di output

Considera una tipica riga di Windows con un numero di hop, tre valori temporali e un indirizzo. Le colonne sono semplici da leggere, purché non si cerchi di ricavarne più di ciò che possono indicare.

I tre valori centrali meritano particolare attenzione: sono tre tentativi distinti. Microsoft li descrive come misurazioni di andata e ritorno dal tuo dispositivo a quell'hop nella sua documentazione ufficiale di tracert. Non sono tre fasi del viaggio di un pacchetto e non sono un riepilogo minimo/medio/massimo già pronto.

Un RTT include anche il percorso di risposta e il tempo di elaborazione sul dispositivo che risponde. Il routing Internet può essere asimmetrico, quindi la risposta potrebbe arrivare attraverso un percorso diverso. RFC 9198 spiega perché una misurazione ICMP di questo tipo non è una stima riproducibile del ritardo di un'applicazione. Considera il valore come un campione dell'intero tragitto tra la sorgente e il dispositivo che risponde, non come un cronometro posto sul cavo tra due router.

Gli asterischi sono silenzio, non un verdetto

Un asterisco significa che la sonda non ha ricevuto una risposta prima del timeout. Questo è tutto ciò che significa da solo. Il router potrebbe filtrare quel tipo di sonda, limitare la velocità delle risposte ICMP, depriorizzare le risposte del piano di controllo o inviare una risposta che viene persa sulla via del ritorno.

Un asterisco accanto a due tempi misurati indica che una delle tre sonde non ha ricevuto risposta. Tre asterischi o «Request timed out» indicano che nessuna sonda di quella riga ha ricevuto risposta in tempo. Se gli hop successivi, compresa la destinazione, rispondono, la traccia è proseguita oltre quel TTL: la riga senza risposta non dimostra quindi un errore di inoltro. Con l'instradamento multipercorso, le sonde successive potrebbero non aver attraversato esattamente la stessa sequenza di dispositivi. L'esempio di Microsoft mostra proprio righe con timeout seguite da una risposta riuscita della destinazione.

Questa è una cattiva diagnosi comune nella lettura del traceroute: trattare ogni salto silenzioso come perdita di pacchetti. Inoltrare il traffico e rispondere alle sonde diagnostiche sono compiti diversi. Un router può eseguire il primo rifiutando il secondo.

Per indagare davvero sulla perdita di pacchetti, ripeti le misurazioni. Su Windows, PathPing combina l'individuazione del percorso con una serie più lunga di sonde e calcola le statistiche. Anche in questo caso, confronta la perdita segnalata verso un router intermedio con gli hop successivi prima di concludere che il traffico inoltrato ne risente.

Come non dare la colpa al router sbagliato

La domanda utile non è “Quale riga ha il numero più grande?” È "Dove inizia un cambiamento e persiste verso la destinazione?"

Distanza, congestione, Wi-Fi, instradamento della VPN, code e comportamento dei dispositivi che rispondono possono tutti modificare l'RTT. Un singolo campione elevato è un indizio, non una prova conclusiva. Cerca un andamento ripetuto che prosegua negli hop successivi e corrisponda al sintomo effettivo dell'utente.

Traceroute non misura nemmeno la capacità di download o upload. Se il problema è che «la connessione sembra lenta ovunque», un test di velocità Internet controlla il throughput, la latenza e il jitter in modo più diretto. I due strumenti rispondono a domande diverse.

Ciò che traceroute non può mostrare in modo affidabile

Traceroute fornisce un'istantanea rapida del percorso. Leggerlo bene significa sapere cosa lascia fuori quella istantanea.

• Potrebbe non mostrare tutti gli hop di livello 3: alcuni dispositivi non rispondono mai alle sonde.
• Normalmente non mostra gli switch trasparenti di livello 2. Questi dispositivi inoltrano frame senza comparire come hop IP.
• Osserva il percorso di andata delle sonde, mentre ogni risposta può seguire un percorso di ritorno diverso.
• Può campionare uno dei diversi percorsi a pari costo, anziché tutti quelli possibili.
• Non stabilisce percentuali stabili di perdita di pacchetti da una manciata di sonde.
• Non può dimostrare il percorso che seguirà ogni flusso di applicazione, soprattutto quando i protocolli di sonda sono diversi.
• Un indirizzo IP o un nome host non è una lettura esatta della posizione fisica.

Usa un test complementare adatto alla domanda ancora aperta. Se un sito web risponde ma un determinato servizio no, un controllo mirato delle porte può verificare specifiche porte TCP pubbliche dal nodo edge di ClockTools. Se gli intervalli privati o i confini CIDR rendono difficile interpretare la traccia, il calcolatore di sottoreti IP aiuta a separare le porzioni di rete e host.

Tracert, traceroute e tipi di sonde

Windows nomina il comando tracert. macOS, Linux, BSD e molti dispositivi di rete utilizzano comunemente traceroute. L'output sembra familiare su tutte le piattaforme, ma le sonde predefinite possono differire.

Finestre tracert invia richieste ICMP Echo con valori TTL crescenti. Il tradizionale traceroute simile a Unix inizia comunemente con UDP, sebbene le implementazioni e le opzioni possano anche utilizzare ICMP o TCP. Evita la regola generale secondo cui "traceroute utilizza sempre UDP" o "traceroute utilizza sempre ICMP". Decidono il programma e il metodo selezionato.

Per una rapida traccia su Windows senza risolvere i nomi host, usa tracert /d example.com. Su un tipico sistema macOS o Linux, inizia con traceroute example.com e leggere il manuale del sistema per le opzioni di protocollo e timeout. Il /d flag può velocizzare una traccia di Windows ignorando la risoluzione dei nomi reverse-DNS, ma non nasconde gli indirizzi IP nell'output.

Il termine tracepath di solito si riferisce a un'utilità simile a Unix correlata con un'interfaccia e un modello di privilegi diversi. MTR e WinMTR ripetono le sonde nel tempo. PathPing aggiunge statistiche ripetute dopo aver scoperto il percorso. Scegli tra questi a seconda che tu abbia bisogno di un'istantanea del percorso rapido o di una misurazione prolungata.

Il ruolo di ClockTools

Una normale pagina web non può inviare le stesse sonde ICMP, UDP o TCP a basso livello di un comando eseguito nel terminale locale. Le sandbox dei browser e l'ambiente Cloudflare Worker di ClockTools non offrono il controllo necessario sul TTL dei pacchetti: per questo ClockTools non inventa una tabella degli hop.

Il test diagnostico Trace Route di ClockTools opera entro questo limite. Il protocollo HTTP e l'RTT del client descrivono il tratto dal browser a ClockTools. Una richiesta HTTP o HTTPS pubblica separata parte dal nodo edge di ClockTools verso la destinazione e ne riporta raggiungibilità, stato, tempo di risposta, tipo di contenuto e reindirizzamenti. È utile per un rapido controllo di un sito dall'esterno, ma non è la tabella degli hop locali del tuo portatile.

Nello screenshot, il callout 1 contrassegna l'avviso di limitazione; callout 2 contrassegna i dati della risposta di destinazione. L'esempio utilizza example.com, un dominio di documentazione pubblica, non un host privato, e generalizza il codice edge specifico della richiesta.

Usa un URL pubblico di tua proprietà, che gestisci o che sei autorizzato a verificare. Se la destinazione risponde rapidamente dal nodo edge ma sembra lenta sul tuo dispositivo, vale la pena controllare il Wi-Fi locale, il percorso dell'ISP, un'eventuale VPN, il carico del dispositivo o il comportamento del browser. I due test partono però da punti di osservazione diversi e possono seguire percorsi differenti. Se entrambi falliscono, sia dal nodo edge sia localmente, diventano più plausibili problemi di DNS, hosting, firewall o disponibilità della destinazione.

Una pratica sequenza di risoluzione dei problemi

Inizia con il sintomo, non con il cassetto degli attrezzi.

• Il sito web è raggiungibile dall'esterno della connessione? Esegui la diagnostica del percorso ClockTools e annota lo stato, i reindirizzamenti e il tempo di risposta.
• Tutta la tua connessione è lenta? Confronta throughput, ping e jitter con un test di velocità di Internet.
• Hai bisogno della visualizzazione hop-by-hop locale? Esegui tracert o traceroute sul dispositivo e sulla rete interessati.
• Un servizio non funziona mentre l'host risponde? Dal nodo edge di ClockTools, controlla solo la porta TCP pubblica pertinente che sei autorizzato a verificare.
• Un RTT elevato o un timeout è comparso una sola volta? Ripeti la traccia. Un comportamento persistente negli hop successivi conta più di una singola riga allarmante.
• Stai confrontando indirizzi pubblici e privati? Qual è il mio IP? identifica il tuo indirizzo pubblico visibile, mentre il calcolatore della sottorete aiuta con gli intervalli di rete privata.

Questa sequenza evita un errore comune: usare un solo strumento diagnostico per rispondere a ogni domanda sulla rete. Raggiungibilità, osservazione del percorso, perdita persistente di pacchetti, capacità di trasferimento e disponibilità dei servizi sono aspetti collegati, ma non intercambiabili.

Condividi i risultati del traceroute in modo sicuro

Una traccia può esporre indirizzi IP pubblici e privati, nomi host interni, nomi di provider, modelli temporali e parti della progettazione di una rete. Prima di inserire l'output in un forum, ticket, articolo o screenshot, rimuovi i dettagli di cui il destinatario non ha bisogno.

Oscura i nomi dei dispositivi interni, i nomi utente incorporati nei nomi host, gli indirizzi privati quando la topologia è irrilevante e gli indirizzi pubblici se non vuoi che siano associati al post. Mantenere una struttura sufficiente affinché il problema rimanga comprensibile: i numeri di hop, la presenza di timeout e i tempi rappresentativi sono spesso sufficienti.

Non dare per scontato tracert /d anonimizza una traccia. Salta la risoluzione dei nomi; visualizza ancora gli indirizzi IP di risposta. Ricorda inoltre che un'ipotesi di geolocalizzazione IP non è una posizione fisica precisa, ma può rivelare un provider o un'ampia regione.

La migliore interpretazione di traceroute è prudente. Indica quali sonde hanno ricevuto risposta, quanto sono durati i percorsi di andata e ritorno e dove può iniziare un andamento ricorrente. Diventa davvero utile quando unisci questi dati a test ripetuti e al sintomo che cerchi di spiegare.