☰

Linux (4.15.0-130) 和 Windows (10) 對待 ICMP 的方式不同嗎？

tag-icon • tag-icon windows-10 traceroute icmp
Linux (4.15.0-130) 和 Windows (10) 對待 ICMP 的方式不同嗎？

在嘗試對具有不穩定網路問題的 Windows 10 電腦進行故障排除時，我對主機進行了追蹤路由，得到的結果與我在核心為 4.15.0-130 的 Ubuntu 18.04 系統上看到的結果有些不同。為了消除硬體因素、不穩定的協定堆疊、驅動程式問題等，我將執行 Linux 的 VirtualBox VM 中的 Windows 10 與主機系統提供的內容進行了比較。 VirtualBox 已設定 NAT，即 Windows 10 連接到主機，然後由主機處理實際的網路 I/O。因此，兩個會話都使用相同的網路適配器，並且所有內容都透過主機上的相同協定堆疊進行。不涉及VPN；客戶端電腦只是掛在 WiFi/3G 互聯網路由器上。

我正在追蹤路由的主機可以從 Linux（使用 Firefox 網路瀏覽器）訪問，但不能從 Windows 10 存取（在另一台使用 Firefox 的 Windows 10 電腦上或在使用 Chrome 的 VirtualBox 中）。

Windows（在 Linux 上的 Virtual Box 中運行）給了我：

>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.

（注意：10.0.2.2 是VitualBox 提供的預設網關位址；Linux 處理從那裡開始的所有網絡，因此該躍點不會出現在下面的追蹤路由中。）使用Linux 重複相同的追蹤路由（在運行Virtual Box的同一系統上）包含上述 Windows 10 的會話）給了我：

$ 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  * * *
$

是什麼導致了這種差異？

答案1

這不是同一個追蹤路由。 Linuxtraceroute實際上會預設發送 UDP 探測，而不是像 Windows 那樣發送 ICMP Echo。用於sudo traceroute --icmp獲得更接近 Windows 的東西。 （mtr當你在做的時候嘗試一下。）

如果最終系統有一個防火牆悄悄地丟棄未知連接埠1上的 UDP 封包，則缺乏回應意味著 Traceroute 程式將無法知道它們去了哪裡，並且實際上無法識別探測是否已最終到達最終目的地目的地，並且沒有必要不斷探測越來越大的TTL。

1任何類型的追蹤路由探測都會發生同樣的情況2，但丟棄 UDP 比丟棄 ICMP Echo 更為常見。 （它甚至不必是故意的阻止 - 某些作業系統只是默認執行此操作，忽略 UDP 甚至 TCP，當標準要求 ICMP 連接埠不可達時保持安靜。他們通常將此稱為「隱形模式」聲稱這是某種安全功能。

2 Traceroute沒有專用的資料包類型；這些工具只是發送可能從最終主機產生回應的任何內容，而不會混淆任何實際服務 - 這包括 ICMP Echo，但也包括高連接埠上的 UDP 封包，甚至是 TCP SYN。

相關內容