linux ip包路由超时,结合tcpdump命令对traceroute深入分析(示例代码)

昨天突然被问到traceroute的原理，一时竟也说不出来，有些命令平时虽然经常在用，但实际原理确并不了解，趁这次机会就来梳理一下。

traceroute：是网络诊断中，用来分析IP包经过那些路由的命令。

学前知识：

IP包中有个字段TTL，这个是最大跳转次数的字段，每经过一个路由器，值会-1，当值为0的时候，这个包就会被路由器丢弃，并返回ICMP-超时包给请求主机。

实现原理：

1、traceroute首先发出三个UDP包(发出三个主要是为了统计，这里可以不用太在意)，其TTL的字段为1，目的地为目标主机的IP，该UDP包在经过路由器-1时，TTL值会被设置为0该包会被丢弃，并返回ICMP-超时给请求主机；

2、在收到路由器1发来的"ICMP-超时"包时，traceroute会继续发出三个UDP包，其TTL的字段被设置为2，该UDP包顺利的经过了路由器-1，在到达路由器-2时，TTL值被值为0，随之丢弃，返回ICMP-超时包给请求主机；

…………继续重复，每收到一个返回ICMP-超时的包，则继续发出TTL值+1的UDP包；

3、就这样，在经历了4个路由器后，TTL=5的UDP包，历经千山万水，终于来到了目的主机，大家可能会觉得目的主机会欣然接受这个UDP包，但实际不是，目的主机做了如下的处理：

丢弃(不认识你，狗带)

返回ICMP-目标不可达包给请求主机

大家可能觉得很奇怪，为什么会被丢弃呢？简单的说一下，就是主机没有监听该UDP端口的进程。

4、请求主机的traceroute程序，在收到ICMP-目标不可达包后，终于心满意足的结束工作了。

下面为了加深一下印象，结合tcpdump命令，对traceroute过程进行一些验证

主要观察过程中[发出的UDP包] [路由器返回的ICMP-超时包] [目的主机返回的ICMP-目标不可达包]

1、使用命令，监听目的主机相关的包

tcpdump -i eno33554984 -vvnn host 119.146.184.98

2、使用traceroute命令对目的主机发起请求

[[email protected] ~]#traceroute 119.146.184.98traceroute to119.146.184.98 (119.146.184.98), 30 hops max, 60 bytepackets1 192.168.0.1 (192.168.0.1) 2.217 ms 1.741 ms 1.509ms2 116.24.132.1 (116.24.132.1) 11.348 ms 11.117 ms 11.287ms3 113.106.47.93 (113.106.47.93) 7.111 ms 6.848 ms 7.123ms4 5.107.38.59.broad.fs.gd.dynamic.163data.com.cn (59.38.107.5) 6.921 ms 6.712 ms 6.434ms5 183.59.12.153 (183.59.12.153) 8.635 ms 7.664 ms 7.593ms6 183.61.222.102 (183.61.222.102) 11.923 ms 10.220 ms 9.423ms7 119.146.184.198 (119.146.184.198) 15.779 ms 119.146.184.94 (119.146.184.94) 47.902 ms 119.146.184.62 (119.146.184.62) 16.571ms

####################################

#返回结果解释：

#列1：[1] 经过的路由器序号；

#列2：[192.168.0.1] 路由器IP(也叫网关)；

#列3：[(113.106.47.93) ] 即括号内的内容，具体用途不明，有懂的可以解释一下哈；

#列4：[7.111ms] 返回的时间，这里也可以发现，一共有3个时间，还想起来吗？traceroute每次发出的UDP包都是3个一起发的；

需要注意的是，大家可以看到最后一列，是有3个地址的，其实也不难理解，路由器是会根据实际情况寻找合适的路径；

3、现在来看看tcpdump采集的结果，观察由请求主机发出的UDP包

18:56:27.892318 IP (tos 0x0, ttl 1, id 10584, offset 0, flags [none], proto UDP (17), length 60)192.168.0.200.39914 > 119.146.184.98.33434: [bad udp cksum 0xf19e -> 0xfaae!] UDP, length 32

18:56:27.892798 IP (tos 0x0, ttl 1, id 10585, offset 0, flags [none], proto UDP (17), length 60)192.168.0.200.38541 > 119.146.184.98.33435: [bad udp cksum 0xf19e -> 0x000b!] UDP, length 32

18:56:27.893869 IP (tos 0x0, ttl 1, id 10586, offset 0, flags [none], proto UDP (17), length 60)

####################################

#返回结果解释：

#可以看到我们的主机，往119.146.184.98发出TTL=1的UDP包，而且是三个；这里大家可以奇怪，不是说经过的网关会返回ICMP-超时的包吗？为啥没看到呢？

