本節書摘來自異步社群《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過，這就是為什麼有些截圖看上去不太自然。
本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。