小试牛刀:一个简单的应用实例
Wireshark网络分析就这么简单
我的老板气宇轩昂,目光笃定,在人群中颇有大将风范(当然是老板娘不在场的时候)。有一年我们在芝加哥流落街头,也没见他皱过眉头。不过前几天,这位气场型领导竟然板着脸跑过来,说赶紧帮忙,有位同事被客户骂惨了。我当然不能拒绝帮(yao)助(qiu)同(jia)事(xin)的机会,立即加入电话会议。
原来事情是这样的:客户不小心重启了服务器A,然后它就再也无法和服务器B通信了。由于这两台服务器之间传输的是关键数据,现场工程师又一时查不出原因,所以客户异常恼火。
问题听起来并不复杂,考虑到起因是服务器A的重启,所以我收集了它的网络配置(见图1)。
服务器B的网络配置则简单很多,只有一个IP地址192.168.182.131,子网掩码也是255.255.255.0。
当我们在A上ping B时,网络包应该怎么走?阅读以下内容之前,读者不妨先停下来思考一下。
一般情况下,像A这类多IP的服务器是这样配路由的:假如自身有一个IP和对方在同一子网,就从这个IP直接发包给对方。假如没有一个IP和对方同子网,就走默认网关。在这个环境中,A的3个IP显然都与B属于不同子网,那就应该走默认网关了。会不会是A和默认网关的通信出问题了呢?我从A上ping了一下网关,结果却是通的。难道是因为网关没有把包转发出去?或者是ping请求已经被转发到B了,但ping回复在路上丢失?我感觉自己已经走进死胡同。每当到了这个时候,我就会想到最值得信赖的队友——Wireshark。
我分别在eth0、eth1、和eth2上抓了包。最先查看的是连接默认网关的eth0,出乎意料的是,上面竟然一个相关网络包都没有。而在eth1上抓的包却是图2的表现: A正通过ARP广播查找B(192.168.182.131)的MAC地址,试图绕过默认网关直接与B通信。这说明了什么问题呢?
这说明A上存在一项符合192.168.182.131的路由,促使A通过eth1直接与B通信。我赶紧逐项检查路由表,果然发现有这么一项(见图3):
因为192.168.182.131属于192.168.182.0/255.255.255.0,所以就会走这条路由。由于不同子网所配的VLAN也不同,所以这些ARP请求根本到达不了B。ping包就更不用说了,它从来就没发出来过。客户赶紧删除了这条路由,两台服务器的通信也随即恢复。
为什么A重启之后会多了这条莫名其妙的路由呢?根据客户回忆,他们以前的确是配过该路由的,后来删掉了,不知道为什么配置文件里还留着。今天的重启加载了一遍配置文件,所以这条路由又出现了。你也许会问,为什么不从一开始就仔细检查路由表呢?这样就不至于走错胡同,连抓包和Wireshark都省了。我当时也是这样反省的,但现实中要做到并不容易。且不说一开始并没有怀疑到路由表,就算怀疑了也不一定能看出问题来。在这个案例中,系统管理员和现场工程师都检查过路由表,但无一例外地忽略了出问题的一项。这是因为真实环境中的路由表有很多项,在紧张的电话会议上难以注意到多出了异常的一项。而且子网掩码也不是255.255.255.0那么直观。假如本文所用的IP保持不变,但子网掩码变成255.255.248.0,路由表就成了图4所示的样子。
在这个输出中,难以一眼注意到192.168.176.0就适用于目标地址192.168.182.131,至少对我来说是这样的。
我们能从这个案例中学习到什么呢?最直接的启示便是翻出简历,投奔甲方去。这样就可以在搞砸系统的时候,义正词严地要求乙方解决了。假如你固执地想继续当乙方,那就开始学习Wireshark吧。再有经验的工程师也有犯迷糊的时候,而Wireshark从来不会,它随时随地都能告诉你真相,不偏不倚。
本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。