☰

Ping funktioniert nicht, aber Wireshark erkennt ICMP-Anfragen und -Antworten

tag-icon • tag-icon ping wireshark
Ping funktioniert nicht, aber Wireshark erkennt ICMP-Anfragen und -Antworten

Ich stehe vor einem seltsamen Problem und wäre dankbar, wenn jemand von Ihnen Informationen hinzufügen könnte.

Ich habe zwei verschiedene Subnetze konfiguriert und versuche testweise, eine Maschine unter 10.10.11.9/30 (in einem Subnetz) von einer anderen Maschine unter 10.10.11.1/30 (in einem anderen Subnetz) anzupingen. Der Ping funktioniert nicht (zu Recht).

Wenn ich jedoch versuche, dasselbe in Wireshark zu erkennen, werden anstelle von „nicht erreichbar“-Meldungen normale ICMP-Anfragen und -Antworten angezeigt. Es ist, als ob Pakete ihren Weg finden würden …

Ich habe einen Screenshot angehängt Bildbeschreibung hier eingeben für Ping sowie Wireshark

Ich habe versucht, die Header-Prüfsumme in IP-Paketen zu berechnen, aber selbst dabei scheinen die Prüfsummen der in Wireshark erfassten Pakete korrekt zu sein – während Ping anzeigt, dass alle Pakete verloren gegangen sind.

Kann jemand Informationen hinzufügen?

Vielen Dank

Antwort1

Vorausgesetzt, Ihr Setup ist tatsächlich so, wie Sie es beschreiben (nichts ist versehentlich falsch konfiguriert): Sofern der Client 10.10.11.1/30 nicht über Informationen zum Routing zu 10.10.11.9/30 verfügt (über das Standard-Gateway, statische Routen usw.), sollten keine ICMP-Pakete gesendet werden.

Probieren Sie es mit Cisco Paket Tracer aus. Richten Sie ein Netzwerk mit zwei Clients und einem Switch dazwischen ein. Solange kein Standard-Gateway konfiguriert ist (und sich die Clients in unterschiedlichen Broadcast-Domänen befinden), sendet der Client nicht einmal ARP-Pakete.

Das bedeutet, dass Ihre aktuelle Konfiguration eine Art „Routing-Auflösung“ bietet, sodass die ICMP-Pakete tatsächlich gesendet und empfangen werden. Möglicherweise über das Standard-Gateway, eine statische Route usw. Überprüfen Sie Schicht 2. Auf welche MAC-Adresse werden die Frames gesendet? Direkt an den Client oder an einen Router? Wie ich in meinem Kommentar geschrieben habe:

das ICMP-Paket musste über einen Router, eine statische Route, eine „exotische“ Konfiguration wie „Proxy-ARP“ usw. gesendet werden. Was passiert auf Schicht 2? Wie wird die IP-Adresse in eine MAC-Adresse aufgelöst? Ich denke, das führt Sie zur Lösung, warum es überhaupt eine Antwort gibt (was nicht der Fall sein sollte).

Warum die empfangenen Pakete nicht in den Ping-Statistiken angezeigt werden, ist eine andere Sache. Es könnte sein, dass eine Firewall sie blockiert (meine Vermutung, da der Ping-Befehl weder Fehler noch Bestätigungen zu den einzelnen Pings ausgibt, sondern nur eine Zusammenfassung).

Die einzige andere Erklärung, die ich habe, ist, dass es eine andere Art von verrückter Konfiguration gibt, die das System durcheinander bringt (z. B. ein zweiter Client mit derselben IP-Adresse wie das Ziel und innerhalb der Broadcast-Domäne wie die Quelle usw.). Sie können dies auch auf Schicht 2 überprüfen, indem Sie die MAC-Adressen der Frames mit denen der tatsächlichen Clients vergleichen.

Nachträglicher Einfall: Könnte es sein, dass Sie ein Standard-Gateway, eine statische Route usw. eingerichtet haben? Hat der Router beispielsweise eine 24-Bit-Netzwerkmaske? In diesem Fall überschneiden sich die Broadcast-Domänen von Router und Clients, obwohl das Subnetz unterschiedlich ist. Dies könnte das aktuelle Verhalten erklären.

Antwort2

Ihr Netzwerk ist in einem schlechten Zustand, wahrscheinlich aufgrund einer Verwechslung der Netzmasken:

  • Der ICMP-Anforderung geht eine vorherige ARP-Anforderung voraus, entweder unmittelbar oder irgendwann davor. Offensichtlich war die ARP-Anforderung erfolgreich, sodass ein Knoten wusste, wo er sich befindet, 10.10.11.9 und seine MAC-Adresse zurückgab, sonst wäre die ICMP-Anforderung nie gesendet worden.

  • Die PING-Anfrage hätte „net unreachable“ (oder zumindest „host unreachable“) zurückgeben sollen, was aber nicht der Fall war. Die ICMP-Anfrage wurde also erfolgreich gesendet und mit einem Erfolgscode zurückgegeben.

Bleibt die Frage, warum der Ping-Befehl dennoch einen 100%igen Paketverlust meldete.

Ich kann nur vermuten, dass der Ping-Befehl selbst die Antwort verworfen hat, möglicherweise weil sie aus einem anderen Netzwerk kam.

Meine Schlussfolgerung ist, dass einige andere Knoten im Netzwerk verwenden 10.10.11.x/24und daher den Ping übermitteln, was für große Verwirrung beim 10.10.11.1/30Knoten sorgt.

verwandte Informationen