Traceroute: ogni pacchetto ha TTL == 1


17

Sto lavorando su Wireshark lab-IP nella rete di computer - Un approccio dall'alto verso il basso e non capisco perché ogni pacchetto che normalmente è scaduto ha un TTL di 1.

Ecco il mio file di acquisizione di Wireshark. https://www.dropbox.com/s/rr5wgze9j20gzvu/traceroute-56.pcapng?dl=0

Ho catturato l'esecuzione del tracerouteprogramma in Linux (con l'opzione di 56 byte), come eseguito con il seguente comando:

traceroute http://gaia.cs.umass.edu 56

Potete vedere che la maggior parte del TTL del pacchetto == 1 e non so perché, poiché ho appreso che ogni hop successivo ha un TTL di +1 (o più).

PS:

  • Sto usando Lubuntu su VMware con una rete ponte sull'host.
  • L'ho catturato con WireShark sul computer host (Windows)
  • Sono connesso a un AP wireless utilizzando il proprio server DHCP in cima al protocollo NAT

Risposte:


14

Vorrei provare a rispondere a questo, perché è un po 'più complicato che possa sembrare inizialmente.

Sembra che tu sappia già l'operazione di base traceroutema prima di ogni altra cosa ecco un riassunto molto piccolo:

traceroutetenta di determinare tutti i passaggi intermedi dal tuo host a un host di destinazione o solo la distanza, ovvero il numero di salti, dal tuo host a un host di destinazione. Per fare ciò inizia a inviare pacchetti all'host di destinazione con un numero di porta di destinazione "casuale" e un TTL che inizia da 1 e continua ad aumentare.
L'idea è che ogni router in mezzo riduce il TTL di 1. Pertanto, se TTL raggiunge 0 (in realtà non lo fa mai poiché il router che sta per ridurlo a 0 produce un errore prima), il router restituirà un ICMP Messaggio di errore " Tempo di vita superato ", ad es. Pacchetto numero 24 nel file di acquisizione. Ciò che ottieni è che la tua destinazione è più lontana ed è per questo che continui ad aumentare il TTL.
Quando il pacchetto ha un TTL sufficientemente grande da raggiungere la destinazione, verrà visualizzato un messaggio di errore ICMP diverso: " Destinazione non raggiungibile (porta non raggiungibile) ", ad esempio il pacchetto numero 208 nel file di acquisizione. Ciò che ottieni è che l'ultimo TTL utilizzato è effettivamente il numero di hop tra te e il nodo di destinazione. Il motivo per cui si riceve un errore è semplicemente perché si sta inviando un messaggio a una porta "casuale" che il nodo di destinazione (si spera) non sta ascoltando.

Ora andiamo nei dettagli per il tuo file di acquisizione:
dalla pagina del manuale traceroutepossiamo vedere che ogni TTL viene usato 3 volte (opzione '-q') e il protocollo predefinito usato è UDP (opzione '-P'). Esaminando i primi 3 pacchetti UDP, ovvero i pacchetti 8-9-10 , possiamo effettivamente vedere che il TTL è 1 . I successivi 3, ovvero 11-12-13 , hanno un TTL 2 e così via. Quindi dal punto di vista della fonte tutto sembra andare bene.

Quindi, dopo qualche tempo dipendente dal ritardo della rete, iniziamo a ricevere i messaggi di errore previsti. Quindi possiamo vedere che i pacchetti 24-25-26 sono pacchetti di errore " Tempo di vita superato " e ciò significa che la destinazione è più lontana.

Questo avanti e indietro di tentativi ed errori continua fino a quando, infine, il pacchetto 208 e su di esso non è possibile visualizzare i messaggi di errore " Porta non raggiungibile ", il che significa che la destinazione è stata raggiunta.

Contando i pacchetti che invii e le risposte puoi effettivamente scoprire anche dalla traccia quale TTL ha effettivamente funzionato ma è un compito noioso :)

Spero che abbia aiutato


super spiegazione
ksp0422

14

Il client invia solo i primi tre pacchetti con un TTL di 1. I successivi tre vengono inviati con un TTL di 2. I successivi tre vengono inviati con un TTL di 3. E così via e così via.

Un modo più semplice per visualizzarlo è impostare il campo IP TTL come propria colonna in Wireshark. Basta fare clic destro sul valore TTL in qualsiasi pacchetto e selezionare "Applica come colonna": Imposta TTL come colonna in Wireshark

Da lì, puoi vedere che i pacchetti 8,9,10 hanno un TTL di 1. E i pacchetti 11,12,13 hanno un TTL di 2. E così via e così via. TTL in un traceroute

Questo accade perché è così che funziona Traceroute. Sfrutta ciò che fa un router quando riduce un TTL a 0. Invece di continuare a inoltrare il pacchetto, invia al client originale un "messaggio ICMP TTL scaduto in transito" (vedi pacchetto n. 24 nella tua acquisizione) .

Pertanto, come client, quando si invia il primo set di pacchetti con un TTL di 1, il primo router nel percorso risponde con il messaggio TTL scaduto. Quindi si misura il tempo impiegato per ricevere il messaggio TTL scaduto rispetto all'invio dei messaggi iniziali e ciò fornisce i primi tre valori nell'output di Traceroute.

Quindi si invia un altro set di tre pacchetti con un TTL di 2. Il primo router nel percorso lo decrementa a 1, quindi lo inoltra al router successivo nel percorso. Alla ricezione, quando viene ricevuto dal secondo router, il TTL viene ridotto a 0, il che lo richiede di rilasciare il pacchetto e inviare il TTL scaduto in transito.

Il processo continua fino a quando il tuo client non ha ricevuto un messaggio (bene, tre) TTL scaduto da ogni router in transito tra te e la destinazione finale su cui stai eseguendo il traceroute.


meglio spiegato visivamente
ksp0422

@Eddie, Questo potrebbe non essere rilevante per questa domanda, ma si tratta di pochissimi dettagli che ho pensato di chiedere in commento. Puoi specificare cosa succede se l'host (non il router) riceve un datagramma con il campo TTL 1?
Vimal Patel,

1
@VimalPatel Se il pacchetto era destinato all'host, l'host accetta semplicemente il pacchetto. Il rilascio di pacchetti se il TTL raggiunge 0 è una funzione del router.
Eddie,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.