Zum Hauptinhalt springen
Download

Traceroute auf Mac, iPhone und iPad: finden, wo die Route bricht

Ein echtes ICMP-Traceroute auf Mac, iPhone und iPad, Sprung für Sprung gestreamt, und der Teil, den niemand erklärt: wie man liest, was zurückkommt.

Von Lucas Russo, Entwickler von SSHive · Aktualisiert am

SSHive kostenlos ladenAlle Netzwerk-Tools
Auch auf iPhone und iPad

Die App für iPhone und iPad gibt es auf Englisch, Französisch und Spanisch, nicht auf Deutsch; die Sprache stellen Sie in den Einstellungen der App ein. Die Mac-App ist auf Deutsch.

Ein Dienst ist langsam oder nicht erreichbar, und auf Ihrer Seite erklärt das nichts. Das DNS löst auf, der Server antwortet lokal, Ihre Leitung ist sauber. Was Sie nicht sehen können, sind die fünfzehn oder zwanzig Router zwischen Ihrer Maschine und diesem Host, und dort liegt die Antwort meistens. Traceroute ist das Werkzeug, das diese Router sichtbar macht. Es misst nicht Ihre Verbindung zu einem Server; es rekonstruiert die Folge der Hops, die Ihre Pakete zu ihm nehmen, und wie lange jeder für eine Antwort braucht. Richtig gelesen, sagt es Ihnen, ob ein Problem Ihres ist, das Ihres Providers, das eines Transitanbieters oder das der Gegenstelle: der Unterschied zwischen etwas reparieren und beim Richtigen ein Ticket aufmachen. Nachlässig gelesen, erzeugt es mehr Fehlschlüsse als jedes andere Netzwerkwerkzeug. Ein Hop voller Sternchen sieht aus wie ein toter Router und ist es fast nie. Ein 300-ms-Ausschlag mitten im Pfad wirkt alarmierend, obwohl dort meist nur ein Router Ihre Sonde nachrangig behandelt, während er den Produktivverkehr ohne Stocken weiterleitet. Einen Traceroute zu lesen heißt vor allem zu wissen, welche Zeilen Messungen sind und welche Rauschen. SSHive misst auf jeder Apple-Plattform, für die es ausgeliefert wird, einen echten Traceroute: Mac-App-Store-Version, iPhone und iPad. Es sendet eigene ICMP-Sonden, einen TTL-Wert nach dem anderen, drei Sonden je Hop, bis zu dreißig Hops, und gibt Adresse und Zeiten jedes Routers aus, sobald sie eintreffen. Nichts wird umformatiert und nichts erfunden. Das gehört klar gesagt, denn eine frühere Fassung dieser Seite behauptete das Gegenteil. Sie hielt fest, eine App-Store-App in der Sandbox könne keinen Traceroute, weil sie dafür rohe ICMP-Sockets bräuchte. Das wurde nie gemessen, und es ist falsch: IP_TTL zu setzen und die Time-Exceeded-Antworten zu lesen funktioniert von einem gewöhnlichen Datagramm-ICMP-Socket aus, der keine Root-Rechte braucht und den die App Sandbox erlaubt. Alles Weitere erklärt den Mechanismus und wie man die Ausgabe liest.

Was SSHive dabei leistet

Eigene Sonden statt des System-Binaries

SSHive baut die Sonden selbst, statt ein Systembinary aufzurufen, deshalb läuft dieselbe Engine in der Mac-App-Store-Version, auf dem iPhone und auf dem iPad. Ein TTL-Wert je Hop, drei Sonden pro Hop, bis zu dreißig Hops, mit der Adresse des Routers und seinen drei Laufzeiten in jeder Zeile. Nichts wird synthetisiert und kein Drittdienst sitzt dazwischen: Die Pakete verlassen Ihr Gerät und die Antworten kommen dorthin zurück.

Live-Ausgabe, Hop für Hop

Hops erscheinen, sobald sie antworten, Zeile für Zeile in einem dicktengleichen Bereich, der von selbst scrollt. Ein Abzeichen „Läuft…“ zeigt, dass die Trace noch unterwegs ist, und Stopp bricht sie sofort ab: praktisch, wenn ein Pfad an einem gefilterten Hop hängen bleibt und Sie Ihre Antwort schon bei Hop 6 hatten. Sie müssen nie einen vollen 30-Hop-Lauf absitzen.

Dieselbe Trace auf iPhone und iPad

