Traceroute手册翻译+特殊案例分析

TRACEROUTE 手册翻译

简介

traceroute -- 打印网络数据包到网络主机的路由信息
复制代码

格式

traceroute [-adeFISdNnrvx] [-A as_server] [-f first_ttl] [-g gateway] [-i iface] [-M first_ttl] [-m max_ttl] [-P proto] [-p port] [-q nqueries] [-s src_addr] [-t tos] [-w waittime]
            [-z pausemsecs] host [packetsize]
复制代码

详细描述

• 互联网是一个庞大而复杂的网络硬件聚合体，经过网关链接在一块儿。跟踪单个数据包的路由路径（或找到那些丢弃你的数据包的恶意网关）可能很困难。因此traceroute利用IP协议“生存时间TTL”信息，尝试从每一个网关沿着到某个主机的路径引出"ICMP TIME_EXCEEDED响应"和具体路径。

• 惟一必需的参数是目标主机名或IP号。默认探测数据报长度为40个字节，但能够经过在目标主机名以后指定数据包大小（以字节为单位）来增长此值。

详细参数说明

-a      为每个跳跃节点开启AS#查询
    -A as_server    
            打开AS＃查找并使用给定的服务器而不是默认服务器。
    -d      启用socket调试
    -D      当收到对咱们的探测数据报的ICMP响应时，打印发送的数据包与ICMP响应引用的数据包之间的差别。打印一个显示传输数据包中字段位置的键，而后是十六进制的原始数据包，接着是十六进制的引用数据包。引用数据包中未更改的字节显示为下划线。注意，IP校验和和引用数据包的TTL预计不匹配。默认状况下，此选项仅发送每跳一个探测。
    -e      防火墙逃避模式。使用固定目标端口进行UDP和TCP探测。
    -f first_ttl
            设置第一个传出探测包中使用的初始生存时间。
    -F      设置“不分段”比特。
    -g gateway
            指定松散的源路由网关（最多8个）。
    -i iface
            指定网络接口以获取传出探测包的源IP地址。这一般仅适用于多宿主主机。（有关执行此操做的其余方法，请参阅-s参数。）
    -I      使用ICMP ECHO而不是UDP数据报。（等同于"-P icmp"）
    -M first_ttl
            设置传出探测包中使用的初始生存时间值。默认值为1，即从第一跳开始。
    -m max_ttl
            设置传出探测包中使用的最大生存时间（最大跳数）。默认值为net.inet.ip.ttl hops（与TCP链接相同的默认值）。
    -n      以数字方式而不是符号和数字方式打印跳跃地址（为路径上找到的每一个网关保存名称服务器地址到名称查找）。
    -P proto
            发送指定IP协议的数据包。当前支持的协议是：UDP，TCP，GRE和ICMP其余协议也能够指定（经过名称或编号），但traceroute不会实现其数据包格式的任何特殊知识。此选项对于肯定路径中的哪一个路由器可能会根据IP协议号阻止数据包颇有用。但请参阅下面的BUGS。
    -p port
            特定协议。对于UDP和TCP，设置探针中使用的基本端口号（默认为33434）。 traceroute但愿没有任何东西在UDP端口上监听目标主机上的base + nhops-1（所以将返回ICMP PORT_UNREACHABLE消息以终止路由跟踪）。若是某些内容正在侦听默认范围内的端口，则此选项可用于选择未使用的端口范围。
    -q nqueries
            将每一个“ttl”的探测次数设置为nqueries（默认为三个探测器）。
    -r      绕过正常的路由表并直接发送到链接网络上的主机。若是主机不在直接链接的网络上，则会返回错误。此选项可用于经过没有路由的接口ping本地主机（例如，在路由被路由（8）丢弃以后）
    -s src_addr
            使用src_addr（必须以IP号码，而不是主机名）做为传出探测数据包中的源地址。在具备多个IP地址的主机上，此选项可用于强制源地址不是发送探测数据包的接口的IP地址。若是IP地址不是本机的接口地址之一，则返回错误而且不发送任何内容。 （有关其余方法，请参阅-i标志。）
    -S      打印每一个跃点未应答的丢包率。
    -t tos  将探测包中的服务类型设置为如下值（默认为零）。 该值必须是0到255范围内的十进制整数。此选项可用于查看不一样类型的服务是否会产生不一样的路径。 （若是您没有运行4.4BSD或更高版本的系统，这多是学术性的，由于正常的网络服务，如telnet和ftp不容许您控制TOS）。 并不是全部TOS值都是合法或有意义的 - 请参阅IP规范以了解定义。 有用的值多是`-t 16'（低延迟）和`-t 8'（高吞吐量）。
    -v      详细输出。 列出了除TIME_EXCEEDED和UNREACHABLE以外的已接收ICMP数据包。
    -w      设置等待探测响应的时间（以秒为单位）（默认为5秒）。
    -x      切换IP校验和。 一般，这会阻止traceroute计算IP校验和。 在某些状况下，操做系统能够覆盖部分传出数据包，但不会从新计算校验和（所以在某些状况下，默认状况下不计算校验和，使用-x会致使计算校验和）。 请注意，使用ICMP ECHO探测器（-I）时，最后一跳一般须要校验和。 因此在使用ICMP时总会计算出它们。
    -z pausemsecs
            设置探针之间暂停的时间（以毫秒为单位）（默认为0）。 某些系统（如Solaris）和路由器（如Ciscos）限制ICMP消息。 与此一块儿使用的推荐值是500（例如1/2秒）。
