[[438888]]

本文轉(zhuǎn)載自微信公眾號(hào)「小咩社長」，作者小咩社長。轉(zhuǎn)載本文請(qǐng)聯(lián)系小咩社長公眾號(hào)。

寫在前面：

最近一保險(xiǎn)客戶火急火燎的找到我說：“濤哥，我們最近這段時(shí)間每天晚上在執(zhí)行批處理的過程中，頻繁的報(bào)錯(cuò)，十萬次的HTTP POST請(qǐng)求中，大概會(huì)有六七百次的請(qǐng)求失敗的情況發(fā)生，故障現(xiàn)象隨時(shí)可以復(fù)現(xiàn)，趕緊幫看看“。經(jīng)過老中醫(yī)我一番懸絲診脈，梳理完整個(gè)業(yè)務(wù)訪問流程后，下一良方，輔以悍藥猛攻，基本上藥到病除。

由于此故障場(chǎng)景很有代表性，于是專門整理出這篇文章，希望能給到大家在日常運(yùn)維排錯(cuò)中一點(diǎn)啟發(fā)。話不多少，上干貨。

網(wǎng)絡(luò)邏輯拓?fù)浼皹I(yè)務(wù)流：

業(yè)務(wù)的邏輯拓?fù)鋱D，如下圖所示。

批處理業(yè)務(wù)服務(wù)器：Server1 10.160.XX.81:8000、Server2 10.160.XX.82:8000。并且通過前端F5設(shè)備提供負(fù)載均衡和業(yè)務(wù)對(duì)外發(fā)布，VIP地址：10.50.XX.67:8165。

測(cè)試終端：通過Curl的方式向 F5 VIP 10.50.XX.67:8165 發(fā)送POST請(qǐng)求(批處理流程)

訪問流程：

• 用戶使用腳本通過curl 提交POST請(qǐng)求到F5 VIP 10.50.XX.67:8165
• F5將客戶的POST請(qǐng)求按照負(fù)載均衡算法將請(qǐng)求轉(zhuǎn)發(fā)給真實(shí)服務(wù)器Server1或者server2
• F5和服務(wù)器之間有一個(gè)國產(chǎn)XX信的NGFW設(shè)備(上聯(lián)F5設(shè)備使用的是防火墻feth11接口，下聯(lián)交換機(jī)使用是防火墻feth10接口)，注意防火墻出入接口，接下來分析數(shù)據(jù)包的時(shí)候會(huì)提到。

故障現(xiàn)象：

用戶在使用腳本提交POST請(qǐng)求到F5 VIP 10.50.XX.67:8165的時(shí)候，運(yùn)行一段時(shí)間后會(huì)卡住(即：POST請(qǐng)求發(fā)出后沒有響應(yīng))，幾秒鐘后收到F5 返回來的RESET包。

抓包大殺器TCPDUMP：

乍一看，很明顯F5發(fā)了RESET包，顯然是F5的鍋嘛。其實(shí)有時(shí)眼見不一定為實(shí)，需要透過現(xiàn)象找到問題本質(zhì)，并不是誰發(fā)了RESET包就是誰的鍋。

話不多說，直接掏出大殺器tcpdump，這種疑難雜癥還得猛藥去攻。在客戶執(zhí)行批處理操作的同時(shí)，我們?cè)谝韵氯齻€(gè)位置進(jìn)行抓包。

一、F5設(shè)備上執(zhí)行tcpdump抓包

#同時(shí)抓取客戶端IP、F5 VIP、服務(wù)器IP，可以抓全整個(gè)訪問環(huán)節(jié)的數(shù)據(jù)包，方便定位故障點(diǎn)

#同時(shí)抓取客戶端IP、F5 VIP、服務(wù)器IP，可以抓全整個(gè)訪問環(huán)節(jié)的數(shù)據(jù)包，方便定位故障點(diǎn) 
tcpdump -ni 0.0:nnn -s0 host 10.50.xx.88 or 10.50.xx.67 or 10.160.xx.81 or 10.160.xx.82 -w /var/tmp/test0421-6.pcap.pcap 

