Wireshark网络分析的艺术 - (EPUB全文下载)

文件大小：0.22 mb。
文件格式：epub 格式。
书籍内容：

Wireshark网络分析的艺术
答读者问
工作中的Wireshark
生活中的Wireshark
两个项目
答读者问
在过去几年中，有不少读者、同事和网友向我咨询过网络问题，其中大部分都记录在案。我一直把这些案例视为珍贵的财富，因为既真实又有广泛的代表性，比我自己在实验室中“制造”出来的好多了。本书从中选择了最经典的部分，希望读者会感兴趣。如果你在工作或生活中遇到网络问题，也欢迎抓个包来找我分析。
Linux为什么卡住了？
到今天为止，已经有5位读者向我求助过这个问题了。症状请看图1，他们通过SSH登录Linux服务器时，输完用户名就卡住了，要等待10秒钟才提示密码输入。这究竟是什么原因导致的呢？其实我也是Linux菜鸟，虽然尝试过搜索“ssh hang”等关键词，但是没找到相关信息。
图1
10秒钟的时间并不算长，吃个薯片喝口咖啡就过去了。但是作为强迫症患者，我还是容不得它的存在，因此便决定写篇文章，向大家演示一下怎样用Wireshark一步步解决这个问题。
首先是抓包，步骤如下。
1．在Linux服务器上启动抓包。
2．从笔记本SSH到Linux服务器，输入用户名并回车。
3．等待10秒左右，直到登录界面提示输入密码。
4．停止抓包。
这样就可以得到一个涵盖该现象的网络包了。一般在实验室中没有干扰流量，不用过滤也可以分析，不过我们最好在做实验时就养成过滤的习惯，以适应生产环境中抓到的包。因为我们是通过SSH协议登录的，所以可以直接用“ssh”来过滤，如图2所示。SSH包都是加密了的，因此我们看不出每个包代表了什么意思，不过这并不影响分析。从图2中可以看到，21号包和25号包之间恰好就相隔10秒。
图2
这两个包之间所发生的事件，可能就是导致这个现象的原因。于是我再用“frame.number> 21 && frame.number< 25”过滤，结果如图3所示。 图3 从图3中可以看到，Linux服务器当时正忙着向DNS服务器查询10.32.200.23的PTR记录（即反向解析），试图获得这个IP地址所对应的域名。该IP属于我们测试所用的笔记本，但由于DNS服务器上没有它的PTR记录，所以两次查询都等了5秒钟还没结果，总共浪费了10秒钟。 我们由此可以推出，这台Linux服务器在收到SSH访问请求时，会先查询该客户端IP所对应的PTR记录。假如经过5秒钟还没有收到回复，就再发一次查询。如果第二次查询还是等了5秒还没回复，就彻底放弃查询。我们甚至可以进一步猜测，如果DNS查询能成功，就不用白等那10秒钟了。 为了验证这个猜测，我在DNS服务器中添加了10.32.200.23的PTR记录，如图4所示，然后再次登录。 图4 这一次果然立即登录进去了。从图5的Wireshark截屏可见，DNS查询是成功的，所以21号包和26号包之间几乎是没有时间停顿的。 图5 明白了DNS查询就是问题的起因，接下来就知道怎么进一步研究了。只要在Google搜索“ssh dns”，第一页出来的链接都是关于这个问题的。随便挑几篇阅读一下，就连我这样的Linux初学者都能把这个问题研究透了。原来这个行为是定义在“/etc/ssh/sshd_config”文件中的，默认配置是这样的： [root@Linux_Server ~]# cat /etc/ssh/sshd_config |grep -i usedns #UseDNS yes 改成下面这样就可以解决了，不用去动DNS服务器上的配置： [root@Linux_Server~]# cat /etc/ssh/sshd_config |grep -i usedns UseDNS no 我经常说技能比知识更重要，这就是例子之一。学会了使用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 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。