再次体会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广播包!!!如下所示:spacer.gif

这说明什么问题呢?这说明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从来不会,它随时随地都能告诉你真相,不偏不倚。

转载于:https://www.cnblogs.com/yizhangheka/p/11033240.html

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 扫一扫,分享海报

参与评论 您还未登录,请先 登录 后发表或查看评论
©️2022 CSDN 皮肤主题:编程工作室 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值