本节书摘来自异步社区《wireshark网络分析就这么简单》一书中的小试牛刀：一个简单的应用实例，作者林沛满,更多章节内容可以访问云栖社区“异步社区”公众号查看。
小试牛刀：一个简单的应用实例
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从来不会，它随时随地都能告诉你真相，不偏不倚。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。