Sie sind Admin und Ihr Netz kränkelt. Wo fangen Sie an mit der Fehlersuche? Unser Tipp: Tasten Sie Ihre Netzwerkpatienten mal nach ICMP-Symptomen ab. Viele führen direkt zur Ursache.

Wenn man Netzwerkschluckauf behandeln muss, gilt Wireshark als eines der Lieblingswerkzeuge von Netzwerkadmins. Denn falsch angestöpselten oder fehlkonfigurierten Servern kommt man oft schon anhand eines Netzwerkmitschnitts auf die Spur und erspart sich so den Adminzugriff auf Abteilungsrouter oder -switches. Als behandelnder Admin müssen Sie das aufgefangene Paketkonfetti nur noch mit einem geeigneten Display-Filter sieben, um jene Paketsorte im Kescher zu behalten, die Fehlerhinweise gratis unter Ihre wissenden Augen bringt: die ICMP-Päckchen.

Wie Sie das machen, beschreiben wir ab dem Abschnitt „Sammelstellen“, an dem sich ein kleines Wireshark-Quiz anschließt. Wenn Sie mit Wireshark und ICMP-Fehlermeldungen per Du sind, lösen Sie das Quiz vermutlich mit einem Haifischgrinsen. Wenn nicht: Hier erfahren Sie, was hinter den Fehlermeldungen steckt und wie Sie das Know-how anwenden.

ICMP gehört im OSI-Schichtenmodell zu den Netzwerkprotokollen; es setzt auf Schicht 3 auf, dem Internet Protocol (IP). Oder anders ausgedrückt: Ein ICMP-Päckchen besteht der Reihe nach aus einem IP-Header, dem ICMP-Header und einem Datenabschnitt. Mittels ICMP-Päckchen melden IP-Netzwerkgeräte, die an einem Dialog beteiligt sind, einander ihren aktuellen Status oder senden Steuerinformationen, daher auch der Name Internet Control Message Protocol (ICMP). Die IPv6-Spezifikation steht im RFC 4443 und das Gegenstück für IPv4 im RFC 792.

Für Analysezwecke kann man ICMP-Päckchen auch mit Werkzeugen wie Ping übertragen. Damit ermittelt man unter Einsatz der Pakettypen Echo Request und Echo Reply beispielsweise die netzwerktechnische Entfernung (Round Trip Time, RTT) von Internet-Hosts wie Routern, Switches oder PCs. Die Funktionsweise haben wir hier beschrieben und die Ping-Analyse hier.

Weniger bekannt sind die ICMP-Pakete vom Typ „Destination Unreachable“, also „Ziel nicht erreichbar“. Und genau diese Pakete erleichtern in vielen Fällen das Troubleshooting, denn Zielgeräte wie Router, Switches oder PCs sollen im Fehlerfall den Absender über den netzwerktechnischen Fehlerzustand informieren, damit Admins eingreifen können.

Den Fehlern können verschiedene Ursachen zugrunde liegen, und wo es hakt, verrät beispielsweise ein Router mit einem Statuscode in seiner ICMP-Nachricht. Einige klassische Netzwerkfehler lassen sich so direkt aus den Meldungen der Sorte „Destination Unreachable“ auslesen – wenn doch nur der Admin die Nachrichten in die Hände bekäme. Doch das geht einfacher als gedacht: Man braucht gar kein klassisches und meist aufwendiges Troubleshooting. Es genügt ein Verkehrsmittschnitt mit Tools wie Wireshark oder beispielsweise mit dem Kommandozeilentool TCPDump.

Liegt Ihnen der Mitschnitt vor, können Sie Ihre Anwender über den Beginn der Fehlersuche informieren. Das stellt nebenbei den Flurfunk wieder leise und drosselt die erfolglosen Verbindungsversuche, die das Netzwerk nutzlos mit Beschlag belegen.