二、XX信防火墻抓包，抓取流經(jīng)上聯(lián)接口feth11和下聯(lián)接口feth10的所有流量。

三、在服務(wù)器 Server1 10.160.XX.81、Server2 10.160.XX.82上使用tcpdump抓取流經(jīng)服務(wù)器網(wǎng)卡的所有數(shù)據(jù)包。

抓包進(jìn)行時(shí)：

測(cè)試端使用腳本跑批處理的時(shí)候，三個(gè)點(diǎn)同時(shí)進(jìn)行抓包，當(dāng)測(cè)試端故障復(fù)現(xiàn)，三個(gè)點(diǎn)停止抓包。

數(shù)據(jù)包分析：

不負(fù)眾望，故障現(xiàn)象成功復(fù)現(xiàn)，下面進(jìn)行最重要的階段，數(shù)據(jù)包分(甩)析(鍋)：

一、F5上數(shù)據(jù)包分析：測(cè)試客戶端到F5 VIP數(shù)據(jù)包分析(clientside)：

注意故障包的時(shí)間：20點(diǎn)57分12秒，以下分析基于該時(shí)間點(diǎn)的故障數(shù)據(jù)包分析，注意數(shù)據(jù)包前時(shí)間!!!

通過wireshark查看F5上tcpdump抓取的數(shù)據(jù)包，找到故障會(huì)話，可以看到

客戶端10.50.X.88:54373訪問 F5 VIP 10.50.XX.67:8165的訪問流量，通過數(shù)據(jù)包我們可以得到到以下信息：

• 客戶端10.50.X.88:54373訪問 F5 VIP 10.50.XX.67:8165 TCP三次握手建立成功
• 客戶端發(fā)起了POST請(qǐng)求，并且F5確認(rèn)收到該請(qǐng)求 (ack)
• F5沒有響應(yīng)回http response給客戶端
• F5返回給客戶端一個(gè)RST，RST原因?yàn)椋篎5RST(peer) TCP retransmit timeout(重傳超時(shí))。

事實(shí)上當(dāng)F5和客戶端建立完TCP三次握手之后，F(xiàn)5會(huì)基于負(fù)載算法選擇一臺(tái)服務(wù)器進(jìn)行tcp三次握手建鏈，然后將客戶端發(fā)來的POST請(qǐng)求轉(zhuǎn)發(fā)給真實(shí)的服務(wù)器：

通過wireshark上使用F5的擴(kuò)展插件，該會(huì)話流程中還能看到以下信息。

• 在該會(huì)話中F5選擇了10.160.XX.82:8000這臺(tái)服務(wù)器
• F5啟用了源地址轉(zhuǎn)換功能，將客戶端的真實(shí)IP地址10.50.XX.88轉(zhuǎn)換為10.50.XX.247
• 源端口為43166

二、F5上數(shù)據(jù)包分析：F5 (10.50.XX.247)到10.160.XX.82:8000流量分析(serverside)：

通過wireshark查看F5上tcpdump抓取的數(shù)據(jù)包，過濾tcp.port ==43166，可以看到

F5端(10.50.XX.247:43166)訪問 server2 10.160.XX.82:8000的訪問流量，通過數(shù)據(jù)包我們可以得到到以下信息：

• 當(dāng)F5端(10.50.XX.247:43166)嘗試與 server2 10.160.XX.82:8000建立鏈接
• F5 發(fā)送SYN包給server2，但是server2并未無回應(yīng) SYN-ACK
• F5觸發(fā)重傳機(jī)制，三次重傳后未得到服務(wù)端的響應(yīng)(于是F5 觸發(fā)RST機(jī)制，強(qiáng)制斷開客戶端的鏈接)

三、服務(wù)器數(shù)據(jù)包分析：server2 10.160.XX.82 數(shù)據(jù)包分析：

通過上述F5上數(shù)據(jù)包我們分析了clientside和serverside的數(shù)據(jù)交互，得出初步結(jié)論，F(xiàn)5和服務(wù)端server2建立鏈接失敗，假設(shè)可能的原因有以下幾種：

