本节书摘来自异步社区《Wireshark网络分析的艺术》一书中的像福尔摩斯一样思考，作者林沛满,更多章节内容可以访问云栖社区“异步社区”公众号查看。

像福尔摩斯一样思考

Wireshark网络分析的艺术有位读者在豆瓣上评论我的上一本书，说有阅读侦探小说的感觉。我对此并不觉得惊讶，因为用Wireshark排查问题，和侦探破案的思路是一致的。神探福尔摩斯的破案秘诀是“溯因推理”——先观察所有细节，比如鞋根上的泥疙瘩甚至烟灰；然后作出多种推理和假设；接着刨去各种不可能，最后剩下的“无论多么难以置信，肯定没错。”用Wireshark分析网络包时也类似，我们先要在网络包中寻找各种线索，然后根据网络协议作出推理，接着刨去人为（有意或无意）掩盖的证据，才能得到最后的真相。尤其是和保密机构打交道的时候，工程师进不了机房，文档也不能公开，所以一切线索只能自己在包里找，感觉就更像破案了。

我最近帮一位读者解决的问题就非常典型。他供职的机构内部网站有时候会发生诡异的现象，比如Web服务器的端口号会随机发生变化（具体症状就不多讲了，和本文关系不大）。后来做了排查，把客户端和Web服务器直连，问题就消失了，确认了Web服务器和客户端都没有问题。难道根本原因就出在网络路径上了？可是管理员又声称网络拓扑非常简单，不会出问题的。见图1，客户端和Web服务器在不同的子网里，中间由一个路由器转发。

凭我的经验，这个网络拓扑的确简单到没有出问题的可能。可是已经到了山穷水尽的地步了，只好抓包试试。Web服务器不允许我们登录，所以只能在客户端抓，更糟糕的是抓包时那个诡异的现象并没有发生。你一定会纳闷，正常状况抓的包有什么看头啊？人在走投无路的时候，要求都是很低的，能抓到一点算一点。图2就是抓到的包，看起来一切都很正常：前3个包是三次握手，接着客户端发了个HTTP GET请求，服务器也确认收到了。

既然表面上都是好的，我们再看看每个包的详细信息。1号包的详情见图3，客户端把包交给了一个叫c0:62:6b:e2:bd:88的MAC地址，该地址属于默认网关。将包交给默认网关是合理的，因为Web服务器在另一个子网中，需要路由转发。也就是说，从1号包中没有发现任何异常。 再看看图4的2号包详情。这个包让人眼前一亮，信息量实在太大了。在阅读下面的文字之前，建议你自己先在图中找找亮点。 首先这个包竟然是从MAC地址00:10:f3:27:61:86发过来的，而不是之前提到的默认网关c0:62:6b:e2:bd:88。我不知道这个MAC地址属于什么设备，但这至少说明2号包和1号包走了条不一样的路径。再看其Time to live（TTL）居然是64，理论上经过一次路由的包，TTL应该减去1，变成63才对。根据这两条信息，可以推测管理员提供的拓扑图有误。真正的网络包流向应该接近图5，即客户端发出去的包是经过路由的，而Web服务器发过来的包没经过路由。 其实到这里就可以去找管理员说理了，不过别急，继续往下看。到了图6的第5号包，发现Identification竟然是49031，而同样是来自Web服务器的2号包（见图4）中，Identification却是0。一般发出Identification为0的机器永远都发0，不会一下子跳到49031。也就是说，其实2号包和5号包是两台不同的设备发出来的，这意味着在Web服务器和客户端之间，可能存在一台设备在代理三次握手，而能够代理握手的设备很可能是应对Syn flood攻击的防火墙。 因此图5的拓扑图还不够准确，应该更正成图7的样子。管理员忽视了这台防火墙，可能就错过了发现问题根源的机会。

把以上分析反馈给管理员之后，他果然通过MAC地址00:10:f3:27:61:86找到了一台防火墙。也正是防火墙上的一些错误配置，导致他们遇到了那些诡异症状，改正之后症状就消失了。本文的目的是演示如何在网络包中寻找被掩盖的线索，而不是防火墙知识，所以就不展开了。

从头到尾再复习一下整个过程，是不是很有当侦探的感觉？

注意：

为了保护客户隐私，本文截图里的IP地址和MAC地址都被PS过，这就是为什么有些截图看上去不太自然。本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。