Ping-Fehlermeldungen und was sie bedeuten
Wenn etwas im Netzwerk nicht funktioniert, probiert man optimalerweise als erstes mit Ping oder Traceroute, ob überhaupt eine Kommunikation mit der Gegenstelle an sich möglich ist.
Bei Problemen liefern diese Tools oft hilfreiche Fehlermeldungen, die allerdings oft ignoriert werden, obwohl sie den Fehler klar aufzeigen (OK, manchmal um die Ecke herum).
Deshalb gibt es hier eine Liste der möglichen Fehlermeldungen, die einem begegnen können und welches Problem sie verursacht.
Ob die Fehlermeldungen bei jedem Betriebssystem und jeder Version exakt so auftreten kann ich natürlich nicht garantieren - aber sinngemäß waren sie bisher überall identisch.
Diese Liste erhebt auch keinen Anspruch, vollständig oder abschließend zu sein
Wie bei allen Anleitungen gilt: Bei konkreten Problemfällen stelle deine Frage bitte im Forum, nicht als Kommentar
Dieser Fehler deutet darauf hin, dass dein lokales System versucht, die Ziel-IP mittels ARP oder NDP in eine MAC-Adresse aufzulösen und genau das gescheitert ist.
An dieser Stelle kann man Firewalls mit 99%iger Sicherheit ausschließen - denn egal, wie fies die Firewall filtert, sie muss wenigstens auf ARP/NDP reagieren.
Mögliche Fehlerursachen:
Um das genauer zu untersuchen, sollte man einen Traceroute durchführen und sehen, wo die Pakete her fließen, um sicher zu gehen, dass diese auch den erwarteten Weg nehmen.
Wenn dem so ist, entspricht das Fehlerbild dem Block über diesem.
In seltenen Fällen könnte hier aber eventuell eine Firewall absichtlich eine Desinformations-Kampagne betreiben und diese Fehlermeldung senden, weil eine Firewall-Regel dies so vorsieht.
Dieser Fehler deutet darauf hin, dass dein lokales System das Paket gerne an einen Router geben würde - aber nicht weiß, an welchen.
Kontrolliere die lokale Subnetzmaske und Routingtabelle. Du müsstest für das Netz von "a.b.c.x/M" eine Route haben, die auf das Interface zeigt, auf dem die IP aus dem Netz gebunden ist.
Mögliche Ursachen:
Um dies zu prüfen, sollte man direkt nach oder während einem Ping-Versuch den lokalen ARP-Cache ansehen und gucken, ob die erwartete MAC-Adresse dort drin steht.
Bei (einseitig) falscher VLAN-Zuordnung würden ja auch entweder die ARP-Anfragen oder Antworten verschütt gehen und du hast das Fehlerbild wie "Zielhost nicht erreichbar".
Wenn das alles passt, gibt es diese möglichen Fehlerursachen:
Falls eine unerwartete MAC-Adresse im ARP-Cache auftaucht, ist entweder die IP doppelt vergeben oder ein Router macht Proxy-ARP.
Ersteres erkennt man an ständig wechselnden MAC-Adressen im Cache, zweiteres dadurch dass die MAC-Adresse identisch mit der eines Routers ist.
Auch ein Blick in die Routingtabelle des Ziel-Systems kann nicht schaden.
Ein Traceroute sollte Aufschluss bringen, wo die Pakete versanden - dieser Traceroute sollte unbedingt von beiden Seiten aus gemacht werden, damit man bestimmen kann, ob die Echo-Anfrage nicht ankommt oder die Antwort verschütt geht.
Notfalls muss man auf dem Zielsystem mit Wireshark/tcpdump lauschen, ob man eingehende ICMP-Echo-Requests sieht, um bestimmen zu können in welche Richtung die Pakete nicht ankommen.
Bei Problemen liefern diese Tools oft hilfreiche Fehlermeldungen, die allerdings oft ignoriert werden, obwohl sie den Fehler klar aufzeigen (OK, manchmal um die Ecke herum).
Deshalb gibt es hier eine Liste der möglichen Fehlermeldungen, die einem begegnen können und welches Problem sie verursacht.
Ob die Fehlermeldungen bei jedem Betriebssystem und jeder Version exakt so auftreten kann ich natürlich nicht garantieren - aber sinngemäß waren sie bisher überall identisch.
Diese Liste erhebt auch keinen Anspruch, vollständig oder abschließend zu sein
Wie bei allen Anleitungen gilt: Bei konkreten Problemfällen stelle deine Frage bitte im Forum, nicht als Kommentar
"Antwort von a.b.c.d: Zielhost nicht erreichbar" bzw. "Destination Host Unreachable"
"a.b.c.d" ist der Rechner, von dem aus ich pinge
Die IP-Adresse, welche du anpingst, befindet sich im selben Subnetz wie das System, von wo aus du den Ping ausführst.Dieser Fehler deutet darauf hin, dass dein lokales System versucht, die Ziel-IP mittels ARP oder NDP in eine MAC-Adresse aufzulösen und genau das gescheitert ist.
An dieser Stelle kann man Firewalls mit 99%iger Sicherheit ausschließen - denn egal, wie fies die Firewall filtert, sie muss wenigstens auf ARP/NDP reagieren.
Mögliche Fehlerursachen:
- IP-Adresse ist ganz schlicht falsch.
- IP-Adresse ist auf dem falschen Interface konfiguriert oder das Interface ist deaktiviert.
- Die Subnetzmaske deines lokalen Systems ist falsch konfiguriert.
- Eines der beiden Systeme befindet sich im falschen VLAN oder VLAN-Tagging funktioniert nicht richtig.
- bei virtuellen Systemen: Virtuelle Maschine ist nicht an der richtigen Bridge/vSwitch angeschlossen oder die vSwitch ist nicht mit dem richtigen physischen NIC verbunden.
"a.b.c.d" ist NICHT mein lokaler Rechner
Wenn es die IP eines Routers ist, will dir der Router mitteilen, dass er genau das Problem hat, wie direkt im Block hier drüber beschrieben.Um das genauer zu untersuchen, sollte man einen Traceroute durchführen und sehen, wo die Pakete her fließen, um sicher zu gehen, dass diese auch den erwarteten Weg nehmen.
Wenn dem so ist, entspricht das Fehlerbild dem Block über diesem.
In seltenen Fällen könnte hier aber eventuell eine Firewall absichtlich eine Desinformations-Kampagne betreiben und diese Fehlermeldung senden, weil eine Firewall-Regel dies so vorsieht.
Antwort von a.b.c.d: "Zielnetz nicht erreichbar" bzw. "Destination unreachable: no route"
"a.b.c.d" ist der Rechner, von dem aus ich pinge und ich befinde mich auch im selben Subnetz wie das Ziel
Das sieht dein lokales System andersDieser Fehler deutet darauf hin, dass dein lokales System das Paket gerne an einen Router geben würde - aber nicht weiß, an welchen.
Kontrolliere die lokale Subnetzmaske und Routingtabelle. Du müsstest für das Netz von "a.b.c.x/M" eine Route haben, die auf das Interface zeigt, auf dem die IP aus dem Netz gebunden ist.
"a.b.c.d" ist NICHT mein lokaler Rechner und das Ziel befindet sich in einem anderen Subnetz
"a.b.c.d" ist ein Router und weiß nicht, wie er die Daten ans Ziel bringen soll.Mögliche Ursachen:
- Das Netz fehlt in der Routingtabelle und es gibt keine Defaultroute die genutzt werden könnte.
- Das Netz ist ein lokales Netz, "a.b.c.d" aber der Router des Providers - dann hat dein lokaler Router keine Router für das Zielnetz und alles ans Defaultgateway (Provider) gegeben, der natürlich nicht weiß, was er damit anfangen soll.
- Es existiert eine spezifische "unreachable"-Route auf dem Router, die greift. Entweder, weil eine noch spezifischere Route fehlt oder weil das Netz generell unerreichbar sein soll.
- Eine Firewallregel auf einem Router blockiert die Kommunikation in Richtung Ziel und sendet diese Meldung.
"Zeitüberschreitung der Anforderung"
Ich befinde mich im gleichen Subnetz wie die IP-Adresse, die ich anpinge
Die gute Nachricht: IP-Adressen und ggf. auch VLANs sind erstmal soweit richtig konfiguriert, da offensichtlich die ARP-/NDP-Auflösung funktioniert hat.Um dies zu prüfen, sollte man direkt nach oder während einem Ping-Versuch den lokalen ARP-Cache ansehen und gucken, ob die erwartete MAC-Adresse dort drin steht.
Bei (einseitig) falscher VLAN-Zuordnung würden ja auch entweder die ARP-Anfragen oder Antworten verschütt gehen und du hast das Fehlerbild wie "Zielhost nicht erreichbar".
Wenn das alles passt, gibt es diese möglichen Fehlerursachen:
- Firewall auf dem Ziel verschluckt Ping-Anfragen (oder lokale Firewall verschluckt die Antworten)
- Das Ziel hat eine falsche (zu kleine Subnetzmaske) und versucht, die Antworten durch ein Gateway zu schicken. Wenn es kein Gateway hat, gehen halt keine Antworten raus.
- Das Ziel hat eine verkorkste Routing-Tabelle und antwortet eventuell auf einem unerwarteten Netzwerk-Interface.
- Es gibt überlappende nicht-disjunkte Netze, wodurch das Ziel auf einem unerwarteten Interface antwortet.
Falls eine unerwartete MAC-Adresse im ARP-Cache auftaucht, ist entweder die IP doppelt vergeben oder ein Router macht Proxy-ARP.
Ersteres erkennt man an ständig wechselnden MAC-Adressen im Cache, zweiteres dadurch dass die MAC-Adresse identisch mit der eines Routers ist.
Auch ein Blick in die Routingtabelle des Ziel-Systems kann nicht schaden.
Ich befinde mich in einem ANDEREN Subnetz, welches per Router oder VPN verbunden ist
Hier ist mit hoher Wahrscheinlichkeit eine Firewall oder eine unvollständige Routingtabelle im Weg.Ein Traceroute sollte Aufschluss bringen, wo die Pakete versanden - dieser Traceroute sollte unbedingt von beiden Seiten aus gemacht werden, damit man bestimmen kann, ob die Echo-Anfrage nicht ankommt oder die Antwort verschütt geht.
Notfalls muss man auf dem Zielsystem mit Wireshark/tcpdump lauschen, ob man eingehende ICMP-Echo-Requests sieht, um bestimmen zu können in welche Richtung die Pakete nicht ankommen.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 458606
Url: https://administrator.de/tutorial/ping-fehlermeldungen-und-was-sie-bedeuten-458606.html
Ausgedruckt am: 22.12.2024 um 22:12 Uhr
2 Kommentare
Neuester Kommentar