复制代码

该程序试图经过启动具备比较小的小ttl（生存时间）的UDP探测包，而后侦听来自网关的ICMP超时信息回复来跟踪IP包在某一个特定因特网内的路由信息。咱们用一个ttl开始咱们的探测并每一跳都+1，直到咱们获得一个ICMP信息端口没法访问（这意味着咱们到达主机）或达到最大值（默认为net.inet.ip.ttl，固然这个值能够用-m标志改变）。在每一个ttl设置发送三个探针（能够用-q标志更改），并打印一行显示ttl+IP地址+每一个探测的网关和往返时间的信息。若是探测答案来自不一样的网关，则将打印每一个响应系统的地址。若是在5秒内没有响应。超时间隔（使用-w标志更改），为该探测器打印*。

一般咱们不但愿目标主机处理UDP探测数据包，因此traceroute会把目标端口设置为一个不太可能在用的端口值（若是目标上的某些clod使用该值，则可用-p标志改变）。

一个可能的示例使用和输出：

[yak 71]% traceroute nis.nsf.net.
 traceroute to nis.nsf.net (35.1.1.48), 64 hops max, 38 byte packet
 1  helios.ee.lbl.gov (128.3.112.1)  19 ms  19 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
 5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  39 ms  39 ms  39 ms
 6  128.32.197.4 (128.32.197.4)  40 ms  59 ms  59 ms
 7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  59 ms
 8  129.140.70.13 (129.140.70.13)  99 ms  99 ms  80 ms
 9  129.140.71.6 (129.140.71.6)  139 ms  239 ms  319 ms
 10  129.140.81.7 (129.140.81.7)  220 ms  199 ms  199 ms
 11  nic.merit.edu (35.1.1.48)  239 ms  239 ms  239 ms
复制代码

注意，第2和第3行是相同的。这是因为第二跳系统上的一个有缺陷的内核lbl-csam.arpa会转发零ttl的数据包（4.3 BSD的分布式版本中的错误）。因此要注意，您必须猜想数据包经过了哪些路径，由于NSFNet（129.140）不为其NSS提供地址到名称的转换。

下面是一个更有意思的案例:

[yak 72]% traceroute allspice.lcs.mit.edu.
 traceroute to allspice.lcs.mit.edu (18.26.0.115), 64 hops max
 1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  19 ms  19 ms
 3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  19 ms  39 ms  39 ms
 5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  20 ms  39 ms  39 ms
 6  128.32.197.4 (128.32.197.4)  59 ms  119 ms  39 ms
 7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  39 ms
 8  129.140.70.13 (129.140.70.13)  80 ms  79 ms  99 ms
 9  129.140.71.6 (129.140.71.6)  139 ms  139 ms  159 ms
 10  129.140.81.7 (129.140.81.7)  199 ms  180 ms  300 ms
 11  129.140.72.17 (129.140.72.17)  300 ms  239 ms  239 ms
 12  * * *
 13  128.121.54.72 (128.121.54.72)  259 ms  499 ms  279 ms
 14  * * *
 15  * * *
 16  * * *
 17  * * *
 18  ALLSPICE.LCS.MIT.EDU (18.26.0.115)  339 ms  279 ms  279 ms
复制代码

请注意，网关12,14,15,16和17跳要么不发送ICMP超时消息，要么发送它们的ttl过小而没法返回到用户主机。 14-17正在运行MIT C Gate-way代码。鬼知道12跳发生了啥。

上面的静音网关12多是4中的错误的结果。由于，对于网关，剩余的ttl为零的时候，ICMP超时信息必然不会返回给咱们。 当它出如今目标系统上时，此错误的行为会更有趣：

1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  39 ms
 3  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  39 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  19 ms
 5  ccn-nerif35.Berkeley.EDU (128.32.168.35)  39 ms  39 ms  39 ms
 6  csgw.Berkeley.EDU (128.32.133.254)  39 ms  59 ms  39 ms
 7  * * *
 8  * * *
 9  * * *
 10  * * *
 11  * * *
 12  * * *
 13  rip.Berkeley.EDU (128.32.131.22)  59 ms !  39 ms !  39 ms !
复制代码

请注意，有12个“网关”（13个是最终目的地），而且它们的后半部分彻底“丢失”。真正缘由的是rip（运行SunOS3.5的Sun-3）正在使用咱们到达的数据报中的ttl做为其ICMP回复中的ttl。所以，回复将在返回路径上超时（因为未发送ICMP，所以未向任何人发送通知ICMP），除非咱们使用至少两倍路径长度的ttl进行探测。 即，rip实际上只有7跳。 以ttl为1的返回信息是分析这个问题的线索。

traceroute在ttl <= 1以后会打出"!"。因为供应商提供了大量过期的（DEC的Ultrix，Sun 3.x）或非标准（HPUX）软件，若是不妥善选择探针主机则会常常看到这种问题。

原做者

由Van Jacobson先生在Steve Deering先生的提一下进行撰写。 而且由上千位开发者提出修改意见，特别是来自C. Philip Wood，Tim Seaver和Ken Adelman的修改意见。