Behandeln Linux (4.15.0-130) und Windows (10) ICMP unterschiedlich?

Question

Beim Versuch, eine Windows 10-Maschine mit unregelmäßigen Netzwerkproblemen zu beheben, habe ich einen Traceroute zu einem Host durchgeführt und etwas andere Ergebnisse erhalten als auf meinem Ubuntu 18.04-System mit Kernel 4.15.0-130. Um Hardwarefaktoren, fehlerhafte Protokollstapel, Treiberprobleme und dergleichen auszuschließen, habe ich dann Windows 10 in einer VirtualBox-VM mit Linux mit dem verglichen, was mir das Hostsystem bietet. VirtualBox wurde mit NAT eingerichtet, d. h. Windows 10 stellt eine Verbindung zum Host her, der dann die eigentliche Netzwerk-E/A abwickelt. Daher verwenden beide Sitzungen denselben Netzwerkadapter und alles läuft über denselben Protokollstapel auf dem Host. Es ist kein VPN beteiligt; die Client-Maschine hängt einfach an einem WiFi/3G-Internet-Router.

Der Host, den ich durchführe, kann von Linux aus (mit dem Firefox-Webbrowser) erreicht werden, jedoch nicht von Windows 10 aus (weder auf dem anderen Windows 10-Computer mit Firefox noch in VirtualBox mit Chrome).

Windows (läuft in Virtual Box unter Linux) gibt mir:

>tracert -d www.brewforafrica.co.za

Tracing route to www.brewforafrica.co.za [41.203.18.81]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  10.0.2.2
  2     3 ms     3 ms     3 ms  192.168.0.1
  3    56 ms    23 ms    36 ms  10.113.42.52
  4    83 ms    31 ms    22 ms  10.251.60.253
  5     *        *        *     Request timed out.
  6    74 ms    34 ms    29 ms  10.251.60.233
  7    88 ms    39 ms    20 ms  10.251.60.234
  8     *      103 ms    39 ms  10.113.145.33
  9    25 ms    33 ms    24 ms  196.207.35.36
 10    82 ms    32 ms    43 ms  192.168.133.110
 11    54 ms    25 ms    42 ms  41.21.235.25
 12    69 ms    80 ms    62 ms  10.118.24.61
 13   103 ms    35 ms    35 ms  196.60.9.24
 14    46 ms    45 ms    53 ms  197.189.193.1
 15    95 ms    53 ms    35 ms  41.203.18.81

Trace complete.

(Hinweis: 10.0.2.2 ist die von VirtualBox bereitgestellte Standard-Gateway-Adresse. Ab da übernimmt Linux die gesamte Netzwerkverbindung, daher ist dieser Hop im folgenden Traceroute nicht vorhanden.) Wenn ich denselben Traceroute mit Linux wiederhole (auf demselben System, auf dem die Virtual Box-Sitzung mit dem oben genannten Windows 10 ausgeführt wird), erhalte ich Folgendes:

$ traceroute -n www.brewforafrica.co.za

traceroute to www.brewforafrica.co.za (41.203.18.81), 30 hops max, 60 byte packets
 1  192.168.0.1  1.416 ms  1.580 ms  1.668 ms
 2  10.113.42.52  24.311 ms  25.119 ms  38.804 ms
 3  10.251.60.253  39.793 ms  39.875 ms  39.922 ms
 4  * * *
 5  10.251.60.233  40.122 ms  41.365 ms  51.445 ms
 6  10.251.60.234  51.910 ms  50.416 ms  50.508 ms
 7  10.113.145.33  50.836 ms  27.691 ms  27.251 ms
 8  196.207.35.36  31.254 ms  73.984 ms  63.871 ms
 9  192.168.133.110  73.479 ms  73.528 ms  62.612 ms
10  41.21.235.25  52.088 ms  61.699 ms  61.572 ms
11  10.118.24.61  62.102 ms  62.275 ms  61.833 ms
12  196.60.9.24  61.680 ms  51.679 ms  39.123 ms
13  197.189.193.1  40.032 ms  40.073 ms  43.791 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
$ 

Was sind die Gründe für diesen Unterschied und ist er in irgendeiner Weise von Bedeutung?

Answer 1

Es ist nicht derselbe Traceroute. Linux traceroutesendet standardmäßig UDP-Probeläufe, statt ICMP-Echos wie Windows. Verwenden Sie es, sudo traceroute --icmpum etwas zu erreichen, das Windows näher kommt. (Probieren Sie es aus, mtrwenn Sie schon dabei sind.)

Wenn das endgültige System über eine Firewall verfügt, die UDP-Pakete auf unbekannten Ports ¹ stillschweigend verwirft , bedeutet das Ausbleiben einer Antwort, dass das Traceroute-Programm nicht wissen kann, wohin die Pakete gegangen sind. Es kann auch nicht erkennen, dass die Sonden endlich das endgültige Ziel erreicht haben und es nicht mehr nötig ist, weiterhin immer längere TTL-Tests durchzuführen.

---

¹ Das Gleiche würde mit jeder Art von Traceroute-Test passieren ² , aber das Löschen von UDP ist einfach viel häufiger als das Löschen von ICMP-Echo. (Es muss nicht einmal eine absichtliche Blockierung sein – einige Betriebssysteme tun es standardmäßig, ignorieren UDP und sogar TCP und bleiben ruhig, wenn die Standards einen ICMP-Port nicht erreichbar erfordern würden. Sie nennen das oft „Stealth-Modus“ und behaupten, dass es irgendwie eine Sicherheitsfunktion ist.)

² Für Traceroute gibt es keinen dedizierten Pakettyp. Die Tools senden einfach alles, was wahrscheinlich eine Antwort vom Endhost erzeugt, ohne echte Dienste zu verwirren. Dazu gehört ICMP-Echo, aber auch UDP-Pakete auf hohen Ports und sogar TCP-SYNs.