再次体会wireshark的威力！

　　今天一位同学给我打电话，说是重启了客户机房里的一台服务器A，重启之后此台服务器不能与B服务器通信了，要命的是A台服务器上有关键数据需要与B服务器进行通信交互。客户大发雷霆，同学的老板也发火一再催促要尽快完工此次项目把钱收回来，做为项目经理的同学陷入到了严重的焦虑当中，一方面因为耽误了客户的业务感到愧疚，更一方面害怕公司的名誉受损，影响接下来的合作。这位同学已经一天一夜没有休息了，他们公司的工程师也来了两位依然没有查到原因，无奈下向我求助，我能体会到这位同学进退两难的境地，透过电话能感受到他低落的情绪，不亲身经历的人永远无法体会这种感觉。我决定试一试帮他解决。

　　问题听起来并不复杂，就是A服务器因重启之后无法连接WEB服务器了，于是我收集了A服务器的网络信息，如下：

[root@A~]# ifconfig | egrep "HWaddr|inet addr"
eth0      Link encap:Ethernet  HWaddr 00:0C:29:EC:9C:70
          inet addr:192.168.80.124  Bcast:192.168.80.255  Mask:255.255.255.0
eth1      Link encap:Ethernet  HWaddr 00:0C:29:EC:9C:84
          inet addr:192.168.90.31  Bcast:192.168.90.255  Mask:255.255.255.0
eth2      Link encap:Ethernet  HWaddr 00:0C:29:EC:9C:7A
          inet addr:192.168.100.31  Bcast:192.168.100.255  Mask:255.255.255.0
          inet addr:127.0.0.1  Mask:255.0.0.0
[root@A ~]# route | grep default
default         192.168.80.254  0.0.0.0         UG    0      0        0 eth0

而B服务器只有一个IP地址，没有网关，地址如下：

[root@B~]# ifconfig | grep "inet addr"
   inet addr:192.168.10.9  Bcast:192.168.10.255  Mask:255.255.255.0

　　在这个环境当中，A服务器的三个网卡都与B服务器的网卡不在同一个网段，正常情况下，如果A想与B进行通信必须先将数据包交付给网关（192.168.80.254）进行转发，于是我在A服务器ping了一下网关，发现A服务器与网关是可以通的，但无法与B通信，请求一直是超时，难道是网关没有把包给转发出去？或者是ICMP-request包到达了B服务器之后被iptables的INPUT链给DROP掉了，亦或者是ICMP-replay包到达了B服务器之后被iptables的OUTPUT链给DROP掉了？造成这个现象的原因有好多，我又不在现场，能排查的地方实在有限，我感觉自己已经走进了死胡同，难道这次帮忙要以失败告终？我不甘心。

　　在屏幕前面发呆了一会儿，我拿出A4纸，把造成这个现象所有的、我能想到的原因全部列了出来，列出来之后我发现我所列出的原因都是集中在数据包离开A服务器之后所经过的节点设备和B服务器上，却没有列出A服务器本身的原因，这时大脑当中忽然莫名奇妙的“蹦”出来一句话与这事不相干的话：“行有不得，反求诸已”，我好像抓住了什么！我有种强烈的预感，问题就是出在这里，A服务器与网关的通信已经能确认没问题，但是A服务器与B服务器通信的数据包真的从A服务器正常发出去了吗？这个我不确定，怎样才能验证一下呢？真是一波三折，正当发愁时，看到任务栏上的wireshark软件，对呀！通过wireshark可以确认A服务器与B服务器通信情况，赶紧试一下。

　　于是我在A服务器ping B服务器时，在A服务器的三个网卡都抓了包，结果发现eth0网卡竟然一个ICMP包都没有发，这不应该，A服务器与B服务器通信时，要通过eth0网卡才能将数据包交给网关，因为A的eth0与网关是处在同一个子网，但是现在却一个包都没有。我又打开在eth1网卡上抓的包，结果惊讶的发现竟然有查找B服务器的ARP广播包！！！如下所示：

　　这说明什么问题呢？这说明A上存在一个符合192.168.10.9的路由表项，使得A通过eth1直接与B通信，而没有匹配到默认路由。我赶紧一条条的仔细检查路由表，果然发现有这么一条！如下所示：

[root@A ~]# route -n | egrep "Dest|192.168.10.0"
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1

　　因为192.168.10.9默认也属于192.168.10.9/24表项，所以默认就会走这条路由，而不同子网所配置的VLAN也不同，所以这些ARP请求包根本无法到达B服务器，PING包就更不用说了，我让同学将这条路由删除之后A服务器就与B服务器恢复通信了，同学和我都如释重负，高兴的不得了，同学说是回来一定要请我吃饭，我当然欣然答应了。我得到了同学的感谢，还得到了自己的认可，心中充满了欢喜，真的像是打赢了一场硬仗，但我知道，我得到的远不止这些……

　　同学知道了原因之后，确定这次事故错不在他，便理直气壮的质问客户：为什么A服务器重启之后多了这条莫名其妙的路由呢？根据客户回忆，他们以前的确配置过该条路由，后来删除了，这个删除仅是删除内存里面的路由条目，而配置文件的路由条目依然存在，这次重启服务器，恰好给了服务器重读配置文件的机会，所以这条路由又出来了。

　　我们从这个案例当中可以学到什么呢？最直接的启示就是拿上简历，投奔甲方去，这样就在搞砸系统的时候，理直气壮要求乙方解决了。假如你依然还想继续当己方的话，那么就必须要好好学习wireshark了，因为wireshark实乃网络工程师居家必备的“甩锅利器”。再有经验的工程师也有犯迷糊的时候，而whireshar从来不会，它随时随地都能告诉你真相，不偏不倚。