#为什么呢？

#因为ICMP-超时这个包，不是119.146.184.98返回的，那是谁返回的呢？回忆一下上文！是路由器！所以这里我们需要使用tcpdump指定路由器的ip来抓包。

4、观察路由器返回的ICMP-超时包

tcpdump -i eno33554984 -vvnn host 116.24.132.1#温馨提示：执行完这个命令后，你需要重新执行traceroute119.146.184.98命令才能进一步观察116.24.132.1返回的包哦19:02:26.210530 IP (tos 0xc0, ttl 254, id 52121, offset 0, flags [none], proto ICMP (1), length 56)116.24.132.1 > 192.168.0.200: ICMP time exceeded in-transit, length 36IP (tos0x0, ttl 1, id 10619, offset 0, flags [none], proto UDP (17), length 60)192.168.0.200.43604 > 119.146.184.98.33437: UDP, length 32####################################

#返回结果解释：

#这里我们选择了采集第二跳的路由器地址116.24.132.1的数据包(为什么不用第一跳呢？因为第一跳往往是自己家里的路由器地址，这个地址的包会非常多，不容易观察到实验#结果)

#从返回的结果中，我们可以看到第二跳路由器确实返回ICMPtime exceeded包，实际上会有3个，就不一一列举了。

5、观察目的主机返回的ICMP-目标不可达包

#在 [[email protected] ~/test_traceroute]#tcpdump -i eno33554984 -vvnn host 119.146.184.98命令返回的结果中查看18:56:27.972224 IP (tos 0x0, ttl 248, id 20689, offset 0, flags [none], proto ICMP (1), length 56)119.146.184.98 > 192.168.0.200: ICMP 119.146.184.98 udp port 33455 unreachable, length 36IP (tos0x0, ttl 2, id 10605, offset 0, flags [none], proto UDP (17), length 60)192.168.0.200.56215 > 119.146.184.98.33455: UDP, length 32####################################

#返回结果解释：

#在返回结果中最后的地方可以看到ICMP119.146.184.98 udp port 33455 unreachable的字样。

最后再总结一下traceroute常见返回结果的分析:

1、大家在练习的时候，可能第一个想到的就是拿一些知名网站来测试，下面我们就拿百度的一个ip地址来测试

[[email protected] ~]#traceroute -m 10 14.215.177.38traceroute to14.215.177.38 (14.215.177.38), 10 hops max, 60 bytepackets1 192.168.0.1 (192.168.0.1) 2.395 ms 2.063 ms 1.583ms2 116.24.132.1 (116.24.132.1) 36.296 ms 36.939 ms 36.706ms3 183.56.71.225 (183.56.71.225) 6.550 ms 6.304 ms 6.396ms4 183.56.66.93 (183.56.66.93) 5.716 ms 5.491 ms 5.713ms5 183.56.64.50 (183.56.64.50) 8.059 ms 7.733 ms 7.513ms6 * * *

7 14.29.121.194 (14.29.121.194) 9.082 ms 14.29.121.198 (14.29.121.198) 8.977 ms 14.29.121.206 (14.29.121.206) 9.700ms8 * * *

9 * * *

10 * * *####################################

返回结果解释：*号代表发出去的UDP没有收到相应的ICMP-超时包，这个主要是因为某些路由器安全原因，拒绝返回ICMP-超时包。

所以大家可以看到第六跳的记录都是*号，说明，第六跳的路由器没有返回ICMP-超时包。

同时存在如下一点疑问：

为什么traceroute没有结束，一直不断的检测呢？(我们在命令中指定检测10跳的参数)，如果你有耐心，可以指定-m 128参数，会发现traceroute始终无法自动结束，每次都需要耗尽所有的检测次数。

2、那么，为什么8 9 10跳返回的也是*呢？这里合理推测一下：

我所在的网络，访问百度这个网站，至少需要7跳才能到达，在第七条以后，TTL=8的UDP包可能已经到达百度的主机，那么为什么traceroute没有结束呢？

一个合理的推测，就是百度14.215.177.38这个主机直接丢弃了我们的UDP包，拒绝返回ICMP-目标不可达包；

由于traceroute一直没有收到ICMP-目标不可达包，所以他会一直生成UDP包，并增加TTL的值发出，直到达到我们指定的检测跳数(本例中，我们指定的跳数=10)。

大家也可以使用如下命令

[[email protected] ~/test_traceroute]#tcpdump -i eno33554984 -vvnn host 14.215.177.38

这个命令可以采集到14.215.177.38的相关包，可以看到只有发出去的包，没有返回的包，也基本可以验证我们的推测。