用逆向方法：排除一例 NFS （網路檔案系統）罕見故障
- 前言
- NFS 卡住了
- tcpdump 抓包
- 像福爾摩斯一樣思考
- 參考
?作者：高玉涵
?時間：2021.12.20 09:47
?博客：blog.csdn.net/cg_i
?環境：
?1 號機： HP-UX B.11.31 U ia64
?2 號機：Linux 4.19.90-24.4.v2101.ky10.x86_64
前言
?手頭專案需要 HP-UX 和 LINUX 系統，遠程訪問同一存盤，系統部同事給出的辦法是，使用 Sun 的網路檔案系統（NFS）協議，NFS 協議被設計為適合于不同的機器、作業系統、網路體系和傳輸協議，此協議的實作已存在于上述系統上（NFSv3），且允許把遠程目錄鏈接到本地檔案系統進行透明的遠程訪問（客戶端訪問該共享與訪問本地檔案系統沒有任何差別），
NFS 卡住了
?癥狀描述：HP-UX 能正常掛載、卸載共享，掛載共享后，能進入目錄（CD）、創建目錄（MKDIR）、創建檔案（TOUCH 1.txt）、寫入檔案（ECHO “2” >> 1.txt）、洗掉檔案或目錄（RM），但，詭異的是瀏覽（LS）檔案或目錄時，命令會被無限掛起，只能用 CTRL+C 強行中斷，而 LINUX 系統下訪問共享一切正常，
?這究竟是什么原因導致的呢？其實我也是 HP-UX 菜鳥，雖然嘗試過全網搜索 “nfs hang” 等關鍵詞，但是沒找到相關資訊，走投無路之下，就只能硬肯 RFC 檔案，通過 tcpdump 抓包，并用 WireShark 分析每一個網路包，
tcpdump 抓包
?從圖 2 中 info 一欄可以看到 WireShark 已經提供了詳細的決議，不過這里我翻譯成更直白的對話，
- mount -F nfs 192.168.0.200:/hxxt /nasdata（掛載共享目錄）
包號 1 和 2（見圖 2）：
客戶端：我想連接你的 NFS 行程，應該用哪個埠啊？
服務端：我的 NFS 埠是 2050
包號 3 和 4（見圖 2）：
客戶端：那我試一下 NFS 行程能否連上，
服務端：收到了，能連上，
包號 7 和 8（見圖 2）：
客戶端：我想連接你的 MOUNT 服務，應該用哪個埠啊？
服務端：我的 MOUNT 埠號是 2049 ，
包號 11 和 13（見圖 2）：
客戶端：那我試一下 MOUNT 行程能否連上，
服務端：收到，能連上，
包號 5 和 6（見圖 2）：
客戶端：我要掛載 /hxxt 共享目錄，
服務端：你的請求被批準了，以后請用 FileHandle：0xf2bf1c8c 來訪問本目錄（見圖 3），
包號 19 和 21（見圖 2）：
客戶端：我想看看這個檔案系統的屬性，
服務端：給，都在這里，
?以上便是 NFS 掛載的全程序，可以看到 Portmap 和 MOUNT 請求都得到及時回應，說明網路通暢服務正常，即然問題出在瀏覽檔案或目錄上（LS），那就應該檢查該共享的訪問控制，
- touch f.txt（root 用戶創建一個新檔案）
?NFS 安全機制設定較為簡單，對客戶端的訪問、對用戶權限的控制，都是通過 IP 地址來實作的，創建共享目錄時，可以指定哪些 IP 允許讀寫、哪些 IP 只允許讀，還有哪些 IP 連掛載都不允許，
包號 42 和 43：（見圖 4）
客戶端：我要在路徑 0xcc292702 內創建一個新檔案，它的名字叫 f.txt，還有我的 UID： 0 ，GID：3 （見圖 5），
服務端：收到，允許創建，
?圖 5 的 Credentials 資訊可知，客戶端A用戶創建檔案時并未使用 root 這個用戶名，而是用了 root 的 UID：0 來代表自己的身份（用戶名與 UID 對應關系是由客戶端 /ect/passwd 決定的），也就是說 NFS 協議是用 UID 來區分用戶的，當 root 通過客戶端創建一個檔案其 UID：0 就會被寫到檔案里，成為 owner 資訊，
?而當客戶端B上的用戶查看該檔案屬性時，看的其實也是 UID：0 ，如果客戶端B上的 /etc/passwd 檔案和客戶端A上的不一樣，或顯示客戶端B對應的用戶名稱，或只顯示 UID 數值，為了防止這類問題，建議用戶和 UID 的關系在每臺客戶端上都保持一致，
- ls -al（查看所有檔案或目錄）
（圖 6）
?圖 6 所示客戶端能及時收到回應，查看回應包內容資訊也正常，較為明顯的是，明明我只執行了一次命令，而機器確不斷重復發送、接收包，就如同進入“死回圈”一樣，這就不難解釋在用戶界面下，操作被掛起，直能通過 CTRL+C 強行中斷操作了，
像福爾摩斯一樣思考
?神探福爾摩斯的破案秘訣是“逆因推理”——先觀察所有細節，比如鞋根上的泥疙瘩甚至煙灰；然后作出多種推理和假設；接著刨去各種不可能，最后剩下的“無論多么難以置信，肯定沒錯，”用 WireShark 分析網路包時也類似，我們先要在網路包中尋找各種線索，然后根據網路協議作出推理，接著刨去人為（有意或無意）掩蓋的證據，才能得到最后的真想，尤其是進不了機房，找不到檔案，所以一切線索只能自己在包里找，感覺就更像破案了，
?既然資料包正常，那最大嫌疑就是 LS 這個命令了，會不會是 LS 無法識別回應的資料包呢？我知道這種概率很小，但概率小不代表不會發生，LS 命令的操作和內核有關，而命令引數與回傳值與字串有關，字串又和系統字符集有關，為了驗證這種猜想，我使用 locale 命令，查詢當前系統支持的所有字符集，并挑選 en_GB.utf8 設定為當前用戶默認的字符集，
locale -a （查詢到系統當前支持的字符集）
export LANG="en_GB.utf8"
?故障排除！困擾了我數周的問題終于解決了！高興啊！
注：我查看了一下 LINUX 的機器，它默認環境是使用 zh_CN.UTF-8，我初次將 HP-UX 也設定成和它一樣的但故障依舊，通過設定成 en_GB.utf8 后正常，
參考
- RFC 1831
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/389296.html
標籤：其他
上一篇：程式員必備的5個自媒體工具
下一篇：Linux相關的內容（一）