Die iOS- und iPadOS-Apps führen dieselbe ICMP-Engine aus wie der Mac, mit derselben Obergrenze von dreißig Hops und denselben drei Sonden je Hop, eine auf dem Telefon gestartete Trace ist also direkt mit einer auf dem Mac gestarteten vergleichbar. Das ist wichtiger, als es klingt: Denselben Host einmal aus dem Mobilfunknetz und einmal aus dem Büro-WLAN zu tracen, ist oft das, was zeigt, wessen Netz schuld ist.

Deaktiviert, wo es nicht geht, nie vorgetäuscht

Wenn das System ICMP rundheraus verweigert (manche Unternehmensnetze und ein paar VPN-Konfigurationen tun das), hält SSHive an und sagt es, statt eine plausibel aussehende Hop-Liste auszugeben. Eine Verweigerung wird als Verweigerung gemeldet. Dasselbe gilt für einen Hop, der nie antwortet: Er erscheint als Sternchen, was ein echtes und häufiges Ergebnis ist, kein Fehler.

Tracen, dann verbinden

Ein Traceroute endet meist mit einer Frage: Was ist dieser letzte antwortende Router, und komme ich auf die Maschine dahinter? SSHive ist zuerst ein SSH-, SFTP-, RDP- und VNC-Client, die Antwort ist also einen Tab entfernt. Bestimmen Sie den letzten guten Hop, öffnen Sie eine Sitzung zum Jump-Host oder zum Server und arbeiten Sie im selben Fenster weiter.

Kostenlos, ohne Konto

Die gesamte Netzwerkwerkzeug-Suite (Traceroute, Ping, DNS-Abfrage, Whois, MX-Abfrage und DNSBL-Prüfungen) gehört auf jeder Plattform, auf der sie verfügbar ist, zur kostenlosen Stufe. Keine Funktionssperre bei irgendeinem davon, keine Werbung, keine Anmeldung. SSHive Pro ist ein Einmalkauf, als Universal Purchase für Mac, iPhone und iPad, und schaltet Sitzungsfunktionen frei, nicht die Diagnose.

So gehen Sie vor, Schritt für Schritt

  1. 1

    Die Netzwerkwerkzeuge öffnen

    Klicken Sie auf dem Mac auf das Netzwerksymbol in der Seitenleiste oder auf die Schaltfläche Netzwerkwerkzeuge im Willkommensbildschirm. Beides öffnet einen eigenen Werkzeug-Tab neben Ihren Sitzungen, sodass Sie eine Route verfolgen können, ohne zu schließen, woran Sie gerade arbeiten. Auf iPhone und iPad liegen dieselben Werkzeuge im Tab Tools, so heißt er in der englischen Oberfläche der App.

  2. 2

    Die Traceroute-Karte finden

    Das Werkzeug-Panel gruppiert seine Karten in drei Abschnitte, und innerhalb eines Abschnitts lassen sich Karten verschieben oder ausblenden, sodass nur die Werkzeuge übrig bleiben, die Sie wirklich nutzen. Traceroute ist die letzte Karte im Abschnitt Erreichbarkeit, nach Ping und Port-Test.

  3. 3

    Ein Ziel eingeben und die Trace starten

    Tippen Sie einen Hostnamen oder eine IP-Adresse in das Feld (der Platzhaltertext zeigt z. B. google.com) und drücken Sie auf Trace. SSHive löst ihn auf, beginnt dann mit einem TTL von 1 zu sondieren und arbeitet sich Hop für Hop nach außen vor, bis zu 30.

  4. 4

    Die Hops eintreffen sehen

    Zeilen laufen ein, sobald der jeweilige Router antwortet, mit einem Abzeichen „Läuft…“, solange die Trace aktiv ist. Ein Hop mit Sternchen antwortet schlicht nicht innerhalb der Wartezeit, und die Trace geht zum nächsten TTL weiter. Drücken Sie auf Stopp, sobald Sie gesehen haben, was Sie brauchten.

  5. 5

    Beim letzten antwortenden Hop ansetzen

    Merken Sie sich den letzten Hop, der geantwortet hat, und ob das Ziel überhaupt geantwortet hat. Von dort aus öffnen Sie im selben Fenster eine SSH-, RDP- oder VNC-Sitzung zum betreffenden Host, oder Sie gleichen das Ziel mit den Karten Ping und DNS-Lookup darüber ab.

Einen Traceroute lesen, ohne den falschen Schluss zu ziehen

