‘wireshark是什么’可以卸载吗?…

用Wireshark调查问题与侦探破案的想法一致。福尔摩斯破案的秘诀是观察所有细节，比如《逆人推理》——首先沾在鞋根上的疙瘩，甚至是烟灰。然后做各种推理和假设。然后削掉各种不可能，最后剩下的是“不管多难相信，一定没错。”说。

”用Wireshark分析网络包时也类似，我们先要在网络包中寻找各种线索，然后根据网络协议作出推理，接着刨去人为（有意或无意）掩盖的证据，才能得到最后的真相。尤其是和保密机构打交道的时候，工程师进不了机房，文档也不能公开，所以一切线索只能自己在包里找，感觉就更像破案了。

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

图1

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

图2

既然表面上都是好的，我们再看看每个包的详细信息。1号包的详情见图3，客户端把包交给了一个叫c0:62:6b:e2:bd:88的MAC地址，该地址属于默认网关。将包交给默认网关是合理的，因为Web服务器在另一个子网中，需要路由转发。也就是说，从1号包中没有发现任何异常。

图3

再看看图4的2号包详情。这个包让人眼前一亮，信息量实在太大了。在阅读下面的文字之前，建议你自己先在图中找找亮点。

图4

首先这个包竟然是从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服务器发过来的包没经过路由。

图5

其实到这里就可以去找管理员说理了，不过别急，继续往下看。到了图6的第5号包，发现Identification竟然是49031，而同样是来自Web服务器的2号包（见图4）中，Identification却是0。一般发出Identification为0的机器永远都发0，不会一下子跳到49031。也就是说，其实2号包和5号包是两台不同的设备发出来的，这意味着在Web服务器和客户端之间，可能存在一台设备在代理三次握手，而能够代理握手的设备很可能是应对Syn flood攻击的防火墙。

图6

因此图5的拓扑图还不够准确，应该更正成图7的样子。管理员忽视了这台防火墙，可能就错过了发现问题根源的机会。

图7

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

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

注意：

为了保护客户隐私，本文截图里的IP地址和MAC地址都被PS过，这就是为什么有些截图看上去不太自然。


本文节选自《Wireshark网络分析的艺术》。

内容简介

Wireshark是当前最流行的网络包分析工具。它上手简单，无需培训就可入门。很多棘手的网络问题遇到Wireshark都能迎刃而解。

本书挑选的网络包来自真实场景，经典且接地气。讲解时采用了生活化的语言，力求通俗易懂，以使读者在轻松阅读的过程中，既可以学到实用的网络知识，又能形成解决问题的思路。

与大多网络图书的课堂式体验不同，阅读本书的感觉更像在听技术圈的朋友分享经验，除了知识，还有心情和想法。本书的覆盖范围从日常使用的手机App，到企业级的数据中心；从对付运营商的网络劫持，到开发自己的分析工具，不一而足。无论你是系统管理员、实施工程师、技术支持、网管、培训教师，还是开发和测试人员，都适合阅读本书。