本節書摘來自異步社群《wireshark網絡分析的藝術》一書中的linux為什麼卡住了？，作者林沛滿,更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
linux為什麼卡住了？
wireshark網絡分析的藝術
到今天為止，已經有5位讀者向我求助過這個問題了。症狀請看圖1，他們通過ssh登入linux伺服器時，輸完使用者名就卡住了，要等待10秒鐘才提示密碼輸入。這究竟是什麼原因導緻的呢？其實我也是linux菜鳥，雖然嘗試過搜尋“ssh hang”等關鍵詞，但是沒找到相關資訊。
10秒鐘的時間并不算長，吃個薯片喝口咖啡就過去了。但是作為強迫症患者，我還是容不得它的存在，是以便決定寫篇文章，向大家示範一下怎樣用wireshark一步步解決這個問題。
首先是抓包，步驟如下。
1．在linux伺服器上啟動抓包。
2．從筆記本ssh到linux伺服器，輸入使用者名并回車。
3．等待10秒左右，直到登入界面提示輸入密碼。
4．停止抓包。
這樣就可以得到一個涵蓋該現象的網絡包了。一般在實驗室中沒有幹擾流量，不用過濾也可以分析，不過我們最好在做實驗時就養成過濾的習慣，以适應生産環境中抓到的包。因為我們是通過ssh協定登入的，是以可以直接用“ssh”來過濾，如圖2所示。ssh包都是加密了的，是以我們看不出每個包代表了什麼意思，不過這并不影響分析。從圖2中可以看到，21号包和25号包之間恰好就相隔10秒。
這兩個包之間所發生的事件，可能就是導緻這個現象的原因。于是我再用“frame.number> 21 && frame.number< 25”過濾，結果如圖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所示，然後再次登入。
這一次果然立即登入進去了。從圖5的wireshark截屏可見，dns查詢是成功的，是以21号包和26号包之間幾乎是沒有時間停頓的。
明白了dns查詢就是問題的起因，接下來就知道怎麼進一步研究了。隻要在google搜尋“ssh dns”，第一頁出來的連結都是關于這個問題的。随便挑幾篇閱讀一下，就連我這樣的linux初學者都能把這個問題研究透了。原來這個行為是定義在“/etc/ssh/sshd_config”檔案中的，預設配置是這樣的：
改成下面這樣就可以解決了，不用去動dns伺服器上的配置：
我經常說技能比知識更重要，這就是例子之一。學會了使用wireshark，其他知識也會跟着來的。
本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。