Jede Zeile ist ein TTL-Wert, keine Messung Ihrer Verbindung. Pro Hop gehen drei Sonden hinaus, Sie bekommen also drei Laufzeiten, und die Streuung zählt ebenso viel wie die Werte: 10 / 11 / 10 ms ist ein stabiler Router, 10 / 400 / 11 ms ist eine Sonde, die hinter etwas anderem in der Warteschlange lag, und verdient selten eine Untersuchung. Jeder RTT enthält einen Rückweg, den Sie nie sehen. Die Antwort von Hop 8 kommt über die Route zurück, die dieser Router zu Ihnen hat, und die ist oft nicht die Umkehrung des Hinwegs. Deshalb kann Hop 8 mit 90 ms erscheinen, während Hop 9 bei 40 ms liegt. Das ist kein Fehler und die Latenz ist nicht gesunken: Die Antwort von Hop 8 hat nur einen langsameren Heimweg genommen. Ziehen Sie nie zwei benachbarte Hops voneinander ab und nennen Sie das Ergebnis die Latenz dieser Strecke. Sternchen sind die am häufigsten falsch gelesene Ausgabe im Netzwerkbereich. Drei davon heißen, dass vor Ablauf der Wartezeit kein ICMP Time Exceeded zurückkam (unter macOS standardmäßig fünf Sekunden). Dafür gibt es drei gewöhnliche Gründe: Der Router erzeugt überhaupt keine ICMP-Fehler, was in Provider- und MPLS-Kernen normal ist; er begrenzt die Rate der ICMP-Fehlererzeugung und verwirft deshalb die Antwort auf Ihre Sonde, während er den Produktivverkehr einwandfrei weiterleitet; oder eine Firewall blockiert die ausgehende Sonde (macOS nutzt UDP ab Port 33434 aufwärts) oder das zurückkommende ICMP. In allen drei Fällen ist die Datenebene gesund. Der Test ist einfach: Wenn irgendein Hop nach den Sternchen antwortet, hat der stumme Hop Ihr Paket korrekt weitergeleitet. Nur Sternchen, die ununterbrochen bis zum Ende der Trace laufen, sagen überhaupt etwas aus. Dieselbe Disziplin gilt für Ausschläge. Ein Hop mit 300 ms zwischen Nachbarn mit 40 ms ist ein Artefakt der Control Plane: Dieser Router hat Ihre Sonde nachrangig behandelt. Es zählt, ob sich ein Anstieg über alle späteren Hops und bis ins Ziel fortsetzt. Eine Stufe, die bis zum Ende durchträgt, ist echt, kann aber Geografie statt Fehler sein: Eine Transatlantikstrecke kostet ihre 70 bis 90 ms, und daran ändert sich nichts. Wo eine Route wirklich bricht, ist der letzte Hop, der geantwortet hat: der letzte Router mit einer Route zu Ihrem Ziel und einer Route zurück zu Ihnen. Wenn danach nichts mehr antwortet und auch das Ziel nie, sitzt der Fehler an dieser Stelle oder kurz dahinter. Ein sich wiederholendes Muster derselben Hops ist eine Routing-Schleife. Und !H, !N, !P oder !X sind eindeutig, wo Sternchen es nicht sind: ein Router, der ausdrücklich Host, Netz oder Protokoll als nicht erreichbar meldet, oder den Pfad als administrativ gefiltert.

Häufige Fragen

