Tracert seltsames verhalten.

[ByteFax]

Guten Morgen .. ..

Ich hatte dieses Phänomen bislang noch nicht deshalb frage ich mich was hier irgendwie miskonfiguriert sein könnte.
bei normalen traceroutes kann ich jeweils nur den letzten hop sehen.

Die anzahl der Hops scheint dabei zu stimmen ...


Via IPv6 geht es ganz normal

C:\Windows\system32>tracert -4 google.com

Routenverfolgung zu google.com [216.58.205.238]
über maximal 30 Hops:

  1     *        *        *     Zeitüberschreitung der Anforderung.
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7     5 ms     5 ms     5 ms  fra15s24-in-f14.1e100.net [216.58.205.238]

Ablaufverfolgung beendet.

C:\Windows\system32>tracert -4 facebook.com

Routenverfolgung zu facebook.com [185.60.216.35]
über maximal 30 Hops:

  1     *        *        *     Zeitüberschreitung der Anforderung.
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8     5 ms     5 ms     5 ms  185.60.216.35

Ablaufverfolgung beendet.

C:\Windows\system32>tracert -4 computerbase.de

Routenverfolgung zu computerbase.de [87.230.75.2]
über maximal 30 Hops:

  1     *        *        *     Zeitüberschreitung der Anforderung.
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7     8 ms     9 ms     8 ms  www.computerbase.de [87.230.75.2]

Ablaufverfolgung beendet.

 

[up.whatever]

ICMP irgendwie in der Firewall gefiltert?

 

[ByteFax]

Ich hatte test weise (ich weiß Pfui) sogar die Windows Firewall komplett abgeschaltet..
Es brachte aber keine Änderung :/

 

[up.whatever]

Ich dachte jetzt eher an eine Firewall im Router. Anscheinend wird bei dir ICMPv4 Type 11 eingehend blockiert, darum siehst du erst eine Antwort sobald die TTL groß genug ist um das Ziel zu erreichen.

 

[ByteFax]

Ich habe nun mal test weise in einer virtuellen Maschine ein Debian installiert,
da klappt es komischerweise ..

 

[TheCadillacMan]

traceroute unter Linux verwendet standardmäßig UDP statt ICMP. Das könnte das unterschiedliche Verhalten erklären.

 

[ByteFax]

Das macht natürlich sinn, .. aber .. irgendwie scheint leider auch das nicht die lösung zu sein

den ich hab das ganze jetzt mal mit einem Windows10 als Virtuelle maschine versucht.

 

[TheCadillacMan]

Irgendwelche Security-Software (Virenscanner, Firewalls etc.) installiert?

 

[ByteFax]

Nein nichts der gleichen ..

Firewall ist die von Windows (welche test weise auch schon deaktiviert wurde)
und auch sonst ist nur der Windows defender am werkeln, an dem ich nichts weiter geändert hab.

 

[Raijin]

Grundsätzlich sind Zeitüberschreitungen in einem trace nicht ungewöhnlich und auch nicht schlimm. Das sagt normalerweise einfach nur aus, dass der Hop nicht direkt angepingt werden will. Geht der Ping allerdings durch ihn hindurch (zum nächsten Hop), leitet er ihn anstandslos weiter.

Dass nun aber scheinbar alle Hops nicht antworten, ist schon merkwürdig. An deiner Stelle würde ich nun mal mit Wireshark gucken wie der ICMP Traffic aussieht. Die Frage ist jetzt nämlich ob es ein generelles Problem mit Windows oder dem Treiber ist oder ob es speziell tracert betrifft.

 

[areiland]

Also an Tracert kanns eigentlich nicht liegen, denn bei mir tritt sowas nicht auf:

 

[Raijin]

Ich meinte jetzt auch keinen allgemeinen Bug oder so. Es geht um die Eingrenzung des Fehlers. Lieber mit der Schrotflinte auf alles ballern als mit Scheuklappen zB hinter der Firewall herzurennen

