☰

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 访问（在其他 Windows 10 计算机上使用 Firefox 或在 VirtualBox 中使用 Chrome）。

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。

相关内容