用wireshark分析网络

这两天看了两本有意思的书， Wireshark网络分析就这么简单 、 wireshark网络分析的艺术 。

之前工作中就常常用到这个软件，好多时候总是感叹 这个软件实在太NB了 ，这本书作者也是个实战派，采用种种案例展示了如何用Wireshark探索网络现象，实在是很迷人。

开篇有一个很有意思的小问题，我思考了一下，觉得很容易作为网络理解的小case用在课堂ABC上，记录一下。

问题：两台服务器A和B的网络配置如下

• 服务器A:

  • IP:192.168.26.129
  • Mask: 255.255.255.0
  • Gateway: 192.160.26.2

• 服务器B:

  • IP:192.168.26.3
  • Mask: 255.255.255.224
  • Gateway: 192.160.26.2

B的子网掩码本应该是255.255.255.0，被不小心配成了255.255.255.224。它们还能正常通信吗？

哈哈，我就喜欢这样简单明快的问题。看似简单，其实想想还是有点陷阱的。而且这种问题有个共同点，就是如果你不懂原理，也没关系；喜欢瞎动手的童鞋一般都会去试试这种情况，所以能把答案 碰出来 。我就见到过这种·自学成才·的老师，他们从来没有在学校里系统学过什么TCP/IP或者老破旧的ISO 7层模型，照样能对网络和路由配置如数家珍，他们的能力完全建立在实战的基础上。

让我们好好分析一下这个问题。

首先B的子网掩码配置决定了它和A不在一个子网上，我们在书本上学到的知识，如果两台机器不在一个子网上，能够通信吗？

哈，如果死读书不实践的人肯定会说:不能通信，不在一个子网嘛。

那么我们照这个逻辑，公司里岂不是不同子网的机器老死不相往来了？

看吧，这是第一个陷阱，两台机器跨子网能否通信，取决于网关。

如果没有网关服务器，或者网关服务器限制的话，肯定是不能通信的，虽然A和B物理上处于同一个子网，但是这个时候可以看成有一道防火墙在两台机器之间。

其实大部分网络管理员都会把网关设置为不同子网间相互转发的，不然一个公司各部门间的机器不能互访，岂不是很悲剧。

那么在网关能正常转发的情况下，我们来脑补一下两个场景，B访问A，A访问B的具体过程。

B Ping => A

1. B首先检查到A和它不在一个子网，这个时候它需要网关来转发数据包
2. B发一个网关IP的ARP请求
3. 网关(192.168.26.2) 回复B的ARP请求，告诉它俺的MAC 地址是XXX
4. 有了网关的MAC，B就可以直接发包给网关了，它告诉网关，我要你帮我转发包给A
5. 如果网关没有限制的话，它就会把包转发给A
6. A收到B的请求，他就会问，这个B是谁呀？A检查一番，发现B和自己在一个子网
7. 既然一个子网，那么A就不会走网关了，它直接发出ARP请求在以太网上广播，谁是B呀，MAC地址回我一个
8. B在物理上实际上是和A在一起的，所以直接响应A，俺的MAC地址是这个
9. A收到B的ARP响应，就很HAPPY的跳过网关，直接给B响应包啦
10. 这样的结果就是B发给A的包需要走网关，A发给B的包直接广播到以太网上，由B直接接收
11. 最终的效果就是B能和A正常通信，虽然B的通信绕了一点远路

A Ping => B

这个过程其实跟上面一样，A发出ARP请求直接找到了B，所以A发包给B是不用走网关的，B的响应还要走网关。

怎么样，这么看看，是不是问题就很明晰了呢。大部分情况下(网关没有特殊配置)，A和B是能够正常通信的。

有点小得意的说，这个问题我很快就反应过来了；因为我和作者一样是野路子出家，实战瞎鼓捣过，所以这类小Case恰好是尝过的菜。

咳咳，真是有点自吹自擂了；其实绝大多数网络问题最后找到原因都很简单，但是当一个大型的网络里面发生诡异的情况时，能迅速定位问题点是很不容易的。我又回想起来之前工作时，在一个客户现场遇到的坑。

很久很久以前~~~

咳咳，其实也不是多久，但那个时候我已经工作挺长时间了，虽然没有经过什么系统理论培训，但是靠着大量野路子实践，我觉得也算是见过很多网络万年坑了，我去客户现场从来不怵头，但就是那一次，差点阴沟里翻船~~

我去国内的某家大型券商部署项目，那家券商真是壕啊，从服务器到网络设备都是定制的特别高端的一批货，然后我熟门熟路的安装好Centos7.1，他们的系统管理员按照内部规定，做了安全防护之后，我们从他们的顶层小机房转移到操作办公室，准备部署应用软件。

这家券商的网络大部分已经迁移到SDN上面，办公室的终端机器经过两层跳板，跳到一个云主机的 shell 上面，然后再远程ssh连接到我们刚刚装好的服务器上，准备大展拳脚~~~~

根据故事的发展，这个时候就出现了诡异的事情，随机过20~40分钟后，我们的ssh连接就会卡一段时间，然后有几率断掉，之前所有工作都是正常的，而且有时候能正常个1小时，但是最后总是会开始卡。

唉，网络卡死，网络时不时断掉，真的是现场网络工程师人生中的一大悲剧，这类问题感觉天天遇见，但是总是没有一个固定的套路去解决它。

