我最近正在对网络连接性元问题进行故障排除,因为我知道给定的目标是可以到达的,但是我无法通过traceroute来证明这一点,因为经过一定的跳数后路径变冷了。鉴于观察到的最后一个跃点刚好在感兴趣的节点的上游,我嗅探了流量,希望确认探针正在到达该流量,并了解哪个过滤器规则正在阻止它们。果然,我了解到这些探针是发往高端口(且不断变化)的UDP数据报,我当然将其阻止入站流量。

这让我感到惊讶,因为我认为所有traceroute探测将默认为ICMP,因为响应为ICMP。我进行了一次文档调查,发现不同的实现会做出不同的选择,有些不允许用户进行非默认选择。


UDP

思科
Linux
FreeBSD


ICMP

瞻博网络
Brocade
Windows




Traceroute探测方法和前向IP路径推断的摘要支持我的直觉,即ICMP探测将更常成功到达目的地。

允许使用不同的探测方法似乎是一种这个好主意,但是默认使用ICMP以外的东西似乎是个坏主意。有人可以说明为什么默认情况下使用UDP更好的原因吗?

#1 楼

traceroute的第一版是由Van Jacobson编写的,它使用了ICMP,但效果不是很好。供应商对RFC792中ICMP的解释是,路由器不应响应ICMP数据包而发送ICMP错误消息(请参见下面的编辑说明)。因此,大多数路由器不会响应TTL为1或0的回显请求而发送“超时”消息。因此,他将其更改为使用UDP和lo,并认为它工作得很好,并且倍受欣喜(和采用)。 Linux和FreeBSD(我假设为Cisco)上的traceroute工具基于Van Jacobson的工作。

该规范后来更改为“响应ICMP错误包”。世界进步了,供应商对其堆栈进行了更改,以允许ICMP错误消息响应回显请求,并且随着防火墙和ACL的兴起,有时会阻止杂散UDP数据包,但ICMP回显请求可以通过。当然,您今天所取得的成功千差万别。我希望tracert和其他工具是在使用ICMP回显响应不是那么麻烦的时候编写的。还是那些都比TCP更好。这完全取决于您遍历的路径和适当的安全策略。您可能需要尝试一个,两个或所有三个实现。

来源:

http://ftp.arl.army.mil/~mike/ping.html
http://www.inetdaemon.com/tutorials/troubleshooting/tools/traceroute/definition.shtml

编辑:

从IP(RFC791)更改RFC到在简介中说的ICMP(RFC792):


为了避免消息等消息的无限回归,不发送有关ICMP消息的ICMP
消息。 />

这是导致供应商不发送回声请求“超时”错误的原因。是表示主机不应响应ICMP错误消息的更新。

评论


仅供参考,现在您已经有足够的声誉,可以就您通过电子邮件发送给我的问题发表评论

–迈克·彭宁顿
2014年6月9日在11:41

做得好。我特别喜欢第一个链接中有关计算机大喊“ Ping!Ping!Ping!”的故事。在其肺的顶部。

–neirbowj
2014年6月9日15:57

迈克,是的,我开始了解这个网站的运作方式了:-)

–karyhead
2014年6月9日在16:24