结合tcpdump命令对traceroute深入分析

Posted 2020-06-29 NienSun

昨天突然被问到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.98
traceroute to 119.146.184.98 (119.146.184.98), 30 hops max, 60 byte packets
 1  192.168.0.1 (192.168.0.1)  2.217 ms  1.741 ms  1.509 ms
 2  116.24.132.1 (116.24.132.1)  11.348 ms  11.117 ms  11.287 ms
 3  113.106.47.93 (113.106.47.93)  7.111 ms  6.848 ms  7.123 ms
 4  5.107.38.59.broad.fs.gd.dynamic.163data.com.cn (59.38.107.5)  6.921 ms  6.712 ms  6.434 ms
 5  183.59.12.153 (183.59.12.153)  8.635 ms  7.664 ms  7.593 ms
 6  183.61.222.102 (183.61.222.102)  11.923 ms  10.220 ms  9.423 ms
 7  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.571 ms
####################################
#返回结果解释：
#列1：[1] 经过的路由器序号；
#列2：[192.168.0.1 ] 路由器IP（也叫网关）；
#列3：[(113.106.47.93) ] 即括号内的内容，具体用途不明，有懂的可以解释一下哈；
#列4：[7.111 ms] 返回的时间，这里也可以发现，一共有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
#温馨提示：执行完这个命令后，你需要重新执行traceroute 119.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 36
IP (tos 0x0, 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的数据包（为什么不用第一跳呢？因为第一跳往往是自己家里的路由器地址，这个地址的包会非常多，不容易观察到实验#结果）
#从返回的结果中，我们可以看到第二跳路由器确实返回ICMP time 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 36
        IP (tos 0x0, 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
####################################
#返回结果解释：
#在返回结果中最后的地方可以看到ICMP 119.146.184.98 udp port 33455 unreachable的字样。

 

---

 

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

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

[[email protected] ~]#traceroute -m 10 14.215.177.38
traceroute to 14.215.177.38 (14.215.177.38), 10 hops max, 60 byte packets
 1  192.168.0.1 (192.168.0.1)  2.395 ms  2.063 ms  1.583 ms
 2  116.24.132.1 (116.24.132.1)  36.296 ms  36.939 ms  36.706 ms
 3  183.56.71.225 (183.56.71.225)  6.550 ms  6.304 ms  6.396 ms
 4  183.56.66.93 (183.56.66.93)  5.716 ms  5.491 ms  5.713 ms
 5  183.56.64.50 (183.56.64.50)  8.059 ms  7.733 ms  7.513 ms
 6  * * *
 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.700 ms
 8  * * *
 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的相关包，可以看到只有发出去的包，没有返回的包，也基本可以验证我们的推测。