小试牛刀：一个简单的应用实例

我的老板气宇轩昂，目光笃定，在人群中颇有大将风范（当然是老板娘不在场的时候）。有一年我们在芝加哥流落街头，也没见他皱过眉头。不过前几天，这位气场型领导竟然板着脸跑过来，说赶紧帮忙，有位同事被客户骂惨了。我当然不能拒绝帮（yao）助（qiu）同（jia）事（xin）的机会，立即加入电话会议。

原来事情是这样的：客户不小心重启了服务器 A，然后它就再也无法和服务器B通信了。由于这两台服务器之间传输的是关键数据，现场工程师又一时查不出原因，所以客户异常恼火。

问题听起来并不复杂，考虑到起因是服务器A的重启，所以我收集了它的网络配置（见图1）。

图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通信。这说明了什么问题呢？

图2

这说明A上存在一项符合192.168.182.131的路由，促使A通过eth1直接与B通信。我赶紧逐项检查路由表，果然发现有这么一项（见图3）：

图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所示的样子。

图4

在这个输出中，难以一眼注意到192.168.176.0就适用于目标地址192.168.182.131，至少对我来说是这样的。

我们能从这个案例中学习到什么呢？最直接的启示便是翻出简历，投奔甲方去。这样就可以在搞砸系统的时候，义正词严地要求乙方解决了。假如你固执地想继续当乙方，那就开始学习 Wireshark 吧。再有经验的工程师也有犯迷糊的时候，而Wireshark从来不会，它随时随地都能告诉你真相，不偏不倚。