Funktioniert Traceroute wirklich in der Mac-App-Store-Version mit Sandbox?+
Ja, und ohne jede Einschränkung. Die verbreitete Überzeugung, es gehe nicht, beruht auf einer Verwechslung zweier Socket-Arten. Ein Traceroute muss IP_TTL auf ausgehenden Sonden setzen und die ICMP-Time-Exceeded-Antworten der Router lesen. Ein Raw-Socket würde von der App Sandbox tatsächlich verweigert, aber ein Datagramm-ICMP-Socket kann beides, braucht keine Root-Rechte und ist erlaubt. Gemessen unter sandbox-exec mit den eigenen Entitlements der App: setsockopt(IP_TTL) gelingt, und die Hops kommen zurück, Router für Router. Ein Vorbehalt, auf die harte Tour gefunden: com.apple.security.network.client allein reicht nicht, denn die Antworten werden dann mit EPERM abgewiesen; network.server wird ebenfalls gebraucht, und SSHive deklariert beide.
Kann ich von einem iPhone oder iPad aus einen Traceroute laufen lassen?+
Ja, und es ist eine echte Messung, keine Illustration. iOS erlaubt kein Starten von Unterprozessen und hat keine setuid-Binaries, eine App kann also nicht einfach den System-Traceroute aufrufen, weshalb das oft für unmöglich gehalten wird. Die Einschränkung betrifft aber nur Network.framework, Apples High-Level-API, die kein ICMP-Transport hat. Darunter ist die BSD-Socket-Schicht intakt: SSHive öffnet socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP), setzt IP_TTL auf jeder Sonde und liest die Time-Exceeded-Antworten, genau wie auf dem Mac. Dreißig Hops, drei Sonden je Hop. Denselben Host einmal über Mobilfunk und einmal über WLAN zu tracen, ist oft der schnellste Weg, festzustellen, wessen Netz schuld ist.
Was bedeuten drei Sternchen in einem Traceroute?+
Dass keine der drei Sonden für dieses TTL vor Ablauf der Wartezeit ein ICMP Time Exceeded zurückbekommen hat. Meist heißt das, dass der Router so konfiguriert ist, keine ICMP-Fehler zu senden, dass er deren Rate begrenzt, oder dass eine Firewall die Sonde oder die Antwort verworfen hat. Selten heißt es, dass der Router defekt ist. Wenn irgendein späterer Hop antwortet, hat dieser stumme Router Ihr Paket einwandfrei weitergeleitet. Nur Sternchen, die ununterbrochen bis zum Ende der Trace laufen, sind ein echtes Signal.
Warum zeigt ein mittlerer Hop 300 ms, wenn das Ziel 40 ms zeigt?+
Weil es nicht die Aufgabe dieses Routers ist, Ihre Sonde zu beantworten. Ein ICMP Time Exceeded zu erzeugen ist Arbeit der Control Plane, erledigt von einer CPU, die ihr absichtlich niedrige Priorität gibt, während der weitergeleitete Verkehr auf dem schnellen Pfad bleibt. Ein Ausschlag, der sich nicht auf die folgenden Hops fortsetzt, ist ein Artefakt, kein Fehler. Nur ein Anstieg, der über alle weiteren Hops und bis ins Ziel bestehen bleibt, gibt wieder, was der Verkehr tatsächlich erlebt.
Die Trace hört bei Hop 12 auf und erreicht den Host nie. Ist das Netz ausgefallen?+
Nicht zwangsläufig. Viele Ziele hinter Load-Balancern, Anycast-Frontends oder Cloud-Firewalls verwerfen Traceroute-Sonden stillschweigend und bedienen TCP-Verkehr dabei normal; eine Trace, die kurz vor dem Ende ausläuft, während der Dienst funktioniert, ist zu erwarten. Bestätigen Sie es mit einem Verbindungstest auf den echten Port (genau das leistet die TCP-Engine von Ping), bevor Sie etwas schließen. Ist der Dienst wirklich nicht erreichbar, ist Hop 12 Ihr Beleg: Er ist der letzte Router mit einer Route zu Ihrem Ziel und einer Route zurück zu Ihnen, der Bruch sitzt also dort oder unmittelbar dahinter.
Kann ich die Hop-Grenze ändern oder mit UDP statt ICMP sondieren?+
Nicht von der SSHive-Karte aus. Die Trace läuft mit einer festen Obergrenze von 30 Hops, mit ICMP-Sonden und drei Sonden je Hop, ohne Optionen für Protokoll, Port oder Sondenzahl und ohne ASN- oder Geolokalisierungs-Anreicherung. Wenn Sie diese Schalter auf einem Mac brauchen, nimmt /usr/sbin/traceroute sie im Terminal direkt entgegen; die Karte ist für den häufigen Fall da, einen Host schnell zu tracen, ohne Ihre Sitzungen zu verlassen, und für iPhone und iPad, wo es kein Terminal gibt, auf das man ausweichen könnte.
Gehört Traceroute zu SSHive Pro?+
Nein. Traceroute und der Rest der Netzwerkwerkzeug-Suite sind auf jeder Plattform kostenlos, ohne Funktionssperre, ohne Werbung und ohne anzulegendes Konto. SSHive Pro ist ein Einmalkauf, als Universal Purchase für Mac, iPhone und iPad, ohne Abo; er schaltet Fähigkeiten auf der Sitzungsseite frei, nicht die Diagnose.

TTL, ICMP-Fehler, und wie eine App in der Sandbox das trotzdem schafft

