Spiegare il Comando Traceroute

Traceroute può essere uno strumento prezioso quando si cerca di diagnosticare problemi di connessione ad host su altre reti. Tuttavia per essere utilizzato in modo efficace bisogna capire come funziona e cosa significa l'output.

Traceroute funziona manipolando il valore Time-To-Live (TTL) nell'intestazione dell'IP (figura 1). Poiché ho dovuto fare i miei esempi utilizzando la rete interna di Stratus ho X'editato la rappresentazione esadecimale dell'indirizzo IP nelle tracce del pacchetto e ho tradotto tutti gli ottetti in qualsiasi notazione decimale doted in un codice univoco di lettere da A a W. Il numero di lettere rappresenta il numero di cifre nell'ottetto. Cioè AAA rappresenta un numero di 3 cifre, mentre J rappresenta un numero di 1 cifra.

Figura 1 - Telaio packet_monitor con TTL evidenziato

Ogni router che elabora il pacchetto diminuirà il valore TTL di 1 e se il valore TTL è maggiore di 0 passerà il pacchetto al router successivo o alla destinazione finale. Se il valore TTL è 0 il router scarta il pacchetto e *può* inviare al mittente un messaggio di ritorno al superamento del tempo ICMP. La chiave è *may*, alcuni router non invieranno un messaggio di ritorno del tempo superato o lo faranno solo se non sono occupati. Inoltre alcuni firewall bloccheranno il messaggio ICMP, quindi anche se il router invia il messaggio di superamento del tempo, l'host che esegue il traceroute potrebbe non vederlo mai.

Traceroute inizia con l'invio di un messaggio alla destinazione di destinazione con un valore TTL pari a 1. Il tempo che impiega dal momento in cui invia il messaggio fino a quando non riceve una risposta.

Figura 2 - traceroute frame traceroute_monitor a pacchetti e risposta

Di default il comando traceroute invia tre messaggi con un TTL di 1 e riporta tutte e tre le volte il nome e/o l'indirizzo IP del router che ha inviato la risposta. Uso sempre l'argomento -numerico per non dover aspettare la risoluzione del nome (figura 3). Traceroute poi incrementa il TTL di 1 e lo fa di nuovo. Continuerà ad aumentare il TTL fino a quando non otterrà una risposta dalla destinazione di destinazione o un qualche limite, 30 (di default), viene raggiunto. Potete trovare la documentazione su tutti gli argomenti del traceroute nel manuale di OpenVOS STREAMS TCP/IP Administrator's Guide (R419 ).

Figura 3 - uscita traceroute

Ci si aspetterebbe che con l'aumento del TTL i tempi aumentino e questo è generalmente il caso, ma non sempre, confrontare i terzi tempi riportati del salto 6 (79 ms) e del salto 5 (80 ms) nella figura 3. Ci sono diverse ragioni per questo. In primo luogo, la rete non è deterministica, a volte ci vuole solo più tempo. In secondo luogo, il router al salto N-1 può essere più occupato del router al salto N e ci vuole più tempo per inviare il messaggio ICMP. Infine, il percorso di ritorno dal router N può essere più veloce del percorso di ritorno dal router N-1. Ad esempio, non è necessario che il 4° router invii la sua risposta alla sorgente tramite i router 3, 2 e 1. Potrebbe inviare la sua risposta direttamente al router 1, che potrebbe essere significativamente più veloce. Questo significa che mentre traceroute è molto bravo a segnalare il percorso che un pacchetto prende dall'host di invio all'host di destinazione non si può fare affidamento sul fatto che un pacchetto inviato dall'host di destinazione all'host di invio prenda lo stesso percorso solo al contrario. Questo è noto come instradamento asimmetrico.

Traceroute può aggiungere un flag ad un tempo che indica che ha ricevuto qualcosa di diverso dal messaggio di superamento del tempo previsto. Le bandiere sono:

H - ospite irraggiungibile
N - rete irraggiungibile
P - protocollo irraggiungibile

Ad esempio, la figura 4 mostra che il primo router non sa come raggiungere la rete di destinazione e quindi restituisce un messaggio di rete irraggiungibile e il traceroute termina in quel punto.

Figura 4 messaggi di rete non raggiungibili

Un asterisco (*) al posto dell'ora indica che traceroute non ha ricevuto risposta. Come ho già detto, potrebbe essere che il router non invii un messaggio ICMP che supera l'orario, potrebbe essere che un firewall abbia bloccato il messaggio che supera l'orario al suo ritorno o che un firewall abbia bloccato il messaggio in uscita. Potrebbe anche essere che la rete abbia semplicemente abbandonato il messaggio in uscita o quello di ritorno.

