Come usare il comando 'traceroute' in Linux

Il comando traceroute viene utilizzato in Linux per mappare il viaggio che un pacchetto di informazioni intraprende dalla sua origine alla sua destinazione. Un uso per traceroute è quello di individuare quando la perdita di dati si verifica in tutta la rete, il che potrebbe significare che un nodo non funziona.

Poiché ogni hop nel record riflette un nuovo server o router tra il PC di origine e l'obiettivo desiderato, rivedere i risultati di una scansione traceroute consente anche di identificare i punti lenti che possono influire negativamente sul traffico di rete.

Come funziona

Valutando il percorso specifico seguito dal traffico di rete (o individuando il gateway malfunzionante che sta scartando i pacchetti) presenta diverse sfide per la risoluzione dei problemi. Traceroute utilizza il protocollo IP tempo di vivere campo per sollecitare una risposta TIME_EXCEEDED ICMP da ciascun gateway lungo il percorso verso un host di destinazione.

L'unico parametro che è necessario includere quando si esegue il comando traceroute è il nome host o l'indirizzo IP della destinazione.

Traceroute Sintassi e Switch

traceroute -dFInrvx -f first_ttl -g porta -io io affronto -m max_ttl -p porta -q nqueries -S src_addr -t tos -w tempo di attesa -z pausemsecs ospite packetlen

Mentre sopra è come deve essere scritto il comando traceroute per poter funzionare nella riga di comando, le prestazioni o l'output del comando possono essere modificati specificando uno o più parametri opzionali.