Mit WireShark kann man normalerweise den kompletten Weg des trace verfolgen. D.h. man sieht die Echo-Requests und die Replies. Irgendwas scheint ja anders zu sein. Die Router-Firewall ist zB eher unschuldig, da es sonst ja aus der VM auch nicht funktionieren würde.

 

[TheCadillacMan]

Ist das ein Hetzner-Server? Hast du mal die Firewall-Einstellungen im Robot überprüft?

 

[ByteFax]

Also ich bin mir relativ sicher das es mal funktionierte.
Daher wundert mich das ganze ja auch.

Die Tatsache das die Virtuellen Maschinen auf dem Rechner Tracen können
das Hostsystem aber nicht, wundert mich dann noch viel mehr.

@TheCadillacMan
Ja ist ein Hetzner Server..
Im Robot existiert nur die Standard regel : Allow all

 

[ByteFax]

so ich hab jetzt noch mal geschaut , das ttl scheint aus irgendwelchen gründen hier ursächlich zu sein

 

[Raijin]

Die TimeToLive, kurz TTL ist die Grundlage von einem Trace. Jeder Hop auf dem Weg reduziert die TTL um 1 und wenn die TTL auf 0 sinkt, wird das Paket nicht mehr weitergeleitet, sondern mit einer Fehlermeldung an den Sender quittiert, "TTL exceeded". Genau das ist dann die Information, die ein traceroute auswertet, weil man dann sehen kann von welcher Quelle, also von welchem Hop diese Antwort kam.

Ein Traceroute arbeitet daher so:

- Ping mit TTL=1 an das Ziel (zB 8.8.8.8) --> Heimrouter merkt, TTL-1=0 --> Fehlermeldung
--> insgesamt 3x wiederholen und Antwortzeit auswerten
- Ping mit TTL=2 an das Ziel --> Heimrouter TTL-1=1 --> Provider-Gateway TTL-1=0 --> Fehlermeldung
--> ingesamt 3x wiederholen und Antwortzeit auswerten
- Ping mit TTL=3 an das Ziel --> TTL-1=2 --> TTL-1=1 --> irgendein Router nach dem Provider TTL-1=0 --> Fehler
--> insgesamt 3x wiederholen und Antwortzeit auswerten

So baut sich ein Trace auf bis die TTL groß genug ist und das Ziel antwortet.

Mein trace sieht in WireShark ähnlich aus wie deiner, es gibt aber feine Unterschiede: Die Zeit zwischen dem Echo Request und der anschließenden TTL exceeded Meldung liegt bei ca. 10-24 ms. Ein Hop, der nicht auf den Ping reagiert (=Timeout) sendet überhaupt keine Antwort, bei dir kommen sehr wohl Meldungen an.

Da WireShark vor der Firewall agiert, gehe ich davon aus, dass in deinem Falle die Firewall diese Meldungen rausfiltert. Für tracert sieht es bei dir daher so aus als wenn der Hop nicht antwortet, obwohl es der Fall ist. Mach dasselbe mal in deiner Windows VM und ich vermute, dass der Trace in WireShark identisch aussehen wird - nur dass in der VM der Reply auch zu tracert durchgereicht und nicht von der Firewall geblockt wird.

Wenn dem so ist, solltest du dir die Firewall im Host nochmal ganz genau anschauen. "Ausschalten" ist bei Firewalls immer so eine Sache. Sie stecken sehr tief im System drin und da hat "ausschalten" nicht unbedingt immer den Effekt, den man erwartet. Insbesondere bei separaten Firewalls wie ZoneAlarm o.ä.
Für einen erfolgreichen ICMP-Trace muss die Firewall mindestens eingehende ICMP-Pakete des Typs 11 (TTL exceeded) erlauben. Ich bin mir gerade nicht 100%ig sicher, aber es kann sein, dass noch weitere nötig sind für andere Rückmeldungen der Hops. Zur Not eingehendes ICMP komplett erlauben.