Wenn Sie jemals im Netzwerkbereich oder im Supportbereich gearbeitet haben, haben Sie wahrscheinlich gute Geschichten über die Fehlerbehebung bei einer unterbrochenen Verbindung. Unweigerlich wird ein neues System installiert und konfiguriert, aber wir können keinen Datenverkehr zum oder vom System leiten.
Eine solche Geschichte, an die ich mich erinnern kann, geht ungefähr so.
Der Anwendungsfall
Ich war mit der Fehlerbehebung bei einem Back-End-Speicher-Array beschäftigt, das gerade von einem großen, bekannten amerikanischen Finanzunternehmen installiert worden war. Der Kunde versuchte, die Datenreplikation von seinem Produktionsstandort (PROD) in Houston zu einem Disaster-Recovery-Standort (DR) in San Antonio zu konfigurieren. Das Disaster-Recovery-System war schon lange implementiert und hatte den Ruf, eine bekannte gute Konfiguration zu sein.
Die Produktionsstätte war brandneu und natürlich die Ursache all unserer Probleme. Das eigentliche Problem war, dass wir keinen Datenverkehr zwischen den beiden von uns konfigurierten Replikationsschnittstellen bewegen konnten. Wir konnten außerhalb des Gateways auf der DR-Site erreichen, aber wir konnten außerhalb der PROD-Site nicht erreichen. Datenverkehr traf auf das Gateway-Gerät und wurde verworfen.
Innerhalb einer halben Stunde nach der Fehlerbehebung fragte ich den Kunden, ob er eine Firewall auf der PROD-Site habe, die den Datenverkehr an den benötigten Ports blockieren könnte. "Natürlich nicht, es gibt keine Firewall zwischen diesen Standorten." Diese Antwort war schockierend, wenn man bedenkt, dass dies eines der größten Finanzinstitute im ganzen Land war. Aber wie bei allen Positionen mit Kundenkontakt müssen Sie respektvoll und höflich sein.
Also ging ich von meiner Seite jeden Check durch, der mir einfiel. Firewall des internen Speichers deaktiviert:überprüfen. Offene Ports von DR zu PROD:prüfen. Offene Ports von PROD zu DR? Nein.
Es stellte sich heraus, dass der Kunde nach vier Stunden Fehlerbehebung und Neukonfiguration der Schnittstellen sagte:„Lassen Sie mich unseren Firewall-Typen anrufen.“
Welcher Typ bist du?
Das ist eine seltsame Einstellung, wenn man bedenkt, dass Sie keine Firewall zwischen diesen Sites haben. Aber es war nicht seltsam, denn natürlich hatten sie eine Firewall. Problem gelöst. Jetzt, da der Albtraum vorbei war, waren die Tools, mit denen ich herausfand, wo das Problem auftrat, das gute altmodische Telnet (das wir in einem späteren Artikel behandeln werden) und natürlich traceroute .
Der Befehl
Jetzt, da Sie einen klaren Anwendungsfall für traceroute sehen können , lassen Sie uns über den Befehl selbst sprechen und welche Informationen Sie daraus erhalten können. Der Zweck dieses Artikels ist schließlich, dass Sie etwas mehr über das Dienstprogramm traceroute wissen Angebote.
Die Syntax ist ziemlich einfach. Der Befehl traceroute <x> (x hier ist es eine IP oder ein Hostname) ist die einfachste Version und beginnt, Pakete an das angegebene Ziel zu senden. Dieses Ergebnis ermöglicht es Ihnen, den Pfad der Pakete zu verfolgen, die von Ihrem Computer zu jedem der Systeme zwischen Ihnen und Ihrem gewünschten Ziel gesendet werden.
Zum Beispiel, wenn ich den Pfad von meinem Computer zu google.com verfolgen möchte , würde ich so etwas eingeben:
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 119.355 ms 119.315 ms 119.508 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 120.321 ms 119.836 ms 120.009 ms
5 66.sub-69-83-106.myvzw.com (69.83.106.66) 119.042 ms 119.489 ms 119.156 ms
6 2.sub-69-83-107.myvzw.com (69.83.107.2) 120.039 ms 125.954 ms 101.450 ms
7 112.sub-69-83-96.myvzw.com (69.83.96.112) 110.757 ms 108.485 ms 122.108 ms
8 112.sub-69-83-96.myvzw.com (69.83.96.112) 115.028 ms 121.073 ms 125.537 ms
9 116.sub-69-83-96.myvzw.com (69.83.96.116) 121.793 ms 124.769 ms 124.434 ms
10 Bundle-Ether10.GW6.DFW13.ALTER.NET (140.222.237.123) 128.082 ms 128.400 ms 126.509 ms
11 google-gw.customer.alter.net (204.148.43.118) 106.276 ms 107.885 ms 105.718 ms
12 108.170.252.129 (108.170.252.129) 99.725 ms 101.797 ms 108.170.252.161 (108.170.252.161) 101.671 ms
13 108.170.230.109 (108.170.230.109) 101.207 ms 100.515 ms 99.730 ms
14 dfw06s48-in-f100.1e100.net (216.58.194.100) 99.059 ms 94.502 ms 94.015 ms
[root@rhel8dev ~]# Die Aufschlüsselung
Lassen Sie uns diese Ergebnisse in kleinere Häppchen aufteilen. Dieser Befehl kann eine Menge Informationen liefern, und wie das Sprichwort sagt:"Der beste Weg, einen Elefanten zu essen, ist ein Bissen nach dem anderen:"
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms Wir betrachten hier nur den ersten Hop. Wir können diesen Hop jedoch verwenden, um die angezeigten Informationen zu analysieren. Zuerst sehen wir, was tatsächlich gesendet wird und wohin:
traceroute to www.google.com(IP), 30 hops max, 60 byte packets
Aus dieser Ausgabe entnehmen wir, dass wir Traffic an das gewünschte Ziel senden (www.google.com ). Traceroute misst standardmäßig 30 Hops von 60-Byte-Paketen.
Als Nächstes sehen wir, wie der erste Hop auftritt. Hier treffen wir auf das externe Gateway:
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
Hier können Sie erkennen, wo Hop One tatsächlich gelandet ist, und dann gibt es drei Zahlenwerte. Diese sind als Round-Trip Time (RTT) bekannt und beziehen sich auf die Zeit, die ein bestimmtes Paket benötigt, um sein Ziel zu erreichen und eine ICMP-Nachricht an die Quelle zurückzuleiten. Standardmäßig traceroute leitet drei Datenpakete, um jeden Hop zu testen. Weitere Informationen zu diesem Vorgang finden Sie online, aber kurz gesagt, jedes Paket leitet eine ICMP-Fehlermeldung zurück an die Quelle, wenn es ein Gerät im Netzwerk erreicht. Diese Aktion ermöglicht traceroute um die RTT dieses Pakets zu bestimmen und weist nicht unbedingt auf einen Fehler hin.
Sehen wir uns nun die Sprünge 2 bis 4 an:
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 109.206 ms 109.400 ms 109.423 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 124.793 ms 123.585 ms 124.585 ms Wir können hier etwas Neues sehen. Hop 2 sieht normal aus:Ein Gerät wird mit RTT-Zeiten im Bereich von 100 Millisekunden getroffen. Dann wird es interessant. Wir sehen nur Sterne (*).
Was bedeuten diese Sterne (Sternchen)? Wurden die Pakete verworfen? Sind sie abgelaufen?
Lassen Sie mich erklären. Bei diesen Sternen gibt es zwei Möglichkeiten. Erstens ist ICMP/UDP möglicherweise nicht konfiguriert. Wenn die traceroute Befehl erfolgreich abgeschlossen wird und Sie diese Sterne sehen, war das betroffene Gerät höchstwahrscheinlich nicht so konfiguriert, dass es auf ICMP/UDP-Datenverkehr antwortet. Dieses Ergebnis bedeutet nicht, dass der Datenverkehr nicht bestanden wurde. Die zweite Möglichkeit ist, dass die Pakete aufgrund eines Problems im Netzwerk verworfen wurden. Diese Ergebnisse sind normalerweise Paketzeitüberschreitungen oder der Datenverkehr wurde von einer Firewall blockiert.
Wie Sie im obigen Beispiel sehen können, werden die Pakete auch dann fortgesetzt, wenn wir Sterne bei Hop 2 sehen, und in Hop 4 zurückgeleitet. Dieses Verhalten führt zu einem erfolgreichen traceroute wie wir sehen können, dass Google erreicht wurde.
Der Imbiss
Traceroute kann ein unschätzbares Werkzeug sein, wenn es um die Behebung von Netzwerkproblemen geht. Es hilft wirklich zu visualisieren, wo das Problem tatsächlich auftritt. Natürlich laufen hinter den Kulissen von traceroute noch andere Operationen die hier nicht behandelt wurden.
Wenn Sie sich dieses Tool noch genauer ansehen möchten, empfehle ich Ihnen dringend, online zu recherchieren. Es gibt viele Informationen zu Time-to-Live (TTL) und RTT, die aus Zeitgründen nicht in diesen Artikel aufgenommen wurden. Mein Ziel ist, dass Sie jetzt besser verstehen, wann und warum Sie traceroute verwenden sollten Tool und wie die angebotenen Daten zu interpretieren sind. Weitere Informationen zur Netzwerkfehlerbehebung und -konzepten finden Sie in unseren verwandten Artikeln hier.