1、一、什么是 traceroute，什么是 tcpdump？通过 Traceroute 我们可以知道信息从你的计算机到互联网另一端的主机是走的什么路径。当然每次数据包由某一同样的出发点（source ）到达某一同样的目的地(destination)走的路径可能会不一样，但基本上来说大部分时候所走的路由是相同的。traceroute 就是用来追踪出发点到目的地所经过的路径（路由器） ，UNIX 系统中，我们称之为 Traceroute,MS Windows 中为 Tracert。TcpDump，用简单的话来定义 tcpdump，就是：dump the traffice on a network，根
2、据使用者的定义对网络上的数据包进行截获的包分析工具。作为互联网上经典的的系统管理员必备工具，tcpdump 以其强大的功能，灵活的截取策略，成为每个高级的系统管理员分析网络，排查问题等所必备的东东之一。 二、traceroute 的使用我的实验网络如下图：192.168.1.1/24 172.16.11.254/24_ _ _ _| | | | | | | | | | | | | | | A |-| B |-| C |-| D |172.16.11.252/24| | | | | | | |_| |_| |_| |_|192.168.1.52/24 172.16.11.156/24 172.1
3、6.10.254/24上图中，上面的 IP 地址为左边网络接口的 IP，下面为右面网口的 IP。现在我们看看从 A 机到 D 机经过那些路由器。下面命令在 Debian/Linux etch 上完成，无特殊说明，本文的实验环境皆为该系统：ginyginy-x31 $ traceroute -n 172.16.10.252traceroute to 172.16.10.252 (172.16.10.252), 30 hops max, 40 byte packets1 192.168.1.1 28.960 ms 0.262 ms 2.485 ms2 172.16.11.254 7.909 ms
4、7.871 ms 11.897 ms3 172.16.10.252 7.861 ms 11.938 ms 11.863 ms上面的例子显示，从 A 机到 D 机，中间经过了 B，C 两个路由器。traceroute 是如何发现经过的路由器的呢？三、用 tcpdump 抓包分析在运行上面的 traceroute 命令前，现用心 tcpdump 进行抓包，tcpdump 需要 root 权限。traceroute 探测路由器的包是 UDP 包，路由器返回的包是 ICMP 报，为了避免本机其他网络通信的干扰，我们只抓 ICMP 包和到主机 172.16.10.252 的 UDP 包。giny-x31
5、 # tcpdump -i eth3 -v -n icmp or ( udp and host 172.16.10.252 )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) 192.168.1.52.52718 172.16.10.252.33435: UDP, length 1221:42:00
6、.336441 IP (tos 0xc0, ttl 64, id 6695, offset 0, flags none, proto: ICMP (1), length: 68) 192.168.1.1 192.168.1.52: ICMP time exceeded in-transit, length 48IP (tos 0x0, ttl 1, id 52719, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33435: UDP, length 1221:42:00.
7、342394 IP (tos 0x0, ttl 1, id 52720, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33436: UDP, length 1221:42:00.343676 IP (tos 0xc0, ttl 64, id 6696, offset 0, flags none, proto: ICMP (1), length: 68) 192.168.1.1 192.168.1.52: ICMP time exceeded in-transit, len
8、gth 48IP (tos 0x0, ttl 1, id 52720, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33436: UDP, length 1221:42:00.345833 IP (tos 0x0, ttl 1, id 52721, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33437: UDP, length 1221:42:00
9、.345973 IP (tos 0xc0, ttl 64, id 6697, offset 0, flags none, proto: ICMP (1), length: 68) 192.168.1.1 192.168.1.52: ICMP time exceeded in-transit, length 48IP (tos 0x0, ttl 1, id 52721, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33437: UDP, length 1221:42:00.
10、346366 IP (tos 0x0, ttl 2, id 52722, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33438: UDP, length 1221:42:00.347319 IP (tos 0xc0, ttl 254, id 64249, offset 0, flags none, proto: ICMP (1), length: 56) 172.16.11.254 192.168.1.52: ICMP time exceeded in-transit,
11、 length 36IP (tos 0x0, ttl 1, id 52722, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33438: UDP, length 1221:42:00.348394 IP (tos 0x0, ttl 2, id 52723, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33439: UDP, length 1221:4
12、2:00.350331 IP (tos 0xc0, ttl 254, id 64250, offset 0, flags none, proto: ICMP (1), length: 56) 172.16.11.254 192.168.1.52: ICMP time exceeded in-transit, length 36IP (tos 0x0, ttl 1, id 52723, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33439: UDP, length 122
13、1:42:00.352717 IP (tos 0x0, ttl 2, id 52724, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33440: UDP, length 1221:42:00.354848 IP (tos 0xc0, ttl 254, id 64251, offset 0, flags none, proto: ICMP (1), length: 56) 172.16.11.254 192.168.1.52: ICMP time exceeded in-
14、transit, length 36IP (tos 0x0, ttl 1, id 52724, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33440: UDP, length 1221:42:00.355224 IP (tos 0x0, ttl 3, id 52725, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33441: UDP, lengt
15、h 1221:42:00.356708 IP (tos 0xc0, ttl 62, id 49316, offset 0, flags none, proto: ICMP (1), length: 68) 172.16.10.252 192.168.1.52: ICMP 172.16.10.252 udp port 33441 unreachable, length 48IP (tos 0x0, ttl 1, id 52725, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252
16、.33441: UDP, length 1221:42:00.360874 IP (tos 0x0, ttl 3, id 52726, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33442: UDP, length 1221:42:00.362249 IP (tos 0xc0, ttl 62, id 49317, offset 0, flags none, proto: ICMP (1), length: 68) 172.16.10.252 192.168.1.52:
17、ICMP 172.16.10.252 udp port 33442 unreachable, length 48IP (tos 0x0, ttl 1, id 52726, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52.52718 172.16.10.252.33442: UDP, length 1221:42:00.363097 IP (tos 0x0, ttl 3, id 52727, offset 0, flags none, proto: UDP (17), length: 40) 192.168.1.52
18、.52718 172.16.10.252.33443: UDP, length 1221:42:00.365540 IP (tos 0xc0, ttl 62, id 49318, offset 0, flags none, proto: ICMP (1), length: 68) 172.16.10.252 192.168.1.52: ICMP 172.16.10.252 udp port 33443 unreachable, length 48IP (tos 0x0, ttl 1, id 52727, offset 0, flags none, proto: UDP (17), length
19、: 40) 192.168.1.52.52718 172.16.10.252.33443: UDP, length 12从上面 tcpdump 抓包显示结果来看，traceroute 首先发送 1 个 ttl 为 1 目标为 172.16.10.252的 UDP 包，目标端口号为 33435，收到第一个返回的 ICMP 包后，在发送两个 ttl 为 1 的包，端口号依次递增。大家知道，ttl 为 1 的数据包，在经过第一个路由器后，其生存时间 ttl 就为 0 了，这个包就要被丢弃，由丢弃数据包的路由器发送一个 ICMP 错误报告消息给被丢弃包的发送者，发送者知道数据包经过了哪个路由器。ttl
20、 为 1 的包能探测出经过的第一个路由器，发送 ttl 为 2 的包便能探测出第二个路由器，依次类推，直到收到目标主机的消息，该消息很可能是端口不可到达的 ICMP 错误消息，因为我们探测包的目标端口很可能没有开放。这就是 traceroute 发现路由器的过程。windows 系统下用户可以用 wireshark 或者 windump （ http:/www.winpcap.org/windump/ ）抓包。四、思考题留三道思考题，第一道我来做，后二道留给亲爱的读者您，哈哈。1、如果第三个路由器返回的 ICMP 包比第二个先回到原包发送者，如何判断那个是经过的第二个路由器，那个是第三个？答：
21、发送 UDP 探测包时，目标端口总是变化的，而返回的 ICMP 错误报告消息中，有原包的端口信息，可以根据这个来区分。2、如果到目标主机的路径有多条，三次探测包经过的路径不一样，traceroute 如何判断并显示结果？3、不用 traceroute 命令，用 ping 能探测出到目标主机的数据包经过的路由器吗？如何实现。例 1：arp 故障故障现象：局域网中的一台采用 solaris 操作系统的服务器 A-SERVER 网络连接不正常，从任意主机上都无法 ping 通该服务器。排查：首先检查系统，系统本身工作正常，无特殊进程运行，cpu，内存利用率正常，无挂接任何形式的防火墙，网线正常。此时
22、我们借助 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 te
23、ll 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 N
24、et to Media TableDevice IP Address Mask Flags Phys Addr - - - - -hme0 netgate 255.255.255.255 00:90:6d:f2:24:00hme0 A-SERVER 255.255.255.255 S 00:03:ba:08:b2:83hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01:00:5e:00:00:00请注意 A-SERVER 的 Flags 位置，我们看到了只有 S 标志。我们知道， solaris 在 arp 实现中，arp 的 flags 需要设置 P 标志
25、，才能响应 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 255.255.255.255 00:90:6d:f2:24:00hme0 A-SERVER 255.255.255.255 SP 00:03:ba:08:b2:83hme0 BASE-ADDRESS.MCAST.NET 240
26、.0.0.0 SM 01:00:5e:00:00:00我们看到本机已经有了 PS 标志，此时再测试系统的网络连接恢复正常，问题解决！例 2：netflow 软件问题故障现象：在新装的网管工作站上安装 cisco netflow 软件对路由设备流量等进行分析，路由器按照要求配置完毕，本地工作上软件安装正常，无报错信息，但是启动 netflow collector 却收不到任何路由器上发出的流量信息，导致该软件失效。 排查：反复检查路由和软件，配置无误。采用逐步分析的方法，首先先要定位出有问题的设备，是路由器根本没有发送流量信息还是本地系统接收出现了问题？突然想到在路由器上我们定义了接收的 cli
27、ent 端由 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马上我们
28、就看到数据包确实从路由器上发过来了，问题出在路由器的可能性基本排除，重新核查系统，果然，网管工作站上安装了防火墙，udp 端口 9998 是被屏蔽的，调整工作站上的防火墙配置，netflow 工作恢复正常，故障排除！例 3：邮件服务器排障故障现象：局域网新安装了后台为 qmail 的邮件服务器 server，邮件服务器收发邮件等基本功能正常，但在使用中发现一个普遍的怪现象：pc 机器上发邮件时连接邮件服务器后要等待很久的时间才能开始实际的发送工作。排查：网络连接没有问题，邮件服务器 server 和下面的 pc 性能都没有问题，问题可能出在哪里呢？为了进行准确的定位，我们在 pc 机 clie
29、nt 上发送邮件，同时在邮件服务器 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.04
30、0960 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
31、(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)这里有问题了，我们看到 server 端试图连接 client 的 113 identd 端口，要求认证，然而没有收到 client 端的回应，server 端重复尝试了 3 次，费时 26 秒后，才放弃认证请求，主动发送了 reset 标志的数据包，开始 push 后面的数据，而正是在这个过
32、程中所花费的 26 秒时间，造成了发送邮件时漫长的等待情况。问题找到了，就可以对症下药了，通过修改服务器端的 qmail 配置，使它不再进行 113 端口的认证，再次抓包，看到邮件 server 不再进行 113 端口的认证尝试，而是在三次握手后直接 push 数据，问题解决！总结：上面我们通过实际的例子演示了包分析软件在故障解决中起到的作用，通过这些例子，我们不难发现，用好包分析软件，对系统管理员快速准确定位网络故障，分析网络问题有不可替代的作用一个学校发现其中有 ARP 欺骗,冲击波病毒,蠕虫王病毒,需要处理.处理过程:在核心交换机上配置端口镜像分别抓各个网段的数据包,(分别抓各个网段的数
33、据包的目的是减小核心交换机压力,也方便缩小分析量)1.ARP 欺骗使用下列过滤法则:arp.opcode=1 or arp.opcode=2 发现 ARP 欺骗包后 ,以其 MAC 为过滤条件即:eth.scr =.分析其相关 IP 信息,找到具体用户.如果用户修改了 IP 和 MAC 地址就只有一根一根去拔线了!2.冲击波病毒分析数据包,使用下列过滤法则:tcp.port = 135 tcp.port = 139分析过滤后的数据包,察看发现全是 TCP 三次握手中的第一个 syn 包,检查其占总体数据的比率远高于正常水平.通过 IP 查找源头!3.蠕虫王病毒tcp.port = 1433分析
34、过滤后的数据包,察看发现全是 TCP 三次握手中的第一个 syn 包,检查其占总体数据的比率远高于正常水平.通过 IP 查找源头!4.使用下列过滤法则:!(tcp.port =5900 or tcp.port =135 or tcp.port=139)先保存过滤后的数据包,再分析.发现:tcp.port = 5900 占用的数据比率也比较高VNC TCP port: 5900) 5900/tcp open vnc VNC (protocol 3.追踪相关 IP!由于其教室中的 PC 都是有硬件还原卡的,而它 PC 也是管理较为混乱.于是决定决定在核心交换机上添加访问列表.具体访问列表的方案参考:网络设备配置中经常使用的访问列表或 rule(华为设备中使用 )
