结合tcpdump命令对traceroute深入分析
2024-12-18 03:43:43 来源: 阅读:
昨天突然被问到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命令对目的主机发起请求
[root@www ~]#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-目标不可达包
#在 [root@www ~/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地址来测试
[root@www ~]#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）。
- 大家也可以使用如下命令
[root@www ~/test_traceroute]#tcpdump -i eno33554984 -vvnn host 14.215.177.38