Nun folgen die vier häufigsten Fehler und deren Ursachen, aufgeschlüsselt nach Client- und Serverseite. Von einem clientseitigen Fehler ist die Rede, wenn dieser beispielsweise eine TCP-Verbindung aufbauen möchte – dafür schickt er ein SYN-Paket zum Ziel – der Aufbau aber scheitert und deshalb eine Fehlermeldung zurückkommt. Ein serverseitiger Fehler liegt vor, wenn der Server eine Antwort auf eine Clientanfrage sendet, diese aber nicht ankommt.

Der Vollständigkeit halber sei erwähnt, dass es noch eine Reihe weiterer Fehlercodes gibt, die jedoch selten vorkommen. Eine Liste aller Fehlermeldungen inklusive Verlinkungen zu den jeweiligen RFC-Spezifikationen pflegt die IANA.

No route to destination

Fall 1: Ein Router auf der Strecke zum Ziel verwirft ein IP-Paket, weil in seiner Routingtabelle der Eintrag für das Zielnetz fehlt. Er kann also das Paket nicht weiterreichen und meldet dem Absender, etwa einem PC, „no route to destination“. Das kann nur bei Internet-Routern passieren, die anstatt der Default Route die Default-Free Zone haben.

Aber wieso sollte ein Gerät ein IP-Paket überhaupt an eine nicht erreichbare Adresse schicken? Eine einfache Erklärung ist: Der Nutzer des Clients hat die IP-Adresse falsch eingetippt und so einen Bereich erwischt, den es im Internet nicht gibt. Oder der Nutzer wollte auf einen Hostnamen zugreifen, bei dem der DNS-Admin dicke Finger hatte, weshalb der A- oder AAAA-Record auf dem autoritativen DNS-Server eine fehlerhafte IP-Adresse enthält.

Seltener kommt es vor, dass die Zielnetzangabe gültig, aber das Ziel temporär nicht erreichbar ist. Ursachen können sein, dass das Ziel-IP-Netzwerk oder dessen Router technische Probleme haben, welche BGP-Routingupdates im Internet verhindern. In solchen Fällen fliegt das Zielnetz einfach aus den weltweiten Routingtabellen raus. Einem Router, der ein Paket für ein solches Ziel bekommt, bleibt nichts anderes übrig, als es zu verwerfen und dem Absender des Pakets per ICMP-Nachricht mitzuteilen, dass sein Weiterleitungsversuch gescheitert ist.

Ein Sonderfall kommt bei Antwortpaketen vor, die Server zum Client senden: Steht in den IP-Paketen des Clients eine falsche Quelladresse (ob absichtlich oder unabsichtlich), gilt das als Netzwerkangriff vom Typ „Source Address Spoofing“. Die Anfrage an den Server erreicht diesen zwar, die Antwort versiegt aber im Netz. Ein Angreifer hat sein Ziel womöglich dennoch erreicht: Last auf dem Server erzeugen, beispielsweise als Teil einer DDoS-Attacke (Distributed Denial of Service).

Communication with destination administratively prohibited

Fall 2: Im Englischen etwas umständlich formuliert handelt es sich bei der Nachricht „communication with destination administratively prohibited“ um eine klassische Firewall-Blockade. Versucht ein Client auf eine Ressource zuzugreifen, die der Firewall-Admin gesperrt hat, verwirft die Firewall das Paket und antwortet eventuell so.

Eventuell, weil eine moderne Firewall standardmäßig nicht mitteilt, dass sie gerade ein Paket verworfen hat. Ist sie nämlich als Perimeter-Firewall in Betrieb, soll sie sich möglichst unauffällig und transparent verhalten. Nur als interne Segmentierungs-Firewall soll sie über Sperren informieren, und zwar hausinterne Anwender. Würde die Firewall das Paket stillschweigend verwerfen, müssten Anwender das Timeout abwarten, mitunter viele lästige Sekunden lang. Einem Angreifer will man aber mit der Fehlermeldung nicht kundtun, dass sein Paket doch irgendwo aufgeschlagen ist und sich weiteres Stochern lohnen könnte.

