像福爾摩斯一樣偵破Wireshark中的問題

用wireshark排查問題，和偵探破案的思路是一致的。神探福爾摩斯的破案秘訣是“溯因推理”——先觀察所有細(xì)節(jié)，比如鞋根上的泥疙瘩甚至煙灰；然后作出多種推理和假設(shè)；接著刨去各種不可能，最后剩下的“無(wú)論多么難以置信，肯定沒錯(cuò)。”用Wireshark分析網(wǎng)絡(luò)包時(shí)也類似，我們先要在網(wǎng)絡(luò)包中尋找各種線索，然后根據(jù)網(wǎng)絡(luò)協(xié)議作出推理，接著刨去人為（有意或無(wú)意）掩蓋的證據(jù)，才能得到最后的真相。尤其是和保密機(jī)構(gòu)打交道的時(shí)候，工程師進(jìn)不了機(jī)房，文檔也不能公開，所以一切線索只能自己在包里找，感覺就更像破案了。

我最近幫一位讀者解決的問題就非常典型。他供職的機(jī)構(gòu)內(nèi)部網(wǎng)站有時(shí)候會(huì)發(fā)生詭異的現(xiàn)象，比如Web服務(wù)器的端口號(hào)會(huì)隨機(jī)發(fā)生變化（具體癥狀就不多講了，和本文關(guān)系不大）。后來(lái)做了排查，把客戶端和Web服務(wù)器直連，問題就消失了，確認(rèn)了Web服務(wù)器和客戶端都沒有問題。難道根本原因就出在網(wǎng)絡(luò)路徑上了？可是管理員又聲稱網(wǎng)絡(luò)拓?fù)浞浅：?jiǎn)單，不會(huì)出問題的。見圖1，客戶端和Web服務(wù)器在不同的子網(wǎng)里，中間由一個(gè)路由器轉(zhuǎn)發(fā)。

圖1

憑我的經(jīng)驗(yàn)，這個(gè)網(wǎng)絡(luò)拓?fù)涞拇_簡(jiǎn)單到?jīng)]有出問題的可能。可是已經(jīng)到了山窮水盡的地步了，只好抓包試試。Web服務(wù)器不允許我們登錄，所以只能在客戶端抓，更糟糕的是抓包時(shí)那個(gè)詭異的現(xiàn)象并沒有發(fā)生。你一定會(huì)納悶，正常狀況抓的包有什么看頭啊？人在走投無(wú)路的時(shí)候，要求都是很低的，能抓到一點(diǎn)算一點(diǎn)。圖2就是抓到的包，看起來(lái)一切都很正常：前3個(gè)包是三次握手，接著客戶端發(fā)了個(gè)HTTP GET請(qǐng)求，服務(wù)器也確認(rèn)收到了。

圖2

既然表面上都是好的，我們?cè)倏纯疵總€(gè)包的詳細(xì)信息。1號(hào)包的詳情見圖3，客戶端把包交給了一個(gè)叫c0:62:6b:e2:bd:88的MAC地址，該地址屬于默認(rèn)網(wǎng)關(guān)。將包交給默認(rèn)網(wǎng)關(guān)是合理的，因?yàn)閃eb服務(wù)器在另一個(gè)子網(wǎng)中，需要路由轉(zhuǎn)發(fā)。也就是說(shuō)，從1號(hào)包中沒有發(fā)現(xiàn)任何異常。

圖3

再看看圖4的2號(hào)包詳情。這個(gè)包讓人眼前一亮，信息量實(shí)在太大了。在閱讀下面的文字之前，建議你自己先在圖中找找亮點(diǎn)。

圖4

