你的位置:首页 > 操作系统

[操作系统]结合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命令对目的主机发起请求
[root@www ~]#traceroute 119.146.184.98traceroute 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 3218: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 3218: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 36IP (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.38traceroute 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

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