Un singolo o anche due timeout su un salto (figura 5) indica probabilmente o che il router non ha inviato il messaggio perché era occupato o che la rete stava facendo cadere i pacchetti (o entrambi). Notate l'8° hop in figura 5, l'asterisco prima dell'indirizzo IP indica che il primo messaggio nel set è scaduto.

Figura 5 - router occupato o pacchetti caduti

Se il timeout di tutti e tre i messaggi ma i successivi tempi di segnalazione dei luppoli (figura 6) è probabile che il router per quel luppolo non invii semplicemente il tempo ICMP superiore ai messaggi.

Figura 6 - Router non rispondenti

Se tutti i salti superano un certo punto di timeout (figura 7) è probabile che ci sia un firewall che blocca i messaggi in uscita o di ritorno.

Figura 7 - blocco del firewall

C'è un'altra ragione per cui tutto è andato oltre un certo punto. E' quando l'obiettivo non risponde. Non tutti i bersagli rispondono e quando ciò accade si ha qualcosa che assomiglia alla figura 8. La differenza tra le figure 7 e 8 è che nella figura 8 l'ultimo router che invia una risposta è il router locale all'obiettivo. Come si può dire che questo è il caso? A volte l'indirizzamento lo rende ovvio, ad esempio il target è 192.168.1.12 e 192.168.1.1.1 è l'ultimo router a rispondere. Non è così ovvio nella figura 9, EEE.FFF.W.XXX può essere l'ultimo router prima di EEE.FFF.GGG.HHH, hanno i primi 16 bit in comune. Ma senza conoscere lo schema di subnetting utilizzato dalla rete dell'obiettivo non c'è modo di essere sicuri senza chiedere.

Figura 8 - l'obiettivo non risponde

È anche possibile ottenere risposte da due o più router per lo stesso hop (figura 9). Questo può accadere se i router sono in bilanciamento del carico o la rete è instabile e le rotte stanno cambiando o come nel caso della figura 9, il router AAA.BBB.CC.KKK non era il router ottimale e dopo aver inoltrato il pacchetto a AAA.BBB.II.J ha inviato un messaggio di reindirizzamento alla sorgente per cambiare la sua tabella di routing.

Figura 9 - due risposte per lo stesso salto

Esistono due tipi di comandi traceroute che si distinguono per il tipo di messaggio che inviano. Alcuni traceroutes, come quello che si trova sui sistemi Microsoft Windows inviano messaggi ICMP echo request (ping); altri, come quello che gira sotto STCP, inviano messaggi UDP. Sapere quale tipo di traceroute si sta utilizzando è importante se è necessario configurare dei firewall per far passare i pacchetti o scrivere i filtri dell'analizzatore di protocollo. Anche la risposta del target sarà diversa. Se il target riceve una richiesta di ping invierà una risposta ping; se riceve un messaggio UDP, la risposta dipende dal numero di porta. Se la porta è in uso, l'applicazione in ascolto scarterà più che probabilmente il pacchetto perché non soddisfa i requisiti di struttura del messaggio dell'applicazione. Se la porta non è in uso l'host *può* inviare un messaggio ICMP di destinazione non raggiungibile. Per questo motivo traceroute seleziona le porte che in genere non vengono utilizzate.

Quale numero di porta viene visto dall'host di destinazione dipenderà dal numero di luppoli necessari per raggiungerlo. Traceroute avvia la porta di destinazione a 33435 (per default) e incrementa il numero di porta per ogni messaggio (figura 10). Il target vede quindi 3 porte diverse, probabilmente non tutte e tre saranno in uso. La porta di origine si basa sull'ID del processo di invio. Un dato processo utilizzerà sempre la stessa porta sorgente.

Infine, a meno che non ci sia un problema al primo salto, probabilmente non ci sarà molto da fare per risolvere il problema. Una volta che STCP (o lo stack di rete di un qualsiasi host) invia un pacchetto al router locale è fuori dalle sue (e dalle vostre) mani. Tuttavia, se si conosce l'indirizzo IP dell'ultimo hop che risponde o l'hop in cui iniziano a verificarsi improvvisamente dei timeout, si ha un'idea di dove si trova il problema e si può contattare il gruppo corretto di amministratori di rete per risolverlo.