Network pills: traceroute

Spread the love
network traceroute
network traceroute

traceroute (per gli utenti Windows il programma si chiama tracert) è un programma di utilità per il network che troviamo nei sistemi operativi Linux e Mac che permette di seguire il percorso di un pacchetto di dati dal nostro computer ad un qualsiasi altro host per evidenziare criticità inm questa trasmissione.

Il percorso di un un pacchetto in Internet (ma anche in una rete chiusa, come ad esempio un’azienda) è un percorso fatto di tanti punti discreti in cui il primo punto (origine) è il PC che invia il pacchetto e l’ultimo punto (destinazione) è l’host che vogliamo raggiungere. Per andare dal’origine alla destinazione, il pacchetto attraversa (ogni device attraversato è un “hop” ovvero un salto) un certo numero di dispositivi che hanno il compito di fare avanzare il pacchetto: sono i router. Ogni router, quando riceve il pacchetto dal suo predecessore, guarda nell’intestazione TCP/IP qual è l’indirizzo di destinazione e decide in base ad un algoritmo di percorso minimo (shortest path) a quale router inviarlo per farlo progredire nel suo cammino.

Ogni hop comporta un tempo che va a sommarsi al tempo totale che il pacchetto impiegherà.

Inoltre, per evitare che un pacchetto giri all’infinito senza raggiungere la destinazione, il protocollo IP prevede di dargli un numero massimo di chance prima di essere scartato: è il “tempo di vita” (TTL Time To Live) che è un numero intero che viene diminuito di 1 ad ogni hop. Ogni device che prende in carico il pacchetto, prima di inoltrarlo al prossimo device prende il valore di TTL nell’intestazione TCP e lo diminuisce di 1:

TTL = TTL -1

Traceroute ci aiuta a diagnosticare eventuali problemi di rete nel raggiungere un certo host analizzando il percorso di un singolo pacchetto ICMP.

Un altro elemento chiave da comprendere è il “tempo di andata e ritorno” (RTT, Round Trip Time). Traceroute assicura che ogni hop sulla strada per un dispositivo di destinazione rilasci un pacchetto e restituisca un messaggio di errore ICMP. Ciò significa che traceroute può misurare la durata del tempo tra l’invio dei dati e la ricezione del messaggio ICMP per ogni hop, fornendo il valore RTT per ogni hop.

Ma come fa traceroute a ritornare un risultato ad ogni hop?

Prima cosa: traceroute fa affidamento sulla capacità di routing di ogni singolo nodo che separa l’origine dalla destinazione e, in realtà, lui non invia un solo pacchetto ma ne invia molti, almeno quanto è il numero massimo di hop previsto. Il funzionamento è questo

  1. traceroute invia un pacchetto ICMP verso la destinazione finale con TTL = 1.
  2. Ciò significa che appena il pacchetto ha raggiunto il primo router sarà già morto e il router informa di questo traceroute che mette via l’indirizzo IP del router raggiunto assieme al RTT e lo stampa.
  3. traceroute invia quindi un nuovo pacchetto ICMP verso la destinazione e gli assegna un TTL=2; il pacchetto raggiungerà il router 1 (che potrebbe anche essere diverso da quello di prima, ma non importa); questi a sua volta lo consegna al router 2 e qui il pacchetto muore. Quindi router 2 invia indietro un pacchetto ICMP all’origine con l’informazione dell’esaurimento del TTL e quindi traceroute pusha nella coda l’indirizzo IP del router2 insieme al RTT.

E così via. Quindi traceroute invia fino a 30 pacchetti, ogni singolo invio è detto probe, (a meno che non gli indichiamo noi il numero di pacchetti massimo con l’opzione -m max_ttl o --max-hops=max_ttl) e per ognuno registra l’indirizzo raggiunto e il tempo di andata e ritorno.

Leggere l’output di traceroute

Un esempio è il seguente

root@jsbach:/home/marcob# traceroute -m 30 www.google.com
traceroute to www.google.com (142.250.180.164), 30 hops max, 60 byte packets
 1  _gateway (192.168.83.125)  2.392 ms  2.375 ms  2.335 ms
 2  10.8.0.1 (10.8.0.1)  45.510 ms  38.503 ms  38.480 ms
 3  192.168.251.30 (192.168.251.30)  53.828 ms  54.004 ms  53.981 ms
 4  192.168.255.21 (192.168.255.21)  41.459 ms  53.936 ms  42.337 ms
 5  194.149.188.16 (194.149.188.16)  53.890 ms  53.868 ms  53.845 ms
 6  * 194.149.187.14 (194.149.187.14)  51.268 ms  51.217 ms
 7  * * partner-network-device.nflxvideo.net (66.197.165.233)  44.639 ms
 8  72.14.220.82 (72.14.220.82)  58.851 ms  55.300 ms  61.741 ms
 9  * * *
10  142.251.50.134 (142.251.50.134)  77.915 ms 142.251.50.138 (142.251.50.138)  76.934 ms 108.170.232.168 (108.170.232.168)  77.465 ms
11  142.250.211.23 (142.250.211.23)  77.647 ms mil04s44-in-f4.1e100.net (142.250.180.164)  77.586 ms  77.523 ms
root@jsbach:/home/marcob# 

