主页 / computer / 问题 / 1620938
Accepted
Frank van Wensveen
Asked: 2021-01-27 07:15:37 +0800 CST

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

  • 772

在尝试对存在不稳定网络问题的 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  * * *
$

是什么导致了这种差异，它是否有任何意义？

windows-10 traceroute

1 个回答

  1. Best Answer

    这不是同一个跟踪路由。Linuxtraceroute实际上默认发送 UDP 探测，而不是像 Windows 那样发送 ICMP Echo。用于sudo traceroute --icmp获得更接近 Windows 的东西。mtr（当你在它的时候尝试一下。）

    如果最终系统有防火墙悄悄丢弃未知端口1上的 UDP 数据包，则没有响应意味着 traceroute 程序将无法知道它们去了哪里，实际上也无法识别探针最终到达了最终目的地，并且没有必要继续探测越来越大的 TTL。

    1任何类型的 traceroute 探测2都会发生同样的情况，但丢弃 UDP 比丢弃 ICMP Echo 更常见。（它甚至不必是一个故意的阻止——一些操作系统只是默认这样做，忽略 UDP 甚至 TCP，当标准要求 ICMP 端口不可达时保持安静。他们通常称之为“隐形模式”和声称它是某种安全功能。）

    2 traceroute没有专门的包类型；这些工具只发送可能从最终主机产生响应的任何内容，而不会混淆任何实际服务——这包括 ICMP Echo，还包括高端口上的 UDP 数据包，甚至 TCP SYN。

    • 3

相关问题