我们的终端机经过了两重跳板，然后ssh客户端和服务器之间，还有一个庞大的网络拓扑，跋山涉水十万八千里才能相见，然后就被某个不知名的幽灵生生拆散了，想象他们艰难的会师路径，我不禁打个冷颤。

肯定不能先去怀疑他们的会师历程，我们先去查找最简单的，也是最容易出错的部分，就是服务端的sshd配置

因为安装完系统后，客户的管理员根据他们的安全管理条例，运行了自己开发一个脚本进行了系统加固，很自然的，我们怀疑这个脚本是不是有什么地方配置不对，导致问题

在对服务器配置稳健和脚本代码详细检查之后，我失望的判定，人家的脚本没问题

配置没有问题，那就看看是不是ssh终端软件有问题呢

我反复使用ssh登陆不同的服务器，惊奇的发现，凡是登陆我们刚安装好的这批服务器，就会时不时断掉，其它服务器就没有问题； 但是悲剧的是我们的服务器所在的机房，没有其它测试机，所以只能证明ssh终端软件没问题

不到万不得已，我是不想怀疑中间庞大的网络路径的，谁知道是不是什么抽风的防火墙规则呢

我抱着笔记本，跑到楼上服务器的小机房直联看看，发现直联好得很

现在说起来简单，其实跑一趟机房需要审批、内部人员带路一堆手续，累的客户跟我上上下下，验证一次需要1个小时以上，而且重现时间是随机的，这就是一线人员苦逼的地方啊。

看起来一切都导向那个我最不愿意看到的结果，好像是通信中间有个什么诡异的防火墙规则之类的~~，但是这么庞大的网络拓扑，怎么定位问题呢？

到了此时，客户不再纠结于安全管理条例，我们小心翼翼的祭出了·抓包·这个手段

• 不到万不得已，其实大家都不想抓包的；金融行业的客户群，重视安全问题甚于生命，所以能在生产环境中让你抓包，其实已经是皇恩浩荡了。

• 经过了几十分钟苦苦等待，终于问题又重现了，我们小心翼翼的把抓到的包存到本地，用wireshark打开，像欣赏小电影一样仔仔细细~~~

• 果然有问题，那台服务器的ARP响应包里面，MAC地址竟然会变！

• 奇哉怪哉，我们刚配好这台服务器，怎么就让人ARP欺骗了呢？而且如果是他们的网络里面有ARP病毒，为啥就只找我们的服务器呢？

当时已经从早上折腾到下午3点种左右，虽然有了重大发现，但是也有了更大的迷惑

突然我灵光一闪，服务器接了两根网线，一根是管理口为了方便管理，这个一直没有动过，会不会是~~~

我立马报着笔记本和一台小交换机跑上楼去

将服务器和笔记本通过一台小交换机联到一个小局域网络中，再抓包发现了真相

这台定制的服务器是浪潮提供的，而浪潮的管理口有个奇怪的设定，它和服务器上的多个网卡被绑定成一个NIC Teaming，类型为Transmit Load Balancing（TLB）。TLB的特点就是收包工作只由一个网卡负责，发包工作则分摊给所有网卡，但是管理口的默认配置有问题，有时候莫名其妙会共享同一个IP，回应ARP请求的时候把自己的MAC地址发回去，但是系统中管理口是没有配置的，所以这台服务器莫名其妙就自己变成了一台ARP欺骗源。

问题定位了，我们打电话找浪潮的供应商；供应商也非常奇怪，表明是第一次碰到这种问题，可能是由于定制的机器，考虑不周导致的。

然后我们的解决方法就是，将笔记本直联服务器，在笔记本上运行一个DHCP 服务，这样管理口在开机的时候会被分配一个IP地址，我们再通过这个IP地址登陆服务器管理界面，配置一个静态IP，就OK了。

虽然最后是一个简单至极的ARP欺骗问题，但是发生在一个庞大的网络拓扑中，调试手段被限制，发生时间随机，楼上物理距离和安全条例导致你重现一次成本极为高昂，你还能·镇定自若，指挥谈笑间·吗，这是一次一波三折的排障经历啊。

我这么详细的回忆一次折腾的排障经历，是因为我在这本书里发现了作者和我一摸一样的苦逼例子，在<wireshark网络分析的艺术>这本书里，大家有兴趣可以自己去翻翻。

其实这两本书真可谓是作者的网络排障手记，因为我也有那么一段跑在一线的日子，读起来格外亲切。这就是一线工程师的日常啊。

曾经，我以为熟读<TCP/IP详解>和<Unix网络编程>就能成为无所不能的网络大拿；曾经，我以为独立实现一个网络协议栈就是开创天地的神邸；后来，我明白了，网络的海洋无穷无尽，虽然规则是死的，但是现实世界实在不可预测，也许下一分钟就会有一个匪夷所思的case来纠缠你，嘲笑你的妄自尊大。

在网络世界迈入SDN之际，我非常惶恐，因为我明白以我的智商，不可能成为什么·专家·了；我想，未来，可能只有在AWS或者Google Cloud浸淫数十年的人，才能小心翼翼的称自己为·真专家·；面对网络知识的变幻莫测，总有一种·生有涯，知无涯·的惶恐；我总是会感叹，网络这个东西实在是太神奇了，真不知道如何形容这份感觉，就是只有·神奇·来形容