☰

Pakete werden zurückgegeben, aber Traceroute schlägt fehl

tag-icon • tag-icon wireshark networking
Pakete werden zurückgegeben, aber Traceroute schlägt fehl

Ich erhalte diese Ausgabe von Traceroute:

#traceroute -i eth1 -s 192.168.12.14 192.168.1.72

1  192.168.12.1 (192.168.12.1)  1.410 ms  2.076 ms  2.251 ms
2  * * *
3  * * *
etc..

Aber in einem anderen Terminal kann ich die korrekten Antworten (Port nicht erreichbar) sehen, die vom Zielhost eintreffen:

9.964867 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)     
9.964879 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964886 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964904 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964923 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964927 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)

Zuerst dachte ich, es läge an einem Firewall-Problem, aber ich habe nachgeschaut und es wurden keine Pakete verloren. Das Einzige, was mir einfällt, ist, dass dies die zweite Netzwerkkarte ist ...

Wenn ich Traceroute zum selben Host auf der ersten Netzwerkkarte ausführe, erhalte ich denselben Wireshark-Trace wie oben (offensichtlich mit einer anderen Quell-IP) – aber der Traceroute-Befehl ist erfolgreich.

Ich verstehe nicht, wie Wireshark die Antworten sehen kann, aber Traceroute auf der zweiten Netzwerkkarte fehlschlägt.

Ich glaube, ich übersehe hier etwas ziemlich Grundlegendes …

Antwort1

Wireshark zeigt an, was über die Netzwerkschnittstelle ankommt. Der Kernel hat diese Pakete offensichtlich gesehen, aber aus irgendeinem Grund entschieden, dass sie nicht an den Traceroute-Befehl übermittelt werden sollen.

Es gibt einige Dinge, die schiefgelaufen sein könnten und dazu geführt haben, dass der Kernel sich dazu entschieden hat, diese Pakete nicht zuzustellen.

  • Möglicherweise verfügen Sie über ein asymmetrisches Routing, das nicht für die Rückpfadfilterung geeignet ist, haben es aber rp_filteraktiviert gelassen.
  • Der Kernel kann den Inhalt der ICMP-Fehlermeldung möglicherweise nicht einem lokalen Socket zuordnen. Dies kann daran liegen, dass das Paket abgeschnitten wurde, obwohl nicht genügend Informationen für eine solche Entscheidung verfügbar waren. Dies kann auch an einer fehlerhaften NAT-Konfiguration liegen, bei der Pakete in eine Richtung durch ein NAT geleitet werden, in die andere jedoch nicht.
  • Der Kernel kann die Pakete aufgrund einer falschen Prüfsumme verwerfen.

Von diesen scheint mir dies rp_filterdie wahrscheinlichste Erklärung zu sein. Sie haben kein Betriebssystem angegeben, aber es sieht so aus, als ob es ein Linux-System sein könnte. Versuchen Sie also diesen Befehl: head /proc/sys/net/ipv4/conf/*/rp_filter. Sie würden wahrscheinlich 1auf jedem davon sehen, was bedeutet, dass der Filter aktiviert ist. Versuchen Sie, ein 0an die Schnittstelle zu schreiben, von der die Pakete gelöscht werden, sowie an den allGerätenamen.

Antwort2

Können Sie die Ausgabe der Routing-Tabelle jeder Box hier posten? Wenn Sie eine ungültige/fehlende Standardroute haben, haben die Pakete keinen Rückweg. Bitte posten Sie die Ausgabe von:

# IP-Routenliste

auf jeder Linux-Box.

verwandte Informationen