感谢支持
我们一直在努力

结合tcpdump命令对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

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

Linux下Tmux与tcpdump使用总结  http://www.linuxidc.com/Linux/2015-09/122775.htm

Linux系统安全工具之tcpdump  http://www.linuxidc.com/Linux/2014-10/107889.htm

Linux系统入门学习:如何使用tcpdump来捕获TCP SYN,ACK和FIN包  http://www.linuxidc.com/Linux/2014-10/107722.htm

Linux运维工程师利器:Nmap和tcpdump http://www.linuxidc.com/Linux/2014-02/96993.htm

tcpdump的用法及使用案例 http://www.linuxidc.com/Linux/2013-11/93200.htm

Linux下实现 tcpdump http://www.linuxidc.com/Linux/2013-08/88775.htm

Linux操作系统tcpdump抓包分析详解 http://www.linuxidc.com/Linux/2013-07/87309.htm

本文永久更新链接地址:http://www.linuxidc.com/Linux/2016-03/129546.htm

赞(0) 打赏
转载请注明出处:服务器评测 » 结合tcpdump命令对traceroute深入分析
分享到: 更多 (0)

听说打赏我的人,都进福布斯排行榜啦!

支付宝扫一扫打赏

微信扫一扫打赏