Nützlich zu wissen ist auch, dass nur UDP-Päckchen diesen Fehlercode auslösen können. Bei Sperrungen von TCP-basierten Diensten sendet eine Firewall nämlich ein TCP-Reset-Päckchen an den Absender. Da UDP als verbindungsloses Protokoll keine Quittungen wie ACK oder RST sendet, hilft ICMP aus.

Serverseitig sollte dieser Fehler fast nie auftauchen. Liegen eine oder mehrere Firewalls zwischen Client und Server, haben diese die Verbindung in der Regel bereits zugelassen. Ebenso lassen alle Firewalls der letzten Jahrzehnte Antwortpakete durch – sie arbeiten „stateful“ und merken sich aktive IP-Sitzungen in einer Tabelle.

Doch einige längst museumsreife Ausnahmen bestätigen die Regel: Vereinzelt finden sich auf alten Routern noch Access Control Lists (ACL), die nicht sitzungsbezogen arbeiten (stateful), sondern rein auf Quell- und Zieladressen ausgerichtet sind, ohne den Zustand einer Session zu beachten.

Dann kommt es vor, dass ein Antwortpaket des Servers erst kurz vor dem Erreichen des Clients von einer ACL blockiert wird und dann den Versand jenes Fehlercodes an den Server auslöst.

Address unreachable

Fall 3: In diesem Szenario kommt das IP-Paket fast an das Ende seines Wegs – es befindet sich im letzten Router vor dem Ziel und muss nur noch über (W)LAN zugestellt werden. Dafür ermittelt der letzte Router die Ethernet-Adresse des Zielhosts per Neighbor Solicitation (IPv6) oder Address Resolution Protocol (IPv4). Scheitert das, kommt es zu „address unreachable“.

Möglicherweise ist der Link down, also das LAN-Kabel durchgebissen, oder das WLAN kränkelt? Oder die Adresse gibt es nicht, was wiederum auf einen Tippfehler des Nutzers beziehungsweise DNS-Admins schließen lassen würde, vergleichbar zu Fall 1.

In beiden Fällen kann der Router mit dem IP-Paket nichts anfangen und muss es verwerfen – zum Glück nicht ohne die Quelle darüber zu informieren.

Falls ein Server diesen Fehler erhält, stecken dahinter dieselben Ursachen: Entweder der Client befindet sich nicht mehr im Netz oder hat keine korrekte Quell-IP-Adresse gemeldet. Eine falsche Adresse ähnelt Fall 1, mit dem Unterschied, dass hier die Host-ID der IP-Adresse und nicht die Netz-ID falsch ist.

Router verwahren im ARP-Cache die Zuordnungen von IP- zu MAC-Adressen ihrer Netzwerke. Im obigen Beispiel sind dem Router fünf IP-Adressen, aber nur vier MAC-Adressen bekannt. Die Abfrage der MAC-Adresse für 192.168.11.42 scheiterte nämlich (status incomplete). Daher kann der Router an dieses Ziel keine IP-Pakete ausliefern – er verwirft sie und meldet dem Absender per ICMP „address unreachable“.

Diese Fehlersituation kommt in großen Netzwerken, die aus mehreren, durch Switches verkoppelten Segmenten bestehen, in zwei Varianten vor: Clients können an einem falschen Switchport hängen oder im falschen VLAN stecken. Sie melden dann zwar eine korrekte Quell-IP-Adresse, doch die MAC-Adresse lässt sich trotzdem nicht ermitteln.

Der Router notiert die gescheiterte Auflösung in seinem ARP-Cache mit der Statusmeldung „incomplete“. Aber dort schlägt man bei einer Fehlersuche selten zuerst nach, zumal man als Admin nicht immer Zugang zu jedem Router einer Firma hat. Auch deshalb sind Mitschnitte und die Analyse von ICMP-Fehlermeldungen empfehlenswert.

Port unreachable

