为什么我可以跟踪路由到这个 IP 地址，但不能 ping？

网络工程 平 联网 国际会议 跟踪路由
2021-07-25 13:56:37

我有一个 IP 地址并且可以跟踪路由到它，但我无法 ping。

你看，我可以跟踪路由43.24.226.50：

dele-MBP:~ ll$ traceroute 43.24.226.50
traceroute to 43.24.226.50 (43.24.226.50), 64 hops max, 52 byte packets
 1  router.asus.com (192.168.2.1)  2.082 ms  1.039 ms  0.924 ms
 2  100.64.0.1 (100.64.0.1)  3.648 ms  3.795 ms  3.955 ms
 3  118.112.212.225 (118.112.212.225)  4.252 ms  4.569 ms  4.168 ms
 4  171.208.203.73 (171.208.203.73)  6.378 ms
    171.208.198.25 (171.208.198.25)  6.943 ms
    171.208.203.61 (171.208.203.61)  7.055 ms
 5  202.97.36.225 (202.97.36.225)  38.149 ms
    202.97.36.221 (202.97.36.221)  39.949 ms
    202.97.36.225 (202.97.36.225)  40.780 ms
 6  202.97.90.158 (202.97.90.158)  37.894 ms
    202.97.94.146 (202.97.94.146)  39.885 ms  39.354 ms
 7  202.97.38.166 (202.97.38.166)  45.324 ms
    202.97.39.149 (202.97.39.149)  40.097 ms
    202.97.94.77 (202.97.94.77)  40.580 ms
 8  202.97.51.118 (202.97.51.118)  374.218 ms
    202.97.27.238 (202.97.27.238)  187.573 ms
    202.97.86.138 (202.97.86.138)  197.524 ms
 9  218.30.53.190 (218.30.53.190)  201.597 ms
    218.30.54.190 (218.30.54.190)  194.194 ms
    218.30.53.190 (218.30.53.190)  204.027 ms
10  182.54.129.91 (182.54.129.91)  220.026 ms  282.360 ms
    et-11-1-5.r01.laxus01.us.bb.bgp.net (182.54.129.38)  185.700 ms
11  182.54.129.91 (182.54.129.91)  229.700 ms  508.509 ms  266.683 ms
12  * 212.5.128.2 (212.5.128.2)  565.161 ms *
13  43.24.226.50 (43.24.226.50)  200.531 ms  201.911 ms  191.566 ms

但我无法ping通它：

dele-MBP:~ ll$ ping 43.24.226.50
PING 43.24.226.50 (43.24.226.50): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11

如果禁止ICMP，traceroute也不应该起作用。这是什么原因？

我检查了服务器的防火墙是否已停止。

4个回答

在一个类似的问题上， Luke Savage 完美地解释了它：

Traceroute 本身不是协议，它是一个应用程序，使用的协议取决于您使用的实现。这主要是ICMP。

主要有两种实现方式：

tracert - tracert 是一个 Windows 应用程序，它利用 ICMP 数据包和递增的 TTL 字段将跃点映射到最终目标地址。

traceroute - traceroute 是一个 *nix 应用程序，可用于大多数基于 Linux 的系统，包括网络设备和 Cisco 设备。这使用带有递增 TTL 字段的 UDP 数据包将跃点映射到最终目的地。

了解它们之间的区别很有用，因为某些网络现在默认阻止 ICMP，因此来自 Windows 机器的 PING 和 tracert 都将失败，但来自 Linux 设备的 traceroute 可能仍然有效。

从您的共享输出中，我可以看到您正在使用traceroute命令，而不是tracert让我认为您使用的是基于Unix或GNU的操作系统。在我提到的答案中，您可以看到基于 Unix 的系统没有使用ICMPfor traceroute. 换句话说，由于PING正在使用ICMP（我认为它被您试图访问的系统阻止）并且traceroute正在使用UDP具有TTL字段增量方法的数据包（我认为它在您试图访问的系统中没有被阻止）PING失败但是Traceroute成功

要添加到@naïveRSA的答案中，如果路径中有过滤/防火墙，也可能会出现 ICMP“回显回复”（ping）数据包被阻止，但允许 ICMP“超时”（跟踪）数据包的情况. 即使仅使用 ICMP (Windows)，这也会产生相同的结果。

在这两种情况下（发送方使用 UDP 或 ICMP），错误通信都将是 ICMP（即节点回复 ping 或 tracer* 数据包）。

让我们看看会发生什么，好吗？

8.8.8.8 是一个很好的例子，因为至少从我的位置，我可以使用traceroute和到达它ping。

首先让我们试着ping 8.8.8.8看看会发生什么：

$ tcpdump -n host 8.8.8.8 or icmp
15:36:51.045994 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 0, length 64
15:36:51.062458 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 0, length 64
15:36:52.048350 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 1, length 64
15:36:52.073657 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 1, length 64

所以ping发送一个 ICMP 回声请求，并期待一个 ICMP 回声回复。

现在traceroute -n 8.8.8.8：