• -f: Imposta il tempo di vita iniziale utilizzato nel primo pacchetto sonda in uscita.
• -F: Imposta il bit "non frammentare".
• -d: Abilita il debug a livello di socket.
• -g: Specificare un gateway di percorso della sorgente libera (massimo 8).
• -io: Specificare un'interfaccia di rete per ottenere l'indirizzo IP di origine per i pacchetti di probe in uscita. Questo è normalmente utile solo su un host multi-homed. (Vedi il-S bandiera per un altro modo per farlo.)
• -IO: Usa ICMP ECHO invece dei datagrammi UDP.
• -m: Imposta il tempo massimo di vita (numero massimo di hop) utilizzato nei pacchetti sonda in uscita. Il valore predefinito è 30 hop (lo stesso valore predefinito utilizzato per le connessioni TCP).
• -n: Stampa gli indirizzi hop numericamente anziché simbolicamente e numericamente (salva una ricerca nome-indirizzo del server dei nomi per ogni gateway trovato nel percorso).
• -p: Impostare il numero di porta UDP di base utilizzato nei probe (il valore predefinito è 33434). Traceroute spera che nulla sia in ascolto sulle porte UDP base a base + nhops - 1 nell'host di destinazione (quindi verrà restituito un messaggio PORT_UNREACHABLE ICMP per terminare la traccia del percorso). Se qualcosa è in ascolto su una porta nell'intervallo predefinito, questa opzione può essere utilizzata per selezionare un intervallo di porte inutilizzato.
• -r: Ignora le normali tabelle di routing e invia direttamente a un host su una rete collegata. Se l'host non si trova su una rete direttamente collegata, viene restituito un errore. Questa opzione può essere utilizzata per eseguire il ping di un host locale tramite un'interfaccia che non ha alcuna route (ad es., Dopo che l'interfaccia è stata trascinata da instradato (8C)).
• -S: Utilizzare il seguente indirizzo IP (che di solito viene indicato come numero IP, non come nome host) come indirizzo sorgente nei pacchetti sonda in uscita. Su host multi-homed (quelli con più di un indirizzo IP), questa opzione può essere utilizzata per forzare l'indirizzo di origine ad essere qualcosa di diverso dall'indirizzo IP dell'interfaccia su cui è inviato il pacchetto di probe. Se l'indirizzo IP non è uno degli indirizzi di interfaccia di questa macchina, viene restituito un errore e non viene inviato nulla. (Vedi il-io bandiera per un altro modo per farlo.)
• -t: Impostare il tipo di servizio in pacchetti sonda al seguente valore (zero predefinito). Il valore deve essere un numero decimale nell'intervallo compreso tra 0 e 255. Questa opzione può essere utilizzata per verificare se diversi tipi di servizio generano percorsi diversi. (Se non stai usando 4.4bsd, questo potrebbe essere accademico, dato che i normali servizi di rete come telnet e ftp non ti permettono di controllare i TOS.) Non tutti i valori di TOS sono legali o significativi: vedi le specifiche IP per le definizioni. I valori utili sono probabilmente `-t 16 '(basso ritardo) e `-t 8 '(alto rendimento).
• -v: Uscita dettagliata. I pacchetti ICMP ricevuti diversi da TIME_EXCEEDED e UNREACHABLEs sono elencati.
• -w: Imposta il tempo (in secondi) per attendere una risposta a una sonda (predefinito 5 sec.).
• -X: Attiva i checksum IP. Normalmente, ciò impedisce a traceroute di calcolare i checksum IP. In alcuni casi, il sistema operativo può sovrascrivere parti del pacchetto in uscita ma non ricalcolare il checksum; quindi, in alcuni casi l'impostazione predefinita è di non calcolare i checksum e l'utilizzo-X li fa calcolare Si noti che i checksum sono solitamente necessari per l'ultimo hop quando si utilizzano le sonde ECHO ICMP (-IO), quindi vengono sempre calcolati quando si utilizza ICMP.
• -z: Imposta il tempo (in millisecondi) per mettere in pausa tra i probe (default 0). Alcuni sistemi come Solaris e router di Cisco, messaggi icmp con limite di velocità. Un buon valore da usare con questo è 500 (ad es. 1/2 secondo).

Interpretazione dei risultati

Traceroute delinea il percorso seguito da un pacchetto IP a un host internet lanciando pacchetti di probe UDP con un piccolo TTL (time to live), quindi ascoltando una risposta ICMP "time exceeded" da un gateway. Iniziamo le nostre sonde con un TTL di uno e aumentiamo di uno finché non otteniamo una "porta irraggiungibile" dell'ICMP (che significa che il pacchetto è arrivato a destinazione) o raggiungiamo un valore massimo di tentativi, che ha un valore predefinito di 30 luppoli e può essere modificato con il-m bandiera.

Quando esegue traceroute, invia tre sonde ad ogni impostazione TTL e quindi stampa una riga sulla console mostrando il TTL, l'indirizzo del gateway e il tempo di andata e ritorno di ciascuna sonda. Se le risposte della sonda provengono da gateway diversi, viene stampato l'indirizzo di ciascun sistema di risposta. Se non vi è risposta entro un intervallo di timeout di cinque secondi (modificato con-w flag), viene stampato un asterisco per quella sonda.

Per impedire che l'host di destinazione venga sopraffatto dall'elaborazione del pacchetto sonda UDP, la porta di destinazione viene impostata su un valore che non è probabile che venga utilizzato da tale dispositivo. Se una rete o un servizio nella destinazione utilizza quella porta, modificare il valore utilizzando-p bandiera.

Un esempio di utilizzo e output restituirà risultati simili a questo esempio:

yak 71% traceroute nis.nsf.net. traceroute a nis.nsf.net (35.1.1.48), 30 luppolo max, 38 byte pacchetto 1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32. 216.1) 39 ms 39 ms 19 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms 5 ccn -nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms 8 129.140. 70.13 (129.140.70.13) 99 ms 99 ms 80 ms 9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms 10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms 11 nic.merit.edu (35.1 .1.48) 239 ms 239 ms 239 ms

Si noti che la seconda e la terza riga sono uguali. Questo risultato si riferisce a un kernel buggy nel sistema di secondo hop-lbl-csam.arpa-che inoltra pacchetti con un TTL zero (un bug nella versione distribuita di 4.3 BSD). È necessario indovinare quale percorso stanno intraprendendo i pacchetti in tutto il paese poiché NSFNet (129.140) non fornisce traduzioni indirizzo-nome per i suoi NSS.

Un esempio più interessante è:

yak 72% traceroute allspice.lcs.mit.edu. traceroute a allspice.lcs.mit.edu (18.26.0.115), 30 luppoli max 1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms 5 ccn-nerif22 .Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms 8 129.140.70.13 ( 129.140.70.13) 80 ms 79 ms 99 ms 9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms 10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms 11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms 12 * * * 13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 ALLSPICE.LCS.MIT.EDU (18.26 .0.115) 339 ms 279 ms 279 ms

Nota che i gateway a 12, 14, 15, 16 e 17 saltano via o non inviano messaggi "superati" ICMP o li inviano con un TTL troppo piccolo per raggiungerci. Le righe dalla 14 alla 17 eseguono il codice del gateway MIT C che non invia messaggi "superati".

Il gateway silenzioso 12 nell'esempio sopra può essere il risultato di un bug nel codice di rete di BSD 23 e le sue derivate: Macchine che eseguono codice 4.3 e in precedenza inviano un messaggio non raggiungibile utilizzando qualsiasi cosa TTL rimanga nel datagramma originale. Dal momento che, per i gateway, il TTL rimanente è zero, l'ICMP "tempo superato" è garantito per non essere restituito a noi. Il comportamento di questo bug è leggermente più interessante quando appare sul sistema di destinazione:

1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1 ) 19 ms 39 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms 5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms 6 csgw. Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 rip.Berkeley.EDU (128.32.131.22) 59 Signorina ! 39 ms! 39 ms!

Si noti che ci sono 12 "gateway" (13 è la destinazione finale) e l'ultima metà di essi manca. Quello che sta realmente accadendo è che il server ha chiamato riposa in pace (un Sun-3 con Sun OS 3.5) usa il TTL dal nostro datagramma in arrivo come TTL nella sua risposta ICMP. Quindi, la risposta scadrà sul percorso di ritorno (senza alcun avviso inviato a nessuno dal momento che gli ICMP non vengono inviati per ICMP) finché non sondiamo con un TTL che è almeno il doppio della lunghezza del percorso, in altre parole, il rip è in realtà solo sette saltella via.

Una risposta che ritorna con un TTL di 1 è un indizio di questo problema. Traceroute stampa un "!" dopo il tempo se il TTL è inferiore o uguale a 1. Dato che i fornitori spediscono un sacco di software obsoleti (DEC's Ultrix, Sun 3.x) o non standard (HPUX), aspettarsi di vedere questo problema frequentemente e fare attenzione a raccogliere il host di destinazione delle tue sonde.

Altre possibili annotazioni dopo il tempo sono! H, ! N, oP! (host, rete o protocollo non raggiungibile),!S (rotta di origine fallita),! F- (necessaria frammentazione: viene visualizzato il valore di rilevamento MTU percorso RFC1191),!X (comunicazione amministrativamente vietata),! V (violazione della precedenza dell'host),! C (precedenza interruzione), o! (Codice ICMP non raggiungibile). Questi codici sono definiti da RFC1812, che sostituisce RFC1716. Se quasi tutte le sonde producono un qualche tipo di host irraggiungibile, traceroute si arrenderà e uscirà.

Questo programma è destinato all'uso nei test, nelle misurazioni e nella gestione della rete. Dovrebbe essere usato principalmente per l'isolamento manuale dei guasti. A causa del carico che potrebbe imporre sulla rete, non è saggio utilizzare traceroute durante le normali operazioni o da script automatici.