Fall 4: Das IP-Paket hat seinen Zielhost erreicht (Layer 3), juhu! Doof nur, wenn der Serveradmin den Dienst nicht korrekt konfiguriert hat oder der Service abgestürzt ist. Dann lauscht auf dem Layer-4-Zielport niemand. Beispielsweise kann das IP-Paket für einen DNS-Server gedacht sein, der auf Port 53 DNS-Anfragen annehmen soll. Doch wenn auf dem Server wegen einer Fehlkonfiguration dem Zielport 53 kein Dienst zugewiesen ist, muss das Betriebssystem das Päckchen verwerfen.

Auch in diesem Fall kann es einen ICMP-Fehler zurückmelden. Damit kann der Netzwerkadmin Flurfunkmutmaßungen widerlegen: Denn wenn mal „das Netzwerk“ diffus als Problem hingestellt wird, belegt diese Fehlermeldung, dass sowohl der Server als auch der Port erreicht worden sind, wo der Zuständigkeitsbereich des Netzadmins endet. Doch vielleicht hat der Client durch eine manuelle Fehleingabe eine falsche IP-Adresse angesteuert? Oder der Dienst ist temporär ausgefallen, da abgestürzt? Es liegt eben nicht immer am Netzwerk.

Falls Sie bei routinemäßigen Analysen auf viele Port-Unreachable-Meldungen stoßen: Es kann sich zwar um einen Portscan im Sinne eines Angriffs handeln, muss aber nicht. Möglicherweise arbeitet sich gerade ein internes Schwachstellenmanagement an einem Port-Scan ab oder ein Inventarisierungssystem scannt fröhlich im Netzwerk herum. Denn wenn ein Server auf Dutzenden TCP- und UDP-Ports abgeklopft wird, reagiert er mit vielen TCP-RST- beziehungsweise ICMP-Port-Unreachable-Meldungen.

Server erhalten diesen Fehler bei defekten Client-Implementierungen. Ein besonders drastisches Beispiel hat sich vor einer Weile im Internet-of-Things-Umfeld zugetragen: Der NTP-Client (Network Time Protocol) eines IoT-Geräts schickte massenweise Anfragen nach der aktuellen Zeit an einen NTP-Server mit dem UDP-Zielport 123 und einem dynamisch ausgewählten Quellport. Daraufhin antwortete der Server pflichtgemäß mit einem kurzen Päckchen und zwar korrekterweise mit dem Zielport 51680, den der Client genutzt hatte, sowie seinem NTP-Quellport 123. Doch keines der Antwortpäckchen erreichte den NTP-Client, denn der schloss den Port 51680 immer schon, bevor die NTP-Antwort ankam. Das Client-Betriebssystem musste daher alle NTP-Antworten verwerfen und dem Server per ICMP melden, dass es dessen Päckchen keinem Dienst zustellen konnte.

Unterm Strich war das ganze Geschnatter vergebens: Der Client erhielt keine Zeitinformation, der Server konnte nur mit den ICMP-Achseln zucken und der Netzwerkbetreiber musste einen Haufen Pakete nutzlos übertragen.

Sammelstellen

Wie bekommt man nun ICMP-Fehlermeldungen zu fassen? Die Grundlage ist immer ein Paketmitschnitt, den man mit Tools wie Wireshark analysiert. Das kann ein Live-Mitschnitt sein oder eine von einem anderen Gerät aufgezeichnete PCAP-Datei. Diese liefert zum Beispiel ein PC mittels tcpdump oder ein Router oder eine Firewall mittels eingebautem Packet Capture.

Standardmäßig kennzeichnet Wireshark ICMP-Fehler mit hellgrüner Schrift auf schwarzem Grund. Ein Klick auf ein solches Paket zeigt die erforderlichen Einzelheiten: einen der oben beschriebenen Fehler und das ursprüngliche IP-Paket, das den Fehler ausgelöst hat.