Il comando stampa una intestazione con scritto il nome host (con il suo indirizzo IP che si è fatto dare dal DNS locale o dal file /etc/hosts), il numero massimo di probe che invierà e la dimensione del pacchetto (60 bytes).

Segue la descrizione di ogni probe (ogni probe si avanza di un hop con il meccanismo di aumento di 1 del TTL per ogni probe). Ogni riga ha questa struttura:

#hop | nome host (se esiste, altrimenti l'indirizzo IP) | (indirizzo IP) | RTT1 | RTT2 | RTT3 |

Hop 1: _gateway è il device che mi connette ad internet, in questo momento il mio cellulare utilizzato come hotspot; il dhcp mi ha dato come indirizzo 192.168.83.118, _gateway ha l’indirizzo 192.168.83.125 (sono chiaramete sulla stessa sottorete 192.168.83). Seguono poi tre misure temporali (2.392 ms 2.375 ms 2.335 ms) che sono rispettivamente tre round tript time per tre distinti pacchetti (quindi per ogni probe in realtà traceroute invia 3 pacchetti e non uno soltanto): questo per mostrare la coerenza, o una sua mancanza, nel percorso.

Hop 2: 10.8.0.1 è il primo router incontrato dal pacchetto

e così via.

Cosa sono gli asterischi?

In realtà, se leggiamo bene, questi asterischi sono scritti nella colonna sbagliata, dovrebbero essere scritti così:

 1  _gateway (192.168.83.125)  2.392 ms  2.375 ms  2.335 ms
 2  10.8.0.1 (10.8.0.1)  45.510 ms  38.503 ms  38.480 ms
 3  192.168.251.30 (192.168.251.30)  53.828 ms  54.004 ms  53.981 ms
 4  192.168.255.21 (192.168.255.21)  41.459 ms  53.936 ms  42.337 ms
 5  194.149.188.16 (194.149.188.16)  53.890 ms  53.868 ms  53.845 ms
 6  194.149.187.14 (194.149.187.14)  *          51.268 ms  51.217 ms
 7  partner-network-device.nflxvideo.net (66.197.165.233)  * * 44.639 ms
 8  72.14.220.82 (72.14.220.82)  58.851 ms  55.300 ms  61.741 ms
 9  * * *
10  142.251.50.134 (142.251.50.134)  77.915 ms 
    142.251.50.138 (142.251.50.138)  76.934 ms 
    108.170.232.168 (108.170.232.168)  77.465 ms
11  142.250.211.23 (142.250.211.23)  77.647 ms 
    mil04s44-in-f4.1e100.net (142.250.180.164)  77.586 ms  77.523 ms

cioè sono dati che vanno scritti nelle colonne dei RTT: sono pacchetti che si sono persi; a volte si perdono per un singolo invio (hop 6), a volte in due (hop 7) a volte in tutti e tre i probe (come si vede all’hop 9).

Questo a significare che statisticamente non tutti i router riusciranno a mandarci indietro il pacchetto e perderemo il tempo di transito di quell’hop.

Analisi dei risultati

Prima di addentrarci nell’analisi occorre rscrivere l’outut in un modo più ordinato:

root@jsbach:/home/marcob# traceroute -m 30 www.google.com
traceroute to www.google.com (142.250.180.164), 30 hops max, 60 byte packets
 1  _gateway (192.168.83.125)  				   2.392 ms   2.375 ms   2.335 ms
 2  10.8.0.1 (10.8.0.1)  45.510 ms  		  38.503 ms  38.480 ms
 3  192.168.251.30 (192.168.251.30)  		  53.828 ms  54.004 ms  53.981 ms
 4  192.168.255.21 (192.168.255.21)  		  41.459 ms  53.936 ms  42.337 ms
 5  194.149.188.16 (194.149.188.16)  		  53.890 ms  53.868 ms  53.845 ms
 6  194.149.187.14 (194.149.187.14)               *          51.268 ms  51.217 ms
 7  partner-network-de... (66.197.165.233)        *          *          44.639 ms
 8  72.14.220.82 (72.14.220.82)                   58.851 ms  55.300 ms  61.741 ms
 9  						  * 	     *          *
10  142.251.50.134 (142.251.50.134)  		  77.915 ms 
    142.251.50.138 (142.251.50.138)  		  76.934 ms 
    108.170.232.168 (108.170.232.168)  	          77.465 ms
11  142.250.211.23 (142.250.211.23)  		  77.647 ms 
    mil04s44-in-f4.1e10  (142.250.180.164)        77.586 ms  77.523 ms
root@jsbach:/home/marcob# 

In generale i tempi di latenza (i delta più grandi) si possono localizzare all’inizio, in mezzo o alla fine del percorso. Possono esserci problemi soltanto nei casi in cui la latenza riguarda l’inzio del percorso (problemi del gateway) oppure all’ultimo passaggio, che può essere sintomo di diversi problemi, per esempio uno può essere quello della presenza di un firewall in entrata (della destinazione) che rende difficile la consegna dei pacchetti all’ultimo step.

Riferimenti

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.