運維案例 - 一個 DNS 解析引發的 “血案”

面對越來越複雜的網絡環境，每天發生着數以萬億的數據交互，一旦出現問題我們就需要快速定位解決問題。那麼，我們就必須儲備豐富的知識，利用各種工具幫助我們分析問題。有時通過應用日誌、網管平臺等看起來一切都沒有異常，分析起來卻一籌莫展，這時就需要使用數據包分析技術，來深入探索每一個 TCP 連接，最終來定位問題。

什麼是數據包分析技術？

數據包分析又叫數據包嗅探，指的是捕獲和解析網絡上在線傳輸數據的過程，目的是爲了更好地瞭解或定位網絡、應用層運行狀態和故障節點，常見的網絡抓包分析工具有 wireshark、dali、tcpdump 等。

數據包分析的切入點

數據包分析的切入點很大程度上取決於具體的問題現象，也就是說並沒有一個絕對固定不變的流程。

但總體上我們可以用排除法判斷在哪些層次沒有發生問題，快速把分析的重點找到:

• 網絡層指標是相對通用化的;
• 多點對比分析常常用於網絡設備層設備故障排查;
• 應用層指標則是專用的，應對於各種業務應用;
• 通常我們利用通用的 TCP 模型，分析其通信過程和具體行爲;

• 正常 / 異常時的對比是分析行爲的有效方法。

基於數據包分析的排障案例

問題描述

1、【問題 1】1 月 28 日某行新 ETC 網關上線， ETC 地址 10.*.*16 在經過防火牆後訪問三方系統時，三次握手建立正常，但發送數據時對方無法收到，且 ETC 網關這邊收到報錯信息爲 Empty replay for Server。

2、【問題 2】ETC 網關可以正常訪問三方系統，但是整個 ETC 業務訪問過程特別慢大概有 10-15s 延遲，嚴重影響使用。

邏輯梳理

有了明確的問題，我們在分析時候首先要瞭解整個訪問的邏輯過程及物理拓撲，切記這是做數據包分析的先決條件，這會涉及到你取數據包的位置，至關重要。

環境描述：

整個業務在行內訪問流程，ESB10...83 先訪問 ETC 網關 10...16:7550，ETC 網關再訪問三方系統 172...248:2000。路由器上將 172...248 映射爲 172...155。

如下圖所示，在採集點 1、2、3、4 分別部署了數據包捕獲點，由數據包採集系統統一管理。

問題分析

分析問題 1：

1）首先因爲 10...16 是 F5 的虛擬地址，爲了排除 F5 的影響，在 ETC 服務器 (10...14) 上將出去的路由手動指向防火牆 FW2，然後在 ETC 服務器 (10. ..14) 上發送一個 Post 請求 172. ..248:2000，其中 172. ..248 做 NAT 後的地址是 172. ..155。使用 tcpdump 在 10. ..14 上抓包如下圖：

可以看到 10...14 與 172. ..248 三次握手正常建立，10...14 發送了一個 Post 請求，172. ..248 也對這個包，進行了確認，但沒有發送響應，等到了 60s 超時後，248 主動斷開了連接。

2）從 ETC 服務器上可以看到 Post 請求發了出去，但對方沒有收到，所以懷疑可能中間環節把請求丟了，即需要 FW2 前後的數據包進行比對，故在抓取採集 3 和採集點 4 關於 ETC 網關和三方系統交互的數據包，如下圖所示：

從生存時間和 MAC 地址上可以看到，在同一個 TCP 流中，11 號包是 FW2 前面的 SYN 包，12 號是 FW2 後面的 SYN 包，三次握手之後，17 號報是 FW2 前面的請求，18 號是 FW2 回覆的 ACK 包，60s 之後因爲連接超時而關閉。

從而可以判斷出請求在過防火牆 FW2 時被丟棄了，需要檢查下防火牆的配置。

3）現象是防火牆可以正常放行三次握手，但 http 層的數據被丟棄。

通過排查和諮詢之後確定是由於 ETC 訪問外部的地址用的 2000 端口，而防火牆 ASA 會訪問外部 tcp 2000 端口的流量當成了 skinny 協議的流量，而實際是 http 流量，因爲兩種協議流量的數據結構肯定不相同，所有當 TCP 三次握手完成後，後面的 http 應用的包被丟棄。

**Skinny 協議，**即 sccp，是思科專有的 VOIP 協議，用於連接 Cisco VoIP 電話到 Cisco 呼叫管理服務器。此外通過 Wireshark 也可以看到 2000 端口被識別成 Cisco-SCCP。

解****決方法有兩種：