15:41:31.803324 IP 10.4.27.179.44838 > 8.8.8.8.33435: UDP, length 24
15:41:31.815184 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.815343 IP 10.4.27.179.44838 > 8.8.8.8.33436: UDP, length 24
15:41:31.819654 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.819791 IP 10.4.27.179.44838 > 8.8.8.8.33437: UDP, length 24
15:41:31.824609 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.824754 IP 10.4.27.179.44838 > 8.8.8.8.33438: UDP, length 24
15:41:31.830506 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.830649 IP 10.4.27.179.44838 > 8.8.8.8.33439: UDP, length 24
15:41:31.834469 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.834565 IP 10.4.27.179.44838 > 8.8.8.8.33440: UDP, length 24
15:41:31.840962 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.841061 IP 10.4.27.179.44838 > 8.8.8.8.33441: UDP, length 24
15:41:31.847440 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.847634 IP 10.4.27.179.44838 > 8.8.8.8.33442: UDP, length 24
15:41:31.853664 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.853761 IP 10.4.27.179.44838 > 8.8.8.8.33443: UDP, length 24
15:41:31.859221 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.859269 IP 10.4.27.179.44838 > 8.8.8.8.33444: UDP, length 24
15:41:31.864149 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.864192 IP 10.4.27.179.44838 > 8.8.8.8.33445: UDP, length 24
15:41:31.870843 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.870922 IP 10.4.27.179.44838 > 8.8.8.8.33446: UDP, length 24
15:41:31.876200 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.876352 IP 10.4.27.179.44838 > 8.8.8.8.33447: UDP, length 24
15:41:31.882148 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.882249 IP 10.4.27.179.44838 > 8.8.8.8.33448: UDP, length 24
15:41:31.890076 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.890156 IP 10.4.27.179.44838 > 8.8.8.8.33449: UDP, length 24
15:41:31.896100 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.896163 IP 10.4.27.179.44838 > 8.8.8.8.33450: UDP, length 24
15:41:31.905037 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.905235 IP 10.4.27.179.44838 > 8.8.8.8.33451: UDP, length 24
15:41:31.913206 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.913283 IP 10.4.27.179.44838 > 8.8.8.8.33452: UDP, length 24
15:41:31.923428 IP 108.170.242.241 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.923520 IP 10.4.27.179.44838 > 8.8.8.8.33453: UDP, length 24
15:41:31.932266 IP 108.170.237.9 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.932441 IP 10.4.27.179.44838 > 8.8.8.8.33454: UDP, length 24
15:41:31.939961 IP 209.85.251.9 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.940043 IP 10.4.27.179.44838 > 8.8.8.8.33455: UDP, length 24
15:41:31.947460 IP 108.170.237.21 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.947508 IP 10.4.27.179.44838 > 8.8.8.8.33456: UDP, length 24
15:41:31.954824 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33456 unreachable, length 36
15:41:31.954888 IP 10.4.27.179.44838 > 8.8.8.8.33457: UDP, length 24
15:41:31.963601 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33457 unreachable, length 36
15:41:31.963671 IP 10.4.27.179.44838 > 8.8.8.8.33458: UDP, length 24
15:41:31.972407 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33458 unreachable, length 36

因此traceroute，至少我安装的实现不会发送 ICMP。相反，它发送 UDP 数据包。

在此跟踪中不可见的（尽管如果我给出tcpdumpa-v以增加详细程度）是第一个探测器的 ttl 为 1，然后它会为以后的探测器增加 ttl。这会导致我和 8.8.8.8 之间的路由器响应 ICMP ttl 超出错误，这就是 traceroute 发现这里和那里之间的路由器的方式。

最终 ttl 足够长以使其一直到达 8.8.8.8，并且 8.8.8.8 以 ICMP 端口不可达错误响应，因为它没有进程侦听 UDP 端口 44838。这就是 traceroute 知道它已到达最终目的地的方式.

如果这里和那里之间的某些东西阻塞了所有ICMP，那么 ping 和 traceroute 都将不起作用。

但通常情况下并非所有ICMP 都被阻止，尽管这种情况并不少见。阻止所有 ICMP 是有问题的：例如，它会破坏依赖于 ICMP 分段所需错误的路径 MTU 发现。ICMP 数据包具有类型和代码，负责任的网络运营商只会选择性地阻止某些类型或代码，这些类型或代码可能会造成滥用或泄露特定信息。

例如，某些主机根本不会响应 ICMP 回显请求，因此 ping 将不起作用。这个想法是，通过不响应 ping，攻击者更难发现网络上存在哪些主机。实际上，这是有问题的，因为还有其他方法可以探测主机。例如，可以向端口 80 发送 TCP SYN 以查找网络服务器。

许多主机在将 UDP 数据报或 TCP SYN 发送到没有进程侦听的端口时也不会发送 ICMP 端口不可达错误，这会破坏跟踪路由。同样的想法是让攻击者更难映射网络，但这对攻击者来说只是一个小小的挫折。

因为 traceroute 是一个程序而不是任何特定的协议，所以它有其他探测方式。它们都依赖于增加 TTL 来发现路由器，但是可以发送不同类型的探测，这些探测可能或多或少有机会从端点引出响应。例如，我man tcpdump列出了一个-I使用 ICMP 回声探测的选项，与 ping 相同。它还必须-T使用 TCP SYN 探测而不是 UDP。如果您知道主持人会做出回应，ping那就-I很有意义了。如果您知道主机正在侦听特定的 TCP 端口，那么-T可能与-p选择端口的选项结合使用是有道理的。

不幸的是，这些选项可能需要 root 或特殊功能，因此 UDP 是一个公平的默认值。事实上，一个类似的工具 ，tracepath在其手册页中是这样说的：

描述

它跟踪到目的地的路径，沿着这条路径发现 MTU。它使用UDP端口端口或一些随机端口。它类似于 traceroute，只是不需要超级用户权限，也没有花哨的选项。

TLDR；ping 可以在远程主机上被阻止（ICMP 块），但 traceroute 仍然可以使用标准网络路由 UDP 或 TCP/IP（任何协议真正找到它的路由；参考https://networkengineering.stackexchange.com/a/36509/ 58968）。请注意，您的 ping 可能也可以到达主机（除非您有一个非常聪明的防火墙阻止了 ICMP ping 流量），主机只是不回复。

其它你可能感兴趣的问题
上一篇为什么 DHCP 使用 UDP 而不是 TCP？ 下一篇为什么要结合使用 SSH 和 VPN？