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

21

我有一个IP地址，可以跟踪到该地址，但是无法ping通。

你看，我可以traceroute 43.224.226.50：

dele-MBP:~ ll$ traceroute 43.224.226.50
traceroute to 43.224.226.50 (43.224.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.95.128.2 (212.95.128.2)  565.161 ms *
13  43.224.226.50 (43.224.226.50)  200.531 ms  201.911 ms  191.566 ms

但我不能ping它：

dele-MBP:~ ll$ ping 43.224.226.50
PING 43.224.226.50 (43.224.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则两者也不起作用。是什么原因呢？

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

ping  networking  icmp  traceroute 
— 244男孩
source
可能是因为ping超时限制太严格了，并且在更宽松的时间限制下它会成功吗？Traceroute为某些节点提供了500毫秒以上的时间。
— vsz

Answers:

39

在类似的问题上，卢克·萨维奇（Luke Savage）完美地解释了它：

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

主要实现有两种：

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

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

了解这两者之间的区别非常有用，因为某些网络默认情况下现在会阻止ICMP，因此Windows计算机的PING和tracert都将失败，但是Linux设备的traceroute仍然可以工作。

— 朴素RSA
source
2
那么，为什么我的服务器IP可以跟踪路由却不能ping？
— 244boy
10
从您的共享输出中，我可以看到您正在使用traceroute命令，而没有看到，tracert这使我认为您使用的是基于Unix或gnu的操作系统。在我提到的答案中，您可以看到基于UNIX的系统未ICMP用于traceroute。换句话说，由于PING使用ICMP（我想这是您要达到系统阻塞）和traceroute使用UDP具有的增量方法分组TTL域（我认为这是不挡在你试图达到系统）PING失败但Traceroute成功。
— naïveRSA
4
当像244boy这样的人提出改进建议时，与其在您的帖子中添加新评论，不如对您的帖子进行编辑，以使将来阅读答案的人不必阅读所有评论即可获得完整答案。
— Keeta-恢复莫妮卡
@naïveRSA严格来说，即使它正在发送 UDP，也traceroute正在使用 ICMP，即它期望并评估途中的跃点中的消息。阻止所有 ICMP的主机是一个坏主意，但是当目标主机阻止请求或答复时，该区域将失败 TTL exceededpingICMP echo
— Hagen von Eitzen
17

要添加到@naïveRSA的答案，如果路径中存在过滤/防火墙，则也可能会出现以下情况：ICMP“回显应答”（ping）数据包被阻止，但允许ICMP“ time over”（tracert）数据包。即使仅使用ICMP（Windows），也会产生相同的结果。

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

— Arjan
source
6

让我们看看会发生什么，对吧？

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数据包。

什么是不可见在此跟踪（虽然这将是，如果我给tcpdump一个-v增加冗长）是第一探头具有1的TTL，然后它增加了以后探针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是有问题的：例如，它中断了路径MTU发现，这依赖于ICMP分段所需的错误。ICMP数据包具有类型和代码，负责任的网络运营商将仅选择性地阻止某些类型或代码，这些类型或代码可能会造成滥用或泄露特定信息。

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

当许多主机将UDP数据报或TCP SYN传送到没有进程监听的端口时，它们也不会发送ICMP端口不可达错误，这会中断traceroute。再次的想法是使攻击者更难以映射网络，但这对攻击者而言只是一个小小的挫败。

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

不幸的是，这些选项可能需要root或特殊功能，因此UDP做出了合理的默认设置。实际上，类似的工具tracepath在其手册页中有这样的说法：

描述

它沿着该路径跟踪发现目标MTU的路径。它使用UDP端口端口或一些随机端口。它类似于traceroute，仅不需要超级用户特权，也没有任何高级选项。

— 菲尔·弗罗斯特
source
2

TLDR；可以在远程主机上阻止ping（ICMP阻止），但traceroute仍可以使用标准网络路由UDP或TCP / IP（实际上是任何协议；请参阅/networkengineering//a/36509/）找到到它的路由58968）。请注意，您的ping也有可能到达主机（除非您有一个非常智能的防火墙在某处阻止了ICMP ping流量），主机只是不回复。

— 罗尔·范德帕尔
source
0

对于您的问题的简短回答是，该ping实用程序依赖于ICMP协议，该协议有时在网络防火墙或设备本身的防火墙处被阻止。网络管理员阻止ICMP的最常见原因是为了防止对他们认为是安全问题的网络进行“扫描”。tracerouteLinux上的实用程序使用UDP，这是一种完全不同的协议，在这种情况下，不会被网络管理员阻止。UDP有多种用途，阻止它会导致许多事情在网络上不可用。所需的ICMP“控制消息”类型ping是协议的子集，这意味着阻止该类型的ICMP数据包在网络上引起的问题较少，因此与UDP相比，更有可能被阻止。

— 赛博
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.