Traceroute - jedes Paket hat TTL == 1

Ich arbeite an Wireshark lab-IP in Computernetzwerken - Ein Top-Down-Ansatz und ich verstehe nicht, warum jedes Paket, das normalerweise abgelaufen ist, eine TTL von 1 hat.

Hier ist meine Wireshark-Erfassungsdatei. https://www.dropbox.com/s/rr5wgze9j20gzvu/traceroute-56.pcapng?dl=0

Ich habe die Ausführung des tracerouteProgramms unter Linux (mit der Option von 56 Bytes) aufgezeichnet, wie mit dem folgenden Befehl ausgeführt:

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

Sie können sehen, dass der größte Teil der TTL des Pakets == 1 ist, und ich weiß nicht warum, da ich erfahren habe, dass jeder nachfolgende Hop eine TTL von +1 (oder mehr) hat.

PS:

• Ich verwende Lubuntu auf VMware mit überbrücktem Netzwerk zum Host.
• Ich habe es mit Wireshark auf einem Hostcomputer aufgenommen (Windows)
• Ich bin über einen eigenen DHCP-Server über das NAT-Protokoll mit einem WLAN-Zugriffspunkt verbunden

Lassen Sie mich versuchen , dies zu beantworten, da es etwas komplizierter ist, als es zunächst aussieht.

Es scheint, dass Sie die grundlegende Funktionsweise von bereits kennen, tracerouteaber vor allem anderen ist hier eine sehr kleine Zusammenfassung:

tracerouteversucht, alle Zwischenschritte von Ihrem Host zu einem Zielhost oder nur die Entfernung, dh die Anzahl der Hops, von Ihrem Host zu einem Zielhost zu bestimmen. Zu diesem Zweck beginnt das Senden von Paketen an den Zielhost mit einer "zufälligen" Zielportnummer und einer TTL, die bei 1 beginnt und stetig zunimmt.
Die Idee ist, dass jeder dazwischen liegende Router die TTL um 1 verringert. Wenn die TTL also 0 erreicht (in Wirklichkeit nie, da der Router, der sie auf 0 verringern will, zuvor einen Fehler erzeugt), gibt der Router einen ICMP zurück " Time-to-live überschritten " Fehlermeldung, zB Paketnummer 24 in der Capture - Datei. Daraus ergibt sich, dass Ihr Ziel weiter entfernt ist und Sie daher die TTL weiter erhöhen.
Wenn Ihr Paket eine TTL hat, die groß genug ist, um das Ziel zu erreichen, wird eine andere ICMP-Fehlermeldung angezeigt: " Ziel nicht erreichbar (Port nicht erreichbar) ", z. B. Paketnummer 208 in Ihrer Erfassungsdatei. Daraus ergibt sich, dass die zuletzt verwendete TTL tatsächlich die Anzahl der Sprünge zwischen Ihnen und dem Zielknoten ist. Der Grund, warum Sie eine Fehlermeldung erhalten, liegt einfach darin, dass Sie eine Nachricht an einen "zufälligen" Port senden, den der Zielknoten (hoffentlich) nicht abhört.

Gehen
traceroute wir nun zu den Details für Ihre Erfassungsdatei über: Auf der Handbuchseite von können wir sehen, dass jede TTL dreimal verwendet wird (Option '-q') und das verwendete Standardprotokoll UDP ist (Option '-P'). Wenn wir die ersten 3 UDP-Pakete untersuchen, dh die Pakete 8-9-10 , können wir in der Tat erkennen, dass die TTL 1 ist . Die nächsten 3, dh 11-12-13 , haben eine TTL 2 und so weiter. Aus der Quellensicht scheint also alles in Ordnung zu sein.

Nach einiger Zeit, abhängig von der Verzögerung des Netzwerks, erhalten wir die erwarteten Fehlermeldungen. Somit können wir sehen, dass die Pakete 24-25-26 Fehlerpakete mit der Angabe " Time to live excess " sind und somit bedeuten, dass das Ziel weiter entfernt ist.

Dieses Hin und Her von Versuchen und Fehlern wird fortgesetzt, bis schließlich Paket 208 angezeigt wird und die Fehlermeldung " Port nicht erreichbar " angezeigt wird, was bedeutet, dass Ihr Ziel erreicht wurde.

Durch Zählen der von Ihnen gesendeten Pakete und der Antworten können Sie sogar anhand der Ablaufverfolgung herausfinden, welche TTL tatsächlich funktioniert hat, aber es ist eine mühsame Aufgabe :)

Hoffe das hat geholfen

Ihr Client sendet nur die ersten drei Pakete mit einer TTL von 1. Die nächsten drei werden mit einer TTL von 2 gesendet. Die nächsten drei werden mit einer TTL von 3 gesendet. Und so weiter und so fort.

Eine einfachere Möglichkeit, dies anzuzeigen, besteht darin, das IP-TTL-Feld in Wireshark als eigene Spalte festzulegen. Klicken Sie einfach mit der rechten Maustaste auf den TTL-Wert in einem beliebigen Paket und wählen Sie "Als Spalte übernehmen":

Von dort aus können Sie sehen, dass die Pakete 8, 9, 10 eine TTL von 1 haben. Und die Pakete 11, 12, 13 haben eine TTL von 2. Und so weiter und so fort.

Dies geschieht, weil Traceroute auf diese Weise funktioniert. Es nutzt die Vorteile eines Routers aus, wenn eine TTL auf 0 verringert wird. Statt das Paket weiterzuleiten, sendet es eine "ICMP TTL Expired in Transit-Nachricht" an den ursprünglichen Client zurück (siehe Paket Nr. 24 in Ihrer Aufzeichnung) .

Wenn Sie als Client den ersten Satz von Paketen mit einer TTL von 1 senden, antwortet der erste Router im Pfad mit der TTL Expired-Nachricht. Anschließend messen Sie, wie lange es gedauert hat, bis die TTL Expired-Nachricht empfangen wurde, als Sie die ersten Nachrichten gesendet haben. Dadurch erhalten Sie Ihre ersten drei Werte in der Traceroute-Ausgabe.

Dann senden Sie einen weiteren Satz von drei Paketen mit einer TTL von 2. Der erste Router im Pfad dekrementiert diese auf 1 und leitet sie dann an den nächsten Router im Pfad weiter. Wenn dieser zweite Router ihn beim Empfang erhält, dekrementiert er die TTL auf 0, wodurch er aufgefordert wird, das Paket fallen zu lassen und Ihnen die TTL Expired während der Übertragung zu senden.

Der Prozess wird fortgesetzt, bis Ihr Client von jedem Router, der zwischen Ihnen und dem endgültigen Ziel, an dem Sie Ihre Traceroute ausführen, eine (nun drei) TTL Expired-Nachricht erhalten hat.