1、更換目的地址使用的端口號

2、只需防火牆將默認的 TCP 2000 的 skinny 協議審查取消即可

           policy-map global_policy

           class inspection_default

           no inspect skinny

分析問題 2：

1）首先根據 ETC 整個業務訪問的流程先分成兩段來看，業務一段是 ESB<——>ETC 網關，業務二段是 ETC 網關 <——> 三方系統。

先抓取業務二段 (採集點 3 和採集點 4) 的數據包過濾相關地址，如圖所示可以看到從三次握手到服務器應用處理時間間隔都很小，在 15s 後 ETC 網關發送 FIN 主動請求斷開連接。

2）同理抓取業務一段 (採集點 1 和採集點 2) 的數據包過濾相關地址，如圖所示可以看到從三次握手和 ESB 發送請求間隔時間都很短，但從 ETC 網關發送給 ESB 的響應間隔了 15S 左右，懷疑 ETC 網關在處理響應時比較慢或者發送有延遲。

3）由於在 ESB 和 ETC 網關之間有防火牆 FW1，爲了排除是否由防火牆造成的延遲，在採集點 1 和採集點 2 中抓取同一會話進行對比，發現防火牆前後 ETC 網關響應的間隔時間差值 2-3ms，故排除防火牆問題。

4）通過數據包採集系統抓取採集點 2 和採集點 3(兩個採集點在同一設備) 同一時間段的流量，因爲從 ESB 到 ETC 網關發送的是 XML 數據，而從 ETC 網關到三方系統發送的是 http 數據，只能根據發送字段的相關信息來把採集點 2 和採集點 3 的同一筆交易進行關聯，發現 ETC 網關在同三方系統開始建立三次握手的時間與 ESB 發送完請求的時間之間剛好差了 15s 左右。

5）同時測試在 ETC 網關上 telnet 自己的業務端口 7550，發現也比較慢。至此，可以判斷大概原因是 ETC 網關建立連接有延遲，後經查證行內系統都需要經過域名反解析，而 ETC 網關上配置的主域名服務器解析出了問題，每次先使用主 DNS 查詢 IP 地址對應的 PTR 記錄，當超時時間 (可能是 5s) 內還沒有收到回覆，就會再查詢一次，如果第二次超時還沒有回覆，就會查詢備用的 DNS 服務器。

通過抓取 ETC 網關的數據包也可以驗證，每次會先查詢主 DNS 服務器 10..10 ，超時時間爲 5s，連續超時之後再查詢備 DNS192...42，返回的信息是 No such name。接着纔開始和對端建立連接。

**解決方案：在 ETC 網關服務器上將故障的主 DNS 服務器摘除，**業務訪問回覆正常。

案例總結

1、分析數據包問題時最好多用幾個分析軟件，抓住每一個細節，比如 wireshark、dali 可以配合使用，本案例中 wireshark 可以把 2000 端口解析爲 cisco-sccp 協議，可以幫助排查問題。

2、在抓取數據包時，宜多不宜少，多了可以通過過濾條件來導出特定分組，但少了就會忽略掉一些關鍵信息。

3、回顧和思考是快速增長經驗的法寶

• 在現場做故障診斷，往往受到很多外界因素影響；

• 每個案例分析過後再回顧，一定可以發現並歸納出一些技術、技巧以及思路上的優化方法；

• 行業化的應用模式具有通用性，特別是金融行業，應用通信模式有很多相似性；

• 只有類似的 Case，沒有一模一樣的 Case，在回顧和思考中深入理解知識點和其應用模式；

• 在本案例中，**最關鍵的部分****是網絡抓包分析系統，**有了它我們才能對每一筆業務在網絡中各個階段進行得心應手的分析。那麼構建一套高效的網絡抓包分析系統便顯得十分必要。

• 小流量的情況，可以選取開源軟件包括 wireshark、sinffer 等。但如果要長時間、大流量實時高性能採集且需要留存歷史數據包來進行網絡故障與性能的分析，建議使用商用產品實現更加複雜和快速網絡故障分析定位。

除此以外，還可以使用網絡性能監控工具來輔助排障，提升解決問題效率。譬如天旦網絡性能管理 NPM，天旦 NPM 採集全網原始流量，建立覆蓋數據中心重要鏈路、關鍵設備（囊括負載均衡、防火牆等應用交付類的網絡設備）與核心服務路徑的監控視圖，對關鍵業務的網絡行爲進行監控、審計與分析，對異常指標實時告警，提前發現問題，快速定位故障，提升運維效率，保障業務暢通。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/R4fEDh7sjl27P62Pw-HsXw