首先這個(gè)包竟然是從MAC地址00:10:f3:27:61:86發(fā)過(guò)來(lái)的，而不是之前提到的默認(rèn)網(wǎng)關(guān)c0:62:6b:e2:bd:88。我不知道這個(gè)MAC地址屬于什么設(shè)備，但這至少說(shuō)明2號(hào)包和1號(hào)包走了條不一樣的路徑。再看其Time to live（TTL）居然是64，理論上經(jīng)過(guò)一次路由的包，TTL應(yīng)該減去1，變成63才對(duì)。根據(jù)這兩條信息，可以推測(cè)管理員提供的拓?fù)鋱D有誤。真正的網(wǎng)絡(luò)包流向應(yīng)該接近圖5，即客戶端發(fā)出去的包是經(jīng)過(guò)路由的，而Web服務(wù)器發(fā)過(guò)來(lái)的包沒經(jīng)過(guò)路由。

圖5

其實(shí)到這里就可以去找管理員說(shuō)理了，不過(guò)別急，繼續(xù)往下看。到了圖6的第5號(hào)包，發(fā)現(xiàn)Identification竟然是49031，而同樣是來(lái)自Web服務(wù)器的2號(hào)包（見圖4）中，Identification卻是0。一般發(fā)出Identification為0的機(jī)器永遠(yuǎn)都發(fā)0，不會(huì)一下子跳到49031。也就是說(shuō)，其實(shí)2號(hào)包和5號(hào)包是兩臺(tái)不同的設(shè)備發(fā)出來(lái)的，這意味著在Web服務(wù)器和客戶端之間，可能存在一臺(tái)設(shè)備在代理三次握手，而能夠代理握手的設(shè)備很可能是應(yīng)對(duì)Syn flood攻擊的防火墻。

圖6

因此圖5的拓?fù)鋱D還不夠準(zhǔn)確，應(yīng)該更正成圖7的樣子。管理員忽視了這臺(tái)防火墻，可能就錯(cuò)過(guò)了發(fā)現(xiàn)問題根源的機(jī)會(huì)。

圖7

把以上分析反饋給管理員之后，他果然通過(guò)MAC地址00:10:f3:27:61:86找到了一臺(tái)防火墻。也正是防火墻上的一些錯(cuò)誤配置，導(dǎo)致他們遇到了那些詭異癥狀，改正之后癥狀就消失了。本文的目的是演示如何在網(wǎng)絡(luò)包中尋找被掩蓋的線索，而不是防火墻知識(shí)，所以就不展開了。

從頭到尾再?gòu)?fù)習(xí)一下整個(gè)過(guò)程，是不是很有當(dāng)偵探的感覺？

注意：

為了保護(hù)客戶隱私，本文截圖里的IP地址和MAC地址都被PS過(guò)，這就是為什么有些截圖看上去不太自然。

本文節(jié)選自《Wireshark網(wǎng)絡(luò)分析的藝術(shù)》。

內(nèi)容簡(jiǎn)介

Wireshark是當(dāng)前最流行的網(wǎng)絡(luò)包分析工具。它上手簡(jiǎn)單，無(wú)需培訓(xùn)就可入門。很多棘手的網(wǎng)絡(luò)問題遇到Wireshark都能迎刃而解。

本書挑選的網(wǎng)絡(luò)包來(lái)自真實(shí)場(chǎng)景，經(jīng)典且接地氣。講解時(shí)采用了生活化的語(yǔ)言，力求通俗易懂，以使讀者在輕松閱讀的過(guò)程中，既可以學(xué)到實(shí)用的網(wǎng)絡(luò)知識(shí)，又能形成解決問題的思路。

與大多網(wǎng)絡(luò)圖書的課堂式體驗(yàn)不同，閱讀本書的感覺更像在聽技術(shù)圈的朋友分享經(jīng)驗(yàn)，除了知識(shí)，還有心情和想法。本書的覆蓋范圍從日常使用的手機(jī)App，到企業(yè)級(jí)的數(shù)據(jù)中心；從對(duì)付運(yùn)營(yíng)商的網(wǎng)絡(luò)劫持，到開發(fā)自己的分析工具，不一而足。無(wú)論你是系統(tǒng)管理員、實(shí)施工程師、技術(shù)支持、網(wǎng)管、培訓(xùn)教師，還是開發(fā)和測(cè)試人員，都適合閱讀本書。

本文轉(zhuǎn)載自異步社區(qū)。

通用安全 高性能計(jì)算

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。