Ein IPv4-Header trägt ein 8-Bit-TTL-Feld (in IPv6 heißt es Hop Limit), dessen einziger Zweck darin besteht, Pakete am ewigen Kreisen zu hindern. Jeder Router, der ein Paket weiterleitet, zieht eins ab; erreicht es null, verwirft der Router das Paket und schickt eine ICMP-Time-Exceeded-Nachricht zurück, Typ 11 Code 0, abgesendet von der Schnittstelle, auf der das Paket eintraf. Traceroute macht aus diesem Fehlermodus eine Messung. Es sendet eine Sonde mit TTL 1, die am ersten Router stirbt und einen Fehler auslöst, der ihn benennt. Dann TTL 2, dann TTL 3, und arbeitet sich Hop für Hop nach außen vor. Drei Sonden je TTL ergeben die drei Zeiten in jeder Zeile. Wie das Ziel erkannt wird, hängt vom Sondentyp ab: Der BSD-Traceroute unter macOS sendet UDP-Datagramme an unwahrscheinliche hohe Ports ab 33434 und wertet ein ICMP Port Unreachable (Typ 3, Code 3) als Ankunftssignal, während das Windows-tracert ICMP Echo Requests sendet und bei einer Echo Reply aufhört. Dieser Unterschied ist nicht kosmetisch. Firewalls behandeln UDP-Sonden und ICMP Echo sehr verschieden, dasselbe Ziel erzeugt von einem Mac und von einer Windows-Maschine aus also berechtigterweise unterschiedliche Sternchen-Hops; prüfen Sie beides, bevor Sie einen Router beschuldigen. Womit wir bei der Frage sind, die alle falsch beantworten, eine frühere Fassung dieser Seite eingeschlossen: Kann eine App in der Sandbox das überhaupt? Die Argumentation, die Nein sagt, geht so. /usr/sbin/traceroute wird unter macOS setuid root installiert, /sbin/ping nicht, also muss Traceroute Privilegien brauchen, die Ping nicht braucht; die App Sandbox gewährt solche Privilegien nicht; also kein Traceroute in einer App-Store-App. Jeder Schritt klingt vernünftig, und die Schlussfolgerung ist trotzdem falsch, denn die Prämisse verwechselt den vom BSD-Traceroute gewählten Sondentyp mit Traceroute als Technik. Dieses Binary sondiert mit UDP-Datagrammen und braucht einen Raw-Socket, um die dadurch ausgelösten ICMP-Fehler zu lesen, daher das setuid. Sondieren Sie stattdessen mit ICMP Echo, und die Antworten treffen auf demselben Datagramm-ICMP-Socket ein, den Ping schon ohne Privilegien nutzt. setsockopt(IP_TTL) ist kein privilegierter Aufruf. SSHive steuert also überhaupt kein Systembinary. Es öffnet socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP), setzt die TTL, sendet drei Echo Requests je Hop und liest, was zurückkommt: ein Time Exceeded, das einen Router benennt, eine Echo Reply, die heißt, dass das Ziel geantwortet hat, oder innerhalb von zwei Sekunden nichts, was als Sternchen erscheint. Das wurde unter sandbox-exec mit den echten Entitlements der App gemessen, bevor irgendetwas davon ausgeliefert wurde, und es zeigte eine Falle, die eine Wiederholung wert ist: Mit com.apple.security.network.client allein geht die Sonde hinaus und die Antwort wird mit EPERM abgewiesen, ein stiller Fehlschlag, der genau wie ein filterndes Netz aussieht. com.apple.security.network.server wird ebenfalls gebraucht. SSHive deklariert beide, weshalb die App-Store-Version in der Sandbox überhaupt eine echte Trace liefert statt einer Spalte voller Sternchen. iOS kommt über denselben Weg an denselben Punkt. Network.framework stellt TCP, UDP, QUIC und TLS bereit und überhaupt kein ICMP, aber es ist nicht die einzige verfügbare API: Die BSD-Socket-Schicht darunter nimmt denselben Datagramm-ICMP-Socket an, und Apples eigenes SimplePing-Beispiel führt das seit Jahren vor. Die iPhone- und iPad-Versionen führen dieselbe Schleife über dreißig Hops und drei Sonden aus wie der Mac. Kennen Sie die Grenzen, bevor Sie sich darauf stützen. Die Hop-Obergrenze liegt fest bei 30, es gibt keine Schalter für Protokoll, Port oder Sondenzahl, und keine ASN- oder Geolokalisierungs-Anreicherung. Weil die Sonden ICMP Echo statt UDP sind, kann eine Firewall, die das eine erlaubt und das andere verwirft, ein anderes Sternchenmuster erzeugen als /usr/sbin/traceroute; keines der beiden Ergebnisse ist falsch, und die beiden zu vergleichen ist gelegentlich genau die Art, wie man die Firewall findet.

Verwandte Tools

Ping

DNS-Abfrage

Whois