簡介Wireshark 數(shù)據(jù)包分析實戰(zhàn)第3版中的一節(jié)故障排查案例適合網(wǎng)絡(luò)運維、安全分析與協(xié)議學(xué)習(xí)人員參考。內(nèi)容圍繞分公司工作站訪問總部應(yīng)用失敗的場景演示如何從 DNS A 記錄查詢響應(yīng)入手利用 Wireshark 抓包逐層定位問題先是 DNS 服務(wù)器返回 server failure隨后分公司 DNS 通過 TCP 53 端口與總部 DNS 通信SYN 包未獲回應(yīng)說明區(qū)域傳送失敗最終經(jīng)過中心辦公室流量嗅探和路由器配置檢查發(fā)現(xiàn)路由器僅放行 UDP 53 而阻斷 TCP 53導(dǎo)致 DNS 區(qū)域傳送無法完成。案例將 DNS 查詢機制、區(qū)域傳送原理、TCP/UDP 差異與抓包分析思路相結(jié)合有助于提升真實網(wǎng)絡(luò)故障的診斷能力。資源為 1 個 PDF 格式文檔大小 644KB已有 327 人學(xué)習(xí)。讀者可從中獲得完整排查路徑和協(xié)議細(xì)節(jié)解讀適合作為數(shù)據(jù)包分析入門或進階時的輔助材料。1. 一個 DNS SERVFAIL 就能讓整個分公司癱瘓先搞清故障鏈條再動手DNS 故障是網(wǎng)絡(luò)排錯里最折磨人的一類服務(wù)器明明活著、應(yīng)用日志一片干凈、客戶端卻集體報“連不上”瀏覽器轉(zhuǎn)幾圈最后給你一個“無法解析服務(wù)器地址”。很多運維的第一反應(yīng)是重啟 DNS 服務(wù)、改 hosts、甚至重裝客戶端結(jié)果折騰一整天問題照舊。這套路我太熟悉了——直到打開 Wireshark 抓到前兩個數(shù)據(jù)包才發(fā)現(xiàn)一切表象都指向一條被忽略的鏈路。本文復(fù)盤的就是某抓包分析實戰(zhàn)手冊里一個經(jīng)典案例工作站訪問總部應(yīng)用服務(wù)器失敗第一包 DNS 查詢返回“服務(wù)器故障”根因卻藏在 53 端口 TCP 流量被路由器丟棄這個細(xì)節(jié)里。適合正在被 DNS 解析失敗、區(qū)域傳送異常、SERVFAIL 報錯卡住的網(wǎng)絡(luò)工程師和運維同學(xué)。2. 現(xiàn)象初判A 記錄查詢返回服務(wù)器故障先確認(rèn)不是客戶端“玄學(xué)”問題2.1 原始抓包里到底發(fā)生了什么兩個數(shù)據(jù)包還原故障起點先看場景工作站172.16.16.101試圖訪問托管在總部應(yīng)用服務(wù)器172.16.16.200上的應(yīng)用程序捕獲文件里只有兩個數(shù)據(jù)包。第一個包是工作站發(fā)給 DNS 服務(wù)器172.16.16.251的 DNS 請求查詢應(yīng)用服務(wù)器的 A 記錄——也就是把應(yīng)用服務(wù)器的域名解析成172.16.16.200這個 IP。第二個包是 DNS 響應(yīng)應(yīng)答碼卻是“服務(wù)器故障”SERVFAIL整包只有錯誤標(biāo)志沒有攜帶任何查詢結(jié)果。打開抓包文件后我一般先用下面的命令快速還原這兩個包的輪廓tshark -r capture.pcap -Y dns -T fields \ -e frame.number -e ip.src -e ip.dst \ -e dns.qry.name -e dns.qry.type -e dns.flags.rcode執(zhí)行后你會看到類似這樣兩行第一行是172.16.16.101 → 172.16.16.251的查詢dns.qry.type為1A 記錄第二行是響應(yīng)包dns.flags.rcode為2。這里-Y dns過濾出所有 DNS 報文-e指定要打印的字段dns.flags.rcode就是應(yīng)答碼字段?？吹?rcode 為 2基本可以確認(rèn)問題出在 DNS 解析鏈路本身而不是客戶端配置或應(yīng)用層故障。2.2 別把 SERVFAIL 當(dāng)成“服務(wù)器宕機”應(yīng)答碼是定位的第一把鑰匙很多同學(xué)看到“服務(wù)器故障”幾個字就慌了直接判斷是 DNS 服務(wù)器掛了。這個誤判在實戰(zhàn)中出現(xiàn)的頻率極高。DNS 應(yīng)答碼RCODE是排查時的第一把鑰匙常見取值就三個RCODE含義典型場景0NOERROR查詢成功能拿到解析結(jié)果2SERVFAILDNS 服務(wù)器無法完成查詢通常是上游鏈路或權(quán)威數(shù)據(jù)問題3NXDOMAIN域名確實不存在關(guān)鍵區(qū)別在于SERVFAIL 意味著 DNS 服務(wù)器“想查但查不到”服務(wù)器進程本身是活著的NXDOMAIN 才是域名本身不存在。這個案例里 DNS 服務(wù)器能正?；貞?yīng)查詢說明它在線真正斷掉的是它獲取解析數(shù)據(jù)的鏈條。如果此時你去重啟 DNS 服務(wù)相當(dāng)于對著錯誤的方向開火問題當(dāng)然不會消失。所以收到 SERVFAIL 第一步不是動服務(wù)而是把排查焦點移到“服務(wù)器是從哪里拿到這些記錄的”。2.3 為什么要切換端口鏡像而不是拔線插嗅探器確定了問題在 DNS 鏈路后手冊里做了一個很關(guān)鍵的操作把嗅探器留在原地只改變交換機端口鏡像設(shè)置。很多人習(xí)慣直接拔掉網(wǎng)線把嗅探器插到 DNS 服務(wù)器上這在生產(chǎn)環(huán)境里是高風(fēng)險動作——會中斷業(yè)務(wù)流量而且如果 DNS 服務(wù)器是虛擬機你根本沒地方插線。端口鏡像SPAN的作用是把交換機某個端口的流量復(fù)制一份給監(jiān)聽端口不影響原始流量轉(zhuǎn)發(fā)是生產(chǎn)環(huán)境抓包的默認(rèn)姿勢。這一步的意義在于對分公司來說客戶端發(fā)出的 DNS 請求最終由172.16.16.251這臺 DNS 服務(wù)器負(fù)責(zé)迭代解析。要看清這臺服務(wù)器為什么回 SERVFAIL就必須把嗅探目標(biāo)從客戶端網(wǎng)段切到 DNS 服務(wù)器所在網(wǎng)段。捕獲結(jié)果保存為stranded_branchdns.pcap這個文件里多出來的那個“怪異”數(shù)據(jù)包才是整個故障的真正突破口。3. 根因深挖看到 TCP 53 的 SYN 數(shù)據(jù)包故障性質(zhì)就變了3.1 DNS 為什么突然走 TCP大響應(yīng)、EDNS 與區(qū)域傳送三種場景打開stranded_branchdns.pcap后除了之前看到的查詢和響應(yīng)還多了一個額外數(shù)據(jù)包。這個包看起來非常“違和”它嘗試與中心辦公室的首選 DNS 服務(wù)器172.16.16.250的標(biāo)準(zhǔn) DNS 服務(wù)端口 53 通信但協(xié)議類型不是我們熟悉的 UDP而是 TCP并且是一個干凈的 SYN 握手包。在大多數(shù)人的認(rèn)知里DNS 就等于 UDP 53看到 TCP 53 的包第一反應(yīng)是“是不是有什么非法掃描流量混進來了”。實際上 DNS 走 TCP 有三種正經(jīng)場景一是 DNS 響應(yīng)超過 UDP 承載上限通常是 512 字節(jié)啟用 EDNS 后可能更大二是 DNS 區(qū)域傳送Zone Transfer用于在 DNS 服務(wù)器之間同步資源記錄三是某些解析器主動選擇 TCP 重試。對照這個案例分公司 DNS 服務(wù)器向總部 DNS 服務(wù)器發(fā)起 TCP 連接方向是“服務(wù)器對服務(wù)器”且沒有先看到大體積 UDP 響應(yīng)基本可以斷定這不是普通查詢而是區(qū)域傳送。tshark -r stranded_branchdns.pcap -Y tcp.port 53 \ -T fields -e frame.number -e ip.src -e ip.dst \ -e tcp.flags.syn -e tcp.flags.ack這條命令過濾出所有 53 端口的 TCP 包重點看 SYN 和 ACK 標(biāo)志位。如果只看到syn1, ack0的包而沒有對應(yīng)的syn1, ack1響應(yīng)說明 TCP 三次握手壓根沒建立起來。TCP 不像 UDP 那樣“發(fā)了就不管”握手失敗是一個強信號——要么包沒到對端要么對端拒絕連接。3.2 SYN 發(fā)出后沒有任何 ACK 響應(yīng)最可能丟在中間鏈路區(qū)域傳送為什么會失敗從協(xié)議層面看TCP 連接建立失敗只有三種可能源端沒發(fā)出、中間網(wǎng)絡(luò)丟棄、目的端拒絕。源端這里已經(jīng)看到 SYN 包了可以排除目的端如果活著且服務(wù)正常一般會回 RST 或 SYN-ACK而不是完全沉默。剩下的最大嫌疑就是中間鏈路——也就是連接分公司和中心辦公室的路由器。這里有一個實戰(zhàn)中容易犯的方向性錯誤一看到 TCP 握手失敗就去查 DNS 服務(wù)器配置、查區(qū)域傳送權(quán)限設(shè)置這屬于檢查“服務(wù)端愿不愿意接”。但更常見的情況是包根本就沒到服務(wù)端。判斷方法很簡單在總部 DNS 服務(wù)器入方向再抓一次包。如果總部那邊完全看不到這個 SYN問題就百分百在中間路由器上而不是 DNS 服務(wù)器本身。手冊里明確提到“沒有給出中心辦公室 DNS 服務(wù)器的流量捕獲文件因為根本就沒有”——這句話翻譯過來就是SYN 數(shù)據(jù)包從未到達服務(wù)器中間設(shè)備是唯一的嫌疑對象。3.3 區(qū)域傳送失敗如何傳導(dǎo)成客戶端的 SERVFAIL把整條故障鏈串起來就非常清晰了分公司用戶訪問總部應(yīng)用服務(wù)器需要先解析應(yīng)用服務(wù)器的域名。分公司 DNS 服務(wù)器是總部 DNS 服務(wù)器的從屬服務(wù)器它沒有獨立維護這些記錄而是依賴從總部同步資源記錄?？偛?DNS 服務(wù)器是被查詢應(yīng)用的權(quán)威 DNS 服務(wù)器。分公司 DNS 服務(wù)器要完成解析必須先把總部那邊的 A 記錄“搬”到自己這里這個過程就是區(qū)域傳送。區(qū)域傳送走 TCP 53SYN 包被路由器丟棄導(dǎo)致分公司 DNS 服務(wù)器一直缺少應(yīng)用服務(wù)器的 A 記錄。客戶端來查詢時分公司 DNS 服務(wù)器手里沒有數(shù)據(jù)、上游也同步不下來只能回一個 SERVFAIL。這條鏈路解釋了為什么客戶端看到的是“服務(wù)器故障”而不是“超時”——分公司 DNS 服務(wù)器確實響應(yīng)了只是它給不出答案。排查這類問題一定要順著“數(shù)據(jù)從哪來”這個思路走而不是盯著最后那一跳的響應(yīng)結(jié)果發(fā)呆。4. 逐段定位與修復(fù)SYN 沒到總部服務(wù)器問題鎖定路由器 ACL4.1 分段抓包法包在哪一段消失故障就在哪一段前面網(wǎng)絡(luò)是黑匣子分段抓包是打開黑匣子的唯一方式。我的排查順序固定如下客戶端網(wǎng)段抓包確認(rèn)請求發(fā)出、響應(yīng)返回的情況這里是 SERVFAIL。分公司 DNS 服務(wù)器網(wǎng)段抓包確認(rèn)它是否向上游發(fā)起查詢或區(qū)域傳送這里看到 TCP SYN?？偛?DNS 服務(wù)器入方向抓包確認(rèn)包是否抵達這里什么都抓不到說明中間斷了。路由器兩側(cè)分別抓包定位丟棄點。第五步是最終實錘。在這個案例里分公司 DNS 服務(wù)器的 SYN 包沒有到達總部服務(wù)器那么問題必然出在兩個辦公室之間的路由器上。判斷依據(jù)不需要復(fù)雜的工具只要在路由器入口、出口各做一次鏡像對比兩次抓包結(jié)果包在哪個方向“消失”問題就在哪個方向的那臺設(shè)備。4.2 實錘路由器只放行了 UDP 53把 TCP 53 靜默丟棄技術(shù)員查看路由器配置后找到了罪魁禍?zhǔn)字行霓k公室的路由器被配置成只允許 53 端口的 UDP 流量進入而 53 端口的 TCP 流量被 ACL 規(guī)則阻止。這是一種非常隱蔽的配置錯誤——從表面看DNS 服務(wù)“沒有被封”因為 UDP 53 是通的實際效果卻是區(qū)域傳送這條關(guān)鍵鏈路被無聲無息地切斷。下面給出這個場景下最常見的 ACL 配置形態(tài)幫助你對比自己的設(shè)備ip access-list extended DNS-IN permit udp any any eq domain deny ip any any問題就在第二行它只放行了 UDP 53把 TCP 53 連同所有其他流量一起拒之門外。ACL 默認(rèn)隱式拒絕所有未匹配的流量所以 TCP SYN 包會被靜默丟棄不會觸發(fā) ICMP 報錯抓包時看起來就是“發(fā)了沒回”。修復(fù)方法是在deny之前追加一條允許 TCP 53 的規(guī)則ip access-list extended DNS-IN permit udp any any eq domain permit tcp any any eq domain deny ip any any追加規(guī)則后原 ACK 包和區(qū)域傳送的數(shù)據(jù)流就能正常通過了。注意這里any any eq domain對應(yīng)的是“所有來源訪問 53 端口”如果實際環(huán)境里區(qū)域傳送只發(fā)生在特定的主從服務(wù)器之間更穩(wěn)妥的做法是把any換成具體的服務(wù)器 IP縮小放行范圍。4.3 修復(fù)后的驗證區(qū)域傳送恢復(fù)客戶端解析回到 NOERROR改完 ACL 之后我一般會按順序做三個驗證確保問題真正閉環(huán)# 1. 在分公司 DNS 服務(wù)器上測試區(qū)域傳送是否成功 dig 172.16.16.251 應(yīng)用服務(wù)器域名 AXFR # 2. 模擬客戶端向分公司 DNS 查詢 A 記錄 dig 172.16.16.251 應(yīng)用服務(wù)器域名 A # 3. 在總部 DNS 服務(wù)器入方向重新抓包確認(rèn) TCP 53 流量到達 tshark -i eth0 -Y tcp.port 53第一條命令會從分公司 DNS 服務(wù)器直接發(fā)起一次完整的區(qū)域傳送請求如果配置修復(fù)成功能看到一串資源記錄被傳輸過來第二條命令模擬客戶端視角此時應(yīng)答碼應(yīng)該從 SERVFAIL 變成 NOERROR并返回172.16.16.200第三條命令確認(rèn) SYN 包能順利到達總部服務(wù)器。三步全部通過才說明修復(fù)沒有留下死角——我在實際排錯中經(jīng)?？吹接腥烁耐昱渲镁褪展さ诙靻栴}復(fù)現(xiàn)就是漏了回歸驗證這一步。5. 避坑清單DNS 排錯里最容易誤判的 5 個常見問題5.1 看到 SERVFAIL 就去重啟 DNS 服務(wù)器現(xiàn)象客戶端大量報“DNS 解析失敗”抓包看到應(yīng)答碼是 SERVFAIL運維第一反應(yīng)是重啟 DNS 服務(wù)或清緩存。原因SERVFAIL 表示 DNS 服務(wù)器想查但查不到進程本身是健康的問題出在上游鏈路、區(qū)域傳送或權(quán)威數(shù)據(jù)同步上。解決先看應(yīng)答碼區(qū)分故障類型再用分段抓包定位是“發(fā)不出去”還是“拿不回來”不要動服務(wù)。5.2 只在客戶端一個點抓包把問題定性為“DNS 服務(wù)器不回包”現(xiàn)象客戶端抓包看到請求發(fā)出后沒有正常響應(yīng)直接斷定 DNS 服務(wù)器有問題。原因中間鏈路丟包和設(shè)備過濾同樣會導(dǎo)致客戶端看不到響應(yīng)客戶端的抓包只能證明“這一段不通”證明不了是誰丟的。解決至少抓三個點——客戶端、本地 DNS、上游/權(quán)威 DNS對比數(shù)據(jù)包的到達情況哪個點開始看不到流量問題就在那個點之前的設(shè)備上。5.3 過濾條件只寫udp.port 53把關(guān)鍵包漏掉現(xiàn)象分析抓包文件時只過濾了udp.port 53從頭到尾沒看到異常判定“網(wǎng)絡(luò)是好的”。原因DNS 區(qū)域傳送走 TCP 53在大多數(shù) DNS 服務(wù)環(huán)境里默認(rèn)就存在只過濾 UDP 就把這條關(guān)鍵鏈路整個忽略了。解決排查 DNS 故障時把過濾條件寫成port 53同時覆蓋 TCP 和 UDP再結(jié)合tcp.flags.syn判斷連接是否建立成功。5.4 不區(qū)分“包沒到對端”和“對端沒回包”方向性錯誤現(xiàn)象SYN 包沒有收到 SYN-ACK排錯時一直在檢查目標(biāo) DNS 服務(wù)器的配置、權(quán)限和監(jiān)聽狀態(tài)。原因TCP 握手失敗可以是目的端拒絕也可以是中間路由器靜默丟棄兩種原因的處理方向完全不同。解決在目標(biāo)服務(wù)器入方向單獨抓包確認(rèn)包是否到達沒到達就順著鏈路往前找不要對著服務(wù)器瞎折騰。5.5 改完 ACL 或防火墻不做回歸驗證現(xiàn)象前一天改了防火墻規(guī)則第二天用戶反饋同樣的故障又出現(xiàn)了。原因很多防火墻同時存在多條規(guī)則新加的放行規(guī)則可能被后面的拒絕規(guī)則覆蓋或者改的是錯誤的接口方向。解決改完立即做端到端驗證既測試區(qū)傳送又測試正常解析必要的話在兩端同時抓包對比確認(rèn)業(yè)務(wù)流量真的通了再宣布修復(fù)完成。6. 快速定位這類 DNS 故障的固定套路面對 DNS 解析失敗、SERVFAIL、區(qū)域傳送異常這類問題我現(xiàn)在的套路已經(jīng)固化成三步每一步都有明確的判斷標(biāo)準(zhǔn)。第一步客戶端抓包定性。用dns.flags.response 1過濾出所有響應(yīng)包看應(yīng)答碼再用dns.flags.rcode 2把所有 SERVFAIL 挑出來確認(rèn)故障類型。第二步本地 DNS 服務(wù)器抓包定段。重點看它是否向上游發(fā)起了 TCP 53 的連接用tcp.flags.syn 1 tcp.flags.ack 0找到所有握手請求再確認(rèn)有沒有對應(yīng)的tcp.flags.syn 1 tcp.flags.ack 1響應(yīng)。沒有響應(yīng)就不要急著查服務(wù)器配置而是繼續(xù)往下游走。第三步在權(quán)威或上游 DNS 入方向抓包定責(zé)。這里需要一個判斷準(zhǔn)則如果 SYN 到了而沒有任何回應(yīng)重點查服務(wù)器本身的監(jiān)聽和防火墻如果 SYN 根本沒到重點查中間路由器。驗證工具上dig比 nslookup 好用得多用dig DNS服務(wù)器 域名 A看正常解析用dig DNS服務(wù)器 域名 AXFR測試區(qū)域傳送返回 NOERROR 且?guī)зY源記錄才算真正恢復(fù)。Wireshark 的顯示過濾器里我會同時打開port 53、tcp.flags.syn 1、dns.flags.rcode三組條件確保 TCP 和 UDP 兩個維度的流量都在視野內(nèi)。那次故障過后我養(yǎng)成了一個習(xí)慣凡是 DNS 類報錯先強制把“客戶端 → 本地 DNS → 上游/權(quán)威 DNS”三步抓包走完再動任何配置。這條流程幫我擋掉了至少三次“看起來是 DNS 掛了、實際上是中間設(shè)備過濾”的翻車現(xiàn)場。希望這一套思路也能幫你少走點彎路。本文還有配套的精品資源點擊獲取