Anhand dieser Daten können Sie zweifelsfrei feststellen, woher das Paket kam und können es so einem Netzwerk, einem Gerät, User oder gar einer Session zuordnen. Besonders praktisch an Wireshark: Display-Filter, die sich auf Nutzdatenpakete beziehen, blenden auch die zugehörigen ICMP-Error-Pakete ein, denn jene enthalten das originale Paket und lassen sich so leicht identifizieren. Um in einem Mitschnitt alle Fehler anzeigen zu lassen, geben Sie als Display-Filter icmpv6.type eq 1 or icmp.type eq 3 ein.

Falls Sie üben möchten, aber keinen Mitschnitt zur Hand haben, können Sie das „Ultimate PCAP“ nehmen, das wir in c’t 24/2020 auf Seite 164 ausführlich beschrieben haben. Die aktuelle Version finden Sie hier.

Tipp: Falls Sie an Statistiken großer Mitschnitte interessiert sind, lassen Sie Wireshark erst einmal links liegen (Spoiler: Bei Dateien deutlich größer als 1 GByte kommt auch der beste Rechner an seine Grenzen). Nehmen Sie stattdessen das Wireshark-Kommandozeilentool tshark. Um beispielsweise eine Liste aller IPv6-Fehlercodes und deren Häufigkeit zu erzeugen, geben Sie tshark -r mein-grosser-mitschnitt.pcapng -Y "icmpv6" -T fields -e icmpv6.type -e icmpv6.code | sort | uniq -c ein. Mehr dazu finden Sie in c’t 14/2019 auf S. 142.

Richtig mitschneiden

Anders als vielleicht gedacht lauern bei Mitschnitten einige Fallstricke. Wenn Router oder PCs am Anschlag arbeiten, lassen sie schon mal Päckchen kommentarlos unter den Tisch fallen. Auch kann die Position im Netzwerk entscheidend dafür sein, einen Fehler zu finden. Wie man Mitschnitte optimal anlegt und mit welchen Geräten, haben wir ausführlich hier und hier beschrieben.

Für diesen Fall eine kleine Warnung vorweg: Es ist zwar gängige Praxis, mittels Capture-Filtern nur so viel mitzuschreiben, wie man wirklich braucht, denn man möchte die Netzwerkkarte und den Rechner nicht überfrachten. Aber der Capture-Filter muss der Situation angepasst sein.

In erster Näherung gilt es beispielsweise, nur den Verkehr der Endpunkte eines Dialogs zu erfassen. Das geht etwa mit dem Capture-Filter host 192.168.178.12 and host 8.8.8.8. Der fängt Pakete, die der IPv4-Host und der Public-DNS-Server von Google austauschen. Vorteil: In Wireshark erscheinen dann nur die für Ihre aktuelle Troubleshooting-Session erforderlichen Pakete!

Wirklich? Leider gefehlt! Denn ICMP-Errors verschicken ja größtenteils die Router entlang des Pfades und deren IP-Adressen kennt man normalerweise nicht vor dem Mitschnitt. Bei einem solchen Capture-Filter fallen also wegweisende Fehlercodes durch das Sieb und Sie bekommen sie nicht zu Gesicht.

Aber man kann den Filter leicht erweitern, um Fehlermeldungen mitzuschreiben: Hängen Sie einfach or icmp6 or icmp an. So landen zwar sämtliche ICMP-Meldungen im Kescher, aber eben auch jene, die sich auf den Verkehr Ihrer beiden Hosts beziehen. Ein Mitschnitt ist eben nur so gut, wie der Mitschnitt ist.

Und nur zur Wiederholung: Capture Filter beziehen sich auf den Befehl tcpdump und sollten nicht mit den ähnlich klingenden Display-Filtern der Wireshark-GUI verwechselt werden. Display-Filter wie ip.addr eq 192.168.178.12 and ip.addr eq 8.8.8.8 berücksichtigen nämlich durchaus auch ICMP-Errors. Aber dafür muss sie der Mitschnitt auch enthalten.

Fallstudie NTP-Server