• 防火墻將F5給服務(wù)器server2發(fā)送的SYN包轉(zhuǎn)發(fā)給了Server2，Server2沒收到
• 防火墻將F5給服務(wù)器server2發(fā)送的SYN包轉(zhuǎn)發(fā)給了Server2，Server2收到但是沒有響應(yīng)
• 防火墻沒有收到F5給服務(wù)器server2發(fā)送的SYN包
• 防火墻收到F5給服務(wù)器server2發(fā)送的SYN包，沒有給服務(wù)器server2轉(zhuǎn)發(fā)

現(xiàn)在我們首先解決假設(shè)2，這個(gè)很easy，我們直接查看在server2上抓的數(shù)據(jù)包即可，如果在時(shí)間點(diǎn)20點(diǎn)57分12秒收到了來自防火墻的數(shù)據(jù)包，那么代表防火墻轉(zhuǎn)發(fā)了數(shù)據(jù)包，server2有沒有回應(yīng)zai數(shù)據(jù)包中一目了然。通過數(shù)據(jù)包我們可以得到到以下信息：

server2 0.160.XX.82在20點(diǎn)57分03秒后就再也沒有收到來自F5 10.50.XX.247:43166的數(shù)據(jù)包。

四、撥云見日：XX信防火墻數(shù)據(jù)包分析：

通過查看server2上的抓包，我們看到server2并未收到來自F5的數(shù)據(jù)包，接下來就清晰多了，就剩下XX信防火墻了，查看XX信的抓包，我們基本上就可以解決剩下的三個(gè)假設(shè)，直接定位問題。

接下來就是見證奇跡的時(shí)刻：打開XX信防火墻的數(shù)據(jù)包瞅一瞅：

通過數(shù)據(jù)包對(duì)比查看定位到故障包時(shí)間點(diǎn)20點(diǎn)57分13 14 15秒鐘XX信防火墻上聯(lián)接口feth11收到了F5發(fā)給server2的SYN包，但是并未從feth10接口轉(zhuǎn)出。。。。

故障定位：

通過以上分析，我們大概能夠還原整個(gè)故障原因：

首先客戶端發(fā)起批處理操作，在不斷的POST的過程中，中間XX信防火墻轉(zhuǎn)發(fā)數(shù)據(jù)異常，導(dǎo)致服務(wù)端無法接收到F5設(shè)備轉(zhuǎn)發(fā)到服務(wù)端的數(shù)據(jù)，于是F5嘗試重傳數(shù)據(jù)包，當(dāng)三次重傳都未能成功建立連接后，F(xiàn)5執(zhí)行RST動(dòng)作，強(qiáng)制斷開服務(wù)端的鏈接。

F5 RST機(jī)制

一、由于F5的全代理架構(gòu)，客戶端到F5(clientside)、F5到服務(wù)器(serverside)維護(hù)連個(gè)TCP/IP協(xié)議棧，受益于架構(gòu)設(shè)計(jì)，才可以做到客戶端和F5之間跑http2，F(xiàn)5和服務(wù)器跑http1.1，前端跑https，后端跑http。所以F5在TCP/HTTP等協(xié)議會(huì)做RFC合規(guī)校驗(yàn)，再特定的包結(jié)構(gòu)下或者協(xié)議安全上會(huì)觸發(fā)RST動(dòng)作，保障業(yè)務(wù)的安全和設(shè)備穩(wěn)定性，以下是部分RST說明，詳情見鏈接：

鏈接：https://support.f5.com/csp/article/K13223

總結(jié)

通過層層抓包，一步步接近問題真相，快感還是有，雖然最終不是自己F5設(shè)備的問題，但是能幫助客戶第一時(shí)間定位問題，這其實(shí)也是我們作為服務(wù)商的價(jià)值，若有坑，召比填，填必滿!最近一直再忙F5 CVE的事，一直沒時(shí)間輸出。老鐵們不用擔(dān)心，rancher商業(yè)版我這已經(jīng)申請(qǐng)測(cè)試了，目前再搭demo環(huán)境，rancher聯(lián)動(dòng)F5和k8s集群的的干貨文章在路上了!