tracerou1te经典详解.doc

一、什么是traceroute，什么是tcpdump？ 通过Traceroute我们可以知道信息从你的计算机到互联网另一端的主机是走的什么路径。当然每次数据包由某一同样的出发点（source）到达某一同样的目的地(destination)走的路径可能会不一样，但基本上来说大部分时候所走的路由是相同的。traceroute就是用来追踪出发点到目的地所经过的路径（路由器），UNIX系统中，我们称之为Traceroute,MS Windows中为Tracert。 TcpDump，用简单的话来定义tcpdump，就是：dump the traffice on a network，根据使用者的定义对网络上的数据包进行截获的包分析工具。作为互联网上经典的的系统管理员必备工具，tcpdump以其强大的功能，灵活的截取策略，成为每个高级的系统管理员分析网络，排查问题等所必备的东东之一。 二、traceroute的使用我的实验网络如下图： /24 54/24 _ _ _ _ | | | | | | | | | | | | | | | | | A |-| B |-| C |-| D |52/24 | | | | | | | | |_| |_| |_| |_|2/24 56/24 54/24上图中，上面的IP地址为左边网络接口的IP，下面为右面网口的IP。现在我们看看从A机到D机经过那些路由器。下面命令在Debian/Linux etch上完成，无特殊说明，本文的实验环境皆为该系统：ginyginy-x31 $ traceroute -n 52traceroute to 52 (52), 30 hops max, 40 byte packets1 28.960 ms 0.262 ms 2.485 ms2 54 7.909 ms 7.871 ms 11.897 ms3 52 7.861 ms 11.938 ms 11.863 ms上面的例子显示，从A机到D机，中间经过了B，C两个路由器。traceroute是如何发现经过的路由器的呢？三、用tcpdump抓包分析在运行上面的traceroute命令前，现用心tcpdump进行抓包，tcpdump需要root权限。traceroute探测路由器的包是UDP包，路由器返回的包是ICMP报，为了避免本机其他网络通信的干扰，我们只抓ICMP包和到主机52的UDP包。giny-x31 # tcpdump -i eth3 -v -n icmp or ( udp and host 52 )tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 96 bytes21:42:00.335644 IP (tos 0x0, ttl 1, id 52719, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33435: UDP, length 1221:42:00.336441 IP (tos 0xc0, ttl 64, id 6695, offset 0, flags none, proto: ICMP (1), length: 68) > 2: ICMP time exceeded in-transit, length 48 IP (tos 0x0, ttl 1, id 52719, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33435: UDP, length 1221:42:00.342394 IP (tos 0x0, ttl 1, id 52720, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33436: UDP, length 1221:42:00.343676 IP (tos 0xc0, ttl 64, id 6696, offset 0, flags none, proto: ICMP (1), length: 68) > 2: ICMP time exceeded in-transit, length 48 IP (tos 0x0, ttl 1, id 52720, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33436: UDP, length 1221:42:00.345833 IP (tos 0x0, ttl 1, id 52721, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33437: UDP, length 1221:42:00.345973 IP (tos 0xc0, ttl 64, id 6697, offset 0, flags none, proto: ICMP (1), length: 68) > 2: ICMP time exceeded in-transit, length 48 IP (tos 0x0, ttl 1, id 52721, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33437: UDP, length 1221:42:00.346366 IP (tos 0x0, ttl 2, id 52722, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33438: UDP, length 1221:42:00.347319 IP (tos 0xc0, ttl 254, id 64249, offset 0, flags none, proto: ICMP (1), length: 56) 54 > 2: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 52722, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33438: UDP, length 1221:42:00.348394 IP (tos 0x0, ttl 2, id 52723, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33439: UDP, length 1221:42:00.350331 IP (tos 0xc0, ttl 254, id 64250, offset 0, flags none, proto: ICMP (1), length: 56) 54 > 2: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 52723, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33439: UDP, length 1221:42:00.352717 IP (tos 0x0, ttl 2, id 52724, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33440: UDP, length 1221:42:00.354848 IP (tos 0xc0, ttl 254, id 64251, offset 0, flags none, proto: ICMP (1), length: 56) 54 > 2: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 52724, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33440: UDP, length 1221:42:00.355224 IP (tos 0x0, ttl 3, id 52725, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33441: UDP, length 1221:42:00.356708 IP (tos 0xc0, ttl 62, id 49316, offset 0, flags none, proto: ICMP (1), length: 68) 52 > 2: ICMP 52 udp port 33441 unreachable, length 48IP (tos 0x0, ttl 1, id 52725, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33441: UDP, length 1221:42:00.360874 IP (tos 0x0, ttl 3, id 52726, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33442: UDP, length 1221:42:00.362249 IP (tos 0xc0, ttl 62, id 49317, offset 0, flags none, proto: ICMP (1), length: 68) 52 > 2: ICMP 52 udp port 33442 unreachable, length 48 IP (tos 0x0, ttl 1, id 52726, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33442: UDP, length 1221:42:00.363097 IP (tos 0x0, ttl 3, id 52727, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33443: UDP, length 1221:42:00.365540 IP (tos 0xc0, ttl 62, id 49318, offset 0, flags none, proto: ICMP (1), length: 68) 52 > 2: ICMP 52 udp port 33443 unreachable, length 48 IP (tos 0x0, ttl 1, id 52727, offset 0, flags none, proto: UDP (17), length: 40) 2.52718 > 52.33443: UDP, length 12从上面tcpdump抓包显示结果来看，traceroute首先发送1个ttl为1目标为52的UDP包，目标端口号为33435，收到第一个返回的ICMP包后，在发送两个ttl为1的包，端口号依次递增。大家知道，ttl为1的数据包，在经过第一个路由器后，其生存时间ttl就为0了，这个包就要被丢弃，由丢弃数据包的路由器发送一个ICMP错误报告消息给被丢弃包的发送者，发送者知道数据包经过了哪个路由器。ttl为1的包能探测出经过的第一个路由器，发送ttl为2的包便能探测出第二个路由器，依次类推，直到收到目标主机的消息，该消息很可能是端口不可到达的ICMP错误消息，因为我们探测包的目标端口很可能没有开放。这就是traceroute发现路由器的过程。windows系统下用户可以用wireshark或者 windump （ /windump/ ）抓包。四、思考题留三道思考题，第一道我来做，后二道留给亲爱的读者您，哈哈。1、如果第三个路由器返回的ICMP包比第二个先回到原包发送者，如何判断那个是经过的第二个路由器，那个是第三个？答：发送UDP探测包时，目标端口总是变化的，而返回的ICMP错误报告消息中，有原包的端口信息，可以根据这个来区分。2、如果到目标主机的路径有多条，三次探测包经过的路径不一样，traceroute如何判断并显示结果？3、不用traceroute命令，用ping能探测出到目标主机的数据包经过的路由器吗？如何实现。例1：arp故障故障现象：局域网中的一台采用solaris操作系统的服务器A-SERVER网络连接不正常，从任意主机上都无法ping通该服务器。排查：首先检查系统，系统本身工作正常，无特殊进程运行，cpu，内存利用率正常，无挂接任何形式的防火墙，网线正常。此时我们借助tcpdump来进行故障定位，首先我们将从B-CLIENT主机上执行ping命令，发送icmp数据包给A-SERVER，如下：rootredhat log# ping A-SERVERPING A-SERVER from B-CLIENT : 56(84) bytes of data.此时在A-SERVER启动tcpdump，对来自主机B-CLIENT的数据包进行捕获。A-SERVER# tcpdump host B-CLIENTtcpdump: listening on hme016:32:32.611251 arp who-has A-SERVER tell B-CLIENT16:32:33.611425 arp who-has A-SERVER tell B-CLIENT16:32:34.611623 arp who-has A-SERVER tell B-CLIENT我们看到，没有收到预料中的ICMP报文，反而捕获到了B-CLIENT发送的arp广播包，由于主机B-CLIENT无法利用arp得到服务器A-SERVER的地址，因此反复询问A-SERVER的MAC地址，由此看来，高层的出问题的可能性不大，很可能在链路层有些问题，先来查查主机A-SERVER的arp表：A-SERVER# arp -a Net to Media TableDevice IP Address Mask Flags Phys Addr - - - - -hme0 netgate 55 00:90:6d:f2:24:00hme0 A-SERVER 55 S 00:03:ba:08:b2:83hme0 BASE-ADDRESS.MCAST.NET SM 01:00:5e:00:00:00请注意A-SERVER的Flags位置，我们看到了只有S标志。我们知道，solaris在arp实现中，arp的flags需要设置P标志，才能响应ARP requests。手工增加p位A-SERVER# arp -s A-SERVER 00:03:ba:08:b2:83 pub 此时再调用arp -a看看A-SERVER# arp -a Net to Media TableDevice IP Address Mask Flags Phys Addr - - - - -hme0 netgate 55 00:90:6d:f2:24:00hme0 A-SERVER 55 SP 00:03:ba:08:b2:83hme0 BASE-ADDRESS.MCAST.NET SM 01:00:5e:00:00:00我们看到本机已经有了PS标志，此时再测试系统的网络连接恢复正常，问题解决！例2：netflow软件问题故障现象：在新装的网管工作站上安装cisco netflow软件对路由设备流量等进行分析，路由器按照要求配置完毕，本地工作上软件安装正常，无报错信息，但是启动netflow collector却收不到任何路由器上发出的流量信息，导致该软件失效。 排查：反复检查路由和软件，配置无误。采用逐步分析的方法，首先先要定位出有问题的设备，是路由器根本没有发送流量信息还是本地系统接收出现了问题？突然想到在路由器上我们定义了接收的client端由udp端口9998接收数据，可以通过监视这个端口来看路由器是否确实发送了udp数据，如果系统能够接收到来自路由的数据包，那么路由方面的问题可能行不大，反之亦然。在网管工作站上使用tcpdump来看看：nms#tcpdump port 9995tcpdump: listening on hme018:15:34.373435 routea nms.9995: udp 146418:15:34.373829 routea.50111 nms.9995: udp 146418:15:34.374100 routea.50111 nms.9995: udp 1464马上我们就看到数据包确实从路由器上发过来了，问题出在路由器的可能性基本排除，重新核查系统，果然，网管工作站上安装了防火墙，udp端口9998是被屏蔽的，调整工作站上的防火墙配置，netflow工作恢复正常，故障排除！例3：邮件服务器排障故障现象：局域网新安装了后台为qmail的邮件服务器server，邮件服务器收发邮件等基本功能正常，但在使用中发现一个普遍的怪现象：pc机器上发邮件时连接邮件服务器后要等待很久的时间才能开始实际的发送工作。排查：网络连接没有问题，邮件服务器server和下面的pc性能都没有问题，问题可能出在哪里呢？为了进行准确的定位，我们在pc机client上发送邮件，同时在邮件服务器server上使用tcpdump对这个client的数据包进行捕获分析，如下： server#tcpdump host clienttcpdump: listening on hme019:04:30.040578 client.1065 server.smtp: S 1087965815:1087965815(0) win 64240 (DF)19:04:30.040613 server.smtp client.1065: S 99285900:99285900(0) ack 1087965816 win 10136 (DF)19:04:30.040960 client.1065 server.smtp: . ack 1 win 64240 (DF)顺利的完成三次握手，目前为止正常，往下看 19:04:30.048862 server.33152 client.113: S 99370916:99370916(0) win 8760 (DF)19:04:33.411006 server.33152 client.113: S 99370916:99370916(0) win 8760 (DF)19:04:40.161052 server.33152 client.113: S 99370916:99370916(0) win 8760 (DF)19:04:56.061130 server.33152 client.113: R 99370917:99370917(0) win 8760 (DF)19:04:56.070108 server.smtp client.1065: P 1:109(10 ack 1 win 10136 (DF)这里有问题了