ICMP-Fehlermeldungen geben nicht nur Hinweise auf konkrete Fehlerursachen, sondern auch einen Eindruck davon, wie gut die eine oder andere Technik im Internet implementiert ist. Das kam bei einer internen Studie mit einem öffentlichen NTP-Server als Teil des NTP Pool Project heraus.

Während eines zweimonatigen Zeitraums wurden sowohl IPv6- als auch IPv4-NTP-Anfragen und die zugehörigen Ergebnisse mitgeschnitten. Auf dieser Basis lässt sich dann beispielsweise beantworten, wie viele Netzwerkfehler aus dem Internet zum NTP-Server gesendet werden. Es waren erstaunlich viele, wie die nachfolgende Tabelle zeigt.

Die Statistik belegt zunächst, dass jeder der beschriebenen Fehler im Internet vorkommt und die Router die Fehler melden.

Es erstaunt aber, dass weit mehr als ein Prozent der NTP-Antworten nicht ausgeliefert wurde. Die Fehlermeldungen verteilen sich je nach IP-Protokoll unterschiedlich: NTP-Pakete, die per IPv6 angefragt und ausgeliefert wurden, liefen in fast 90 Prozent der Fälle im Layer-3-Netz ins Leere – offenbar scheiterte in diesen Fällen die Neighbor Discovery. Ursache könnten Bugs in der MAC-Adressauflösung sein.

Bei NTP-Paketen, die per IPv4 übertragen wurden, klappt die MAC-Addressauflösung viel öfter. Die meisten IPv4-Fehler passieren beim allerletzten Übertragungsschritt, nämlich der Zustellung der NTP-Antworten an die anfragenden Clients. Hier sind möglicherweise die NTP-Implementierungen buggy.

Challenges gefällig?

Falls Sie nun Ihre Wireshark-Skills testen möchten, hätten wir einige Herausforderungen für Sie: Im Ultimate-PCAP-File stecken einige Fehler, an denen Sie üben und Ihr Know-how schärfen können. Die Auflösung erscheint voraussichtlich in der nächsten c’t.

Laden Sie das PCAP-File auf Ihren PC und öffnen Sie es mit Wireshark. Anschließend geben Sie drei verschiedene Filter ein und schlussfolgern aus der Wireshark-Darstellung, welche Ursachen zu den jeweiligen Ergebnissen geführt haben.

Display-Filter 1: udp.stream in {1177,1178} Hier liefert dieselbe DNS-Anfrage (DNS-Query) anscheinend verschiedene Fehler. Was könnte der Grund dafür sein?

Display-Filter 2: udp.stream in {249,251} Vergleichen Sie die Fehler. Was sind die Unterschiede? Was sticht beim zweiten Fall hervor?

Display-Filter 3: udp.stream == 1178 Hier wurde auf dem Client, der die NTP-Anfrage stellt, mitgeschnitten. Wie weit entfernt war die Firewall? Tipp: Hop Limits.

Und zum Schluss noch eine tshark-Challenge: Analysieren Sie alle „destination unreachables“ vom Typ „port unreachable“, die zur IPv4-Adresse 194.247.5.12 geschickt wurden. Führen Sie alle Quell-IPv4-Adressen auf und entfernen Sie doppelte Einträge automatisch.

Fazit

Vielen Admins blieb der ICMP-Schatz bisher verborgen, doch damit meldet das Netzwerk in einigen Fällen selbst, welche Ursache einem Fehler zugrunde liegt; der Admin muss sie lediglich heben und kann so seine Diagnosen oft drastisch abkürzen.

Die Abkürzung kann man sowohl beim Schluckauf im internen Netz als auch im Internet nutzen. Liegt die Ursache in Ihrem Zuständigkeitsbereich, führt sie fast immer direkt zur Lösung.

Ein Hemmschuh ist die händische Analyse – weder Router noch moderne Firewalls liefern ICMP-Statistiken, geschweige denn Klartexthinweise zu fehlgeschlagenen IP-Dialogen. Zeit für einen persönlichen Hausputz im eigenen Netz.

Soli Deo Gloria!

Photo by National Cancer Institute on Unsplash