详情
本书是最有趣、有料的Wireshark数据包分析实用技巧图书，本书通过多个常见的示例剖析了Wireshark的强大功能，并借助Wireshark通过抓包分析的方式来帮助大家学习、掌握TCP/IP、DNS、HTTP等技术的精髓；最后通过几个实用的案例，帮助大家进一步掌握Wireshark的一些高级功能。
我每次当面试官，都要伪装成无所不知的大牛。
这当然是无奈的选择——现在每封简历都那么耀眼，不装一下简直镇不住场面。比如尚未毕业的本科生，早就拿下CCIE认证；留欧两年的海归，已然精通英、法、德三门外语；最厉害的一位应聘者，研究生阶段就在国际上首次提出了计算机和生物学的跨界理论……可怜我这个老实人在一开场还能装装，到了技术环节就忍不住提问基础知识，一下子把气氛从学术殿堂拉到建筑工地。不过就是这些最基础的问题，却常常把简历精英们难住。本文要介绍的便是其中的一道。
问题：两台服务器A和B的网络配置如下（见图1），B的子网掩码本应该是255.255.255.0，被不小心配成了255.255.255.224。它们还能正常通信吗？
很多应聘者都会沉思良久（他们一定在心里把我骂了很多遍了），然后给出下面这些形形色色的答案。
答案1：“A和B不能通信，因为……如果这样都行的话，子网掩码还有什么用？”（这位的反证法听上去很有道理！）
答案2：“A和B能通信，因为它们可以通过ARP广播获得对方的MAC地址。”（那子网掩码还有什么用？楼上的反证法用来反驳这位正好。）
答案3：“A和B能通信，但所有包都要通过默认网关192.168.26.2转发。”（请问这么复杂的结果你是怎么想到的？）
答案4：“A和B不能通信，因为ARP不能跨子网。”（这个答案听上去真像是经过认真思考的。）
以上哪个答案是正确的？还是都不正确？如果这是你第一次听到这道题，不妨停下来思考一下。
真相只有一个，应聘者的答案却是五花八门。可见对网络概念的理解不容含糊，否则差之毫厘，谬以千里。要知道，这还只是基本的路由交换知识，假如涉及复杂概念，结果就更不用说了。
问题是即便我们对着教材咬文嚼字，也不一定能悟出正确答案。这个时候，就可以借助Wireshark的抓包与分析功能了。我手头就有两台Windows服务器，已经按照面试题配好网络。如果你以前没有用过Wireshark，就开始第一次亲密接触吧。
1．从http://www.wireshark.org/download.html免费下载安装包，并在服务器B上装好（把所有可选项都装上）。
2．启动Wireshark软件，单击菜单栏上的Capture，再单击Interfaces按钮（见图2）。
3．服务器B上的所有网卡都会显示在弹出的新窗口上（见图3），在要抓包的网卡上单击Start按钮。
4．在服务器B上ping A的IP地址，结果是通的（见图4）。该操作产生的网络包已经被Wireshark捕获。
5．在Wireshark的菜单栏上，再次单击Capture，然后单击Stop。
6．在Wireshark的菜单栏上，单击File，再单击Save，把网络包保存到硬盘上（这一步并非必需，但存档是个好习惯）。
7．收集每台设备的MAC地址以备分析。
• 服务器B: 00:0c:29:51:f1:7b
• 默认网关: 00:50:56:e7:2f:88
现在可以分析网络包了。如图5所示，Wireshark的界面非常直观。最上面是Packet List窗口，它列出了所有网络包。在Packet List中选定的网络包会详细地显示在中间的Packet Details窗口中。由于我在Packet List中选定的是3号包，所以图5中看到的就是Frame 3的详情。最底下是Packet Bytes Details窗口，我们一般不会用到它。
接下来看看每个包都做了些什么。
1号包（见图6）：
服务器B通过ARP广播查询默认网关192.168.26.2的MAC地址。为什么我ping的是服务器A的IP，B却去查询默认网关的MAC地址呢？这是因为B根据自己的子网掩码，计算出A属于不同子网，跨子网通信需要默认网关的转发。而要和默认网关通信，就需要获得其MAC地址。
默认网关192.168.26.2向B回复了自己的MAC地址。为什么这些MAC地址的开头明明是“00:50:56”或者“00:0c:29”，Wireshark上显示出来却都是“Vmware”？这是因为MAC地址的前3个字节表示厂商。而00:50:56和00:0c:29都被分配给Vmware公司。这是全球统一的标准，所以Wireshark干脆显示出厂商名了。
3号包（见图8）：
B发出ping包，指定Destination IP为A，即192.168.26.129。但Destination MAC却是默认网关的00:50:56:e7:2f:88（Destination MAC可以在图8中的Packet Details中看到）。这表明B希望默认网关把包转发给A。至于默认网关有没有转发，我们目前无从得知，除非在网关上也抓个包。
4号包（见图9）：
B收到了A发出的ARP广播，这个广播查询的是B的MAC地址。这是因为在A看来，B属于相同子网，同子网通信无需默认网关的参与，只要通过ARP获得对方MAC地址就行了。这个包也表明默认网关成功地把B发出的ping请求转发给A了，否则A不会无缘无故尝试和B通信。
B回复了A的ARP请求，把自己的MAC地址告诉A。这说明B在执行ARP回复时并不考虑子网。虽然ARP请求来自其他子网的IP，但也照样回复。
6号包（见图11）：
B终于收到了A的ping回复。从MAC地址00:0c:29:0c:22:10可以看出，这个包是从A直接过来的，而不是通过默认网关的转发。
7、8、9、10号包（见图12）：
都是重复的ping请求和ping回复。因为A和B都已经知道对方的联系方式，所以就没必要再发ARP了。
分析完这几个包，答案出来了。原来通信过程是这样的：B先把ping请求交给默认网关，默认网关再转发给A。而A收到请求后直接把ping回复给B，形成图13所示的三角形环路。不知道你答对了吗？
通过这道题，不知道你是否已经感受到了Wireshark的神奇？如果有兴趣进一步练习，不妨也搭个环境，把这道题里A和B的掩码互换一下。看看这次还能ping通吗？如果不能，原因又在哪里？
其实做题对Wireshark只是大材小用，它还可以用于学习复杂的协议，或者解决隐蔽的难题。在下文中，我们将体验Wireshark在实际工作中的应用。
我的老板气宇轩昂，目光笃定，在人群中颇有大将风范（当然是老板娘不在场的时候）。有一年我们在芝加哥流落街头，也没见他皱过眉头。不过前几天，这位气场型领导竟然板着脸跑过来，说赶紧帮忙，有位同事被客户骂惨了。我当然不能拒绝帮（yao）助（qiu）同（jia）事（xin）的机会，立即加入电话会议。
原来事情是这样的：客户不小心重启了服务器A，然后它就再也无法和服务器B通信了。由于这两台服务器之间传输的是关键数据，现场工程师又一时查不出原因，所以客户异常恼火。
问题听起来并不复杂，考虑到起因是服务器A的重启，所以我收集了它的网络配置（见图1）。
服务器B的网络配置则简单很多，只有一个IP地址192.168.182.131，子网掩码也是255.255.255.0。
当我们在A上ping B时，网络包应该怎么走？阅读以下内容之前，读者不妨先停下来思考一下。
一般情况下，像A这类多IP的服务器是这样配路由的：假如自身有一个IP和对方在同一子网，就从这个IP直接发包给对方。假如没有一个IP和对方同子网，就走默认网关。在这个环境中，A的3个IP显然都与B属于不同子网，那就应该走默认网关了。会不会是A和默认网关的通信出问题了呢？我从A上ping了一下网关，结果却是通的。难道是因为网关没有把包转发出去？或者是ping请求已经被转发到B了，但ping回复在路上丢失？我感觉自己已经走进死胡同。每当到了这个时候，我就会想到最值得信赖的队友——Wireshark。
我分别在eth0、eth1、和eth2上抓了包。最先查看的是连接默认网关的eth0，出乎意料的是，上面竟然一个相关网络包都没有。而在eth1上抓的包却是图2的表现: A正通过ARP广播查找B（192.168.182.131）的MAC地址，试图绕过默认网关直接与B通信。这说明了什么问题呢？
这说明A上存在一项符合192.168.182.131的路由，促使A通过eth1直接与B通信。我赶紧逐项检查路由表，果然发现有这么一项（见图3）：
因为192.168.182.131属于192.168.182.0/255.255.255.0，所以就会走这条路由。由于不同子网所配的VLAN也不同，所以这些ARP请求根本到达不了B。ping包就更不用说了，它从来就没发出来过。客户赶紧删除了这条路由，两台服务器的通信也随即恢复。
为什么A重启之后会多了这条莫名其妙的路由呢？根据客户回忆，他们以前的确是配过该路由的，后来删掉了，不知道为什么配置文件里还留着。今天的重启加载了一遍配置文件，所以这条路由又出现了。你也许会问，为什么不从一开始就仔细检查路由表呢？这样就不至于走错胡同，连抓包和Wireshark都省了。我当时也是这样反省的，但现实中要做到并不容易。且不说一开始并没有怀疑到路由表，就算怀疑了也不一定能看出问题来。在这个案例中，系统管理员和现场工程师都检查过路由表，但无一例外地忽略了出问题的一项。这是因为真实环境中的路由表有很多项，在紧张的电话会议上难以注意到多出了异常的一项。而且子网掩码也不是255.255.255.0那么直观。假如本文所用的IP保持不变，但子网掩码变成255.255.248.0，路由表就成了图4所示的样子。
在这个输出中，难以一眼注意到192.168.176.0就适用于目标地址192.168.182.131，至少对我来说是这样的。
我们能从这个案例中学习到什么呢？最直接的启示便是翻出简历，投奔甲方去。这样就可以在搞砸系统的时候，义正词严地要求乙方解决了。假如你固执地想继续当乙方，那就开始学习Wireshark吧。再有经验的工程师也有犯迷糊的时候，而Wireshark从来不会，它随时随地都能告诉你真相，不偏不倚。
当我们在Notepad等文本编辑器上单击File-->Save的时候，底层的操作非常简单—编辑器上的内容被直接写入文件了（见图1）。假如这个文件是被保存到了网络盘上，我们就可以从Wireshark抓包上看到这个过程（见图2）。
包号58：
客户端：“我要写6个字节到/Temp/wireshark.txt中”。
包号59：
服务器：“写好了。”
相比之下，微软Office保存文件的过程就没有这么简单了，所以微软的老用户都或多或少经历过保存文件时发生的问题。比如图3中的Excel提示信息就很常见，它说明该文件被占用，暂时保存不了。这样的问题在Notepad上是不会发生的。
那么，Excel究竟是如何保存文件的呢？虽然我的手头没有微软的文档，但只要把文件保存到网络盘上，就可以借助Wireshark看到整个过程了。我在实验室中编辑了Excel文件“wireshark.xlsx”，然后在保存时抓了个包，我们一起来分析其中比较关键的几个步骤（见图4）：
这几个包可以解析为下述过程。
24号包：
客户端：“/Temp目录中存在一个叫DCD652B.tmp的文件吗？”
25号包：
服务器：“不存在。”
26号包：
客户端：“那我要创建一个叫DCD652B.tmp的文件。”
27号包：
服务器：“建好了。”
38号包：
客户端：“把Excel里的内容写到DCD652B.tmp里。”
42号包：
服务器：“写好了。”
从以上过程可见，Excel并没有直接把文件内容存到wireshark.xlsx上，而是存到一个叫DCD652B.tmp的临时文件上了。接下来再看（见图5）。
47号包：
客户端：“/Temp目录里存在一个叫6AF04530.tmp的文件吗？”
48号包：
服务器：“不存在。”
97号包：
客户端：“那好，把原来的wireshark.xlsx重命名成6AF04530.tmp。”
98号包：
服务器：“重命名完毕。”
103号包：
客户端：“再把一开始那个临时文件DCD652B.tmp重命名成wiresahrk.xlsx。”
104号包：
服务器：“重命名完毕。”
从以上过程可知，原来的wireshark.xlsx被重命名成一个临时文件，叫6AF04530.tmp。而之前创建的那个临时文件DCD652B.tmp又被重命名成wireshark.xlsx。经过以上步骤之后，我们拥有一个包含新内容的wireshark.xlsx，还有一个临时文件6AF04530.tmp（也就是原来那个wireshark.xlsx）。接着往下看，就发现6AF04530.tmp被删除了（见图6）。
微软把保存过程设计得如此复杂，自然是有很多好处的。不过复杂的设计往往伴随着更多出问题的概率，因为其中一步出错就意味着保存失败。比如上文提到的报错信息“…is currently in use. Try again later”，大多数时候的确是文件被占用才触发的，但也有时候是Excel bug或者杀毒软件导致的。无论出于何种原因，我们只有理解了保存时发生的细节，才可能探究到真相。
Wireshark正是获得这些细节的通用法宝，任何经过网络所完成的操作，我们都可以从Wireshark中看到。有了这样的利器，还有多少问题能难住你？
