隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展，銀行互聯(lián)網(wǎng)邊界網(wǎng)絡(luò)作為對公眾以及互聯(lián)網(wǎng)合作商戶提供服務(wù)的重要網(wǎng)絡(luò)基礎(chǔ)設(shè)施也在不斷演進(jìn)。在高可用、高性能、高安全管控要求下，銀行互聯(lián)網(wǎng)邊界網(wǎng)絡(luò)架構(gòu)日益復(fù)雜，一旦發(fā)生故障，影響大，排查難，由于其結(jié)構(gòu)復(fù)雜，個別系統(tǒng)運(yùn)維人員難以全局了解整體架構(gòu)，涉及到互聯(lián)網(wǎng)邊界各類問題需要網(wǎng)絡(luò)運(yùn)維人員共同研究和討論分析，這也成為網(wǎng)絡(luò)運(yùn)維的難點。本文結(jié)合近年來我行互聯(lián)網(wǎng)服務(wù)區(qū)域網(wǎng)絡(luò)運(yùn)維安全運(yùn)營的經(jīng)驗，聊聊互聯(lián)網(wǎng)邊界網(wǎng)絡(luò)故障定位分析的一些思路。

一、互聯(lián)網(wǎng)邊界故障分析處置的挑戰(zhàn)

在說分析思路前，有必要先熟悉一下邊界網(wǎng)絡(luò)。大體上邊界網(wǎng)絡(luò)都具備三大功能：

(相關(guān)資料圖)

1、互聯(lián)網(wǎng)線路接入:承載出入向的互聯(lián)網(wǎng)訪問流量?？紤]冗余性和運(yùn)營商互聯(lián)互通問題和多數(shù)據(jù)中心部署，多中心多出口多活是各大銀行的常規(guī)配置，配套需要部署多組DNS設(shè)備通過GSLB智能地址解析實現(xiàn)在各互聯(lián)網(wǎng)出口線路中進(jìn)行流量調(diào)度；

2、DMZ區(qū)服務(wù)器接入，常見部署WEB或者前置服務(wù)器。隨著計算、存儲和網(wǎng)絡(luò)技術(shù)的發(fā)展，通過虛擬化或者容器化部署逐漸成為目前的主流部署方式，形成了多種資源池接入的架構(gòu)；

3、安全資源接入，承載互聯(lián)網(wǎng)邊界的安全防護(hù)能力。安全設(shè)備包括防火墻、入侵檢測、加解密、WAF應(yīng)用防火墻等多種安全產(chǎn)品，提供全方位的安全防護(hù)能力。多種安全防護(hù)設(shè)備的接入進(jìn)一步提高了互聯(lián)網(wǎng)邊界架構(gòu)的復(fù)雜度。

圖1

從以上的介紹中可以看到，互聯(lián)網(wǎng)邊界網(wǎng)絡(luò)猶如一個精密的機(jī)器，分層部署環(huán)環(huán)相扣，在這樣一個網(wǎng)絡(luò)中定位一個問題是難度是極大的。然而，一個實際互聯(lián)網(wǎng)系統(tǒng)訪問異?？赡鼙冗@個更為復(fù)雜：

1、涉及范圍廣?；ヂ?lián)網(wǎng)故障所涉及的網(wǎng)絡(luò)范圍遠(yuǎn)遠(yuǎn)不止數(shù)據(jù)中心運(yùn)維人員維護(hù)的數(shù)據(jù)中心資源范疇，還包括從用戶端到銀行互聯(lián)網(wǎng)邊界線路所經(jīng)過的整個互聯(lián)網(wǎng)，包括用戶側(cè)網(wǎng)絡(luò)，可能是家庭網(wǎng)絡(luò)也可能是企業(yè)網(wǎng)絡(luò)，可能是有線網(wǎng)絡(luò)也可能是無線網(wǎng)絡(luò)，無線網(wǎng)絡(luò)還需要區(qū)分WIFI網(wǎng)絡(luò)和移動網(wǎng)絡(luò)，中間還可能經(jīng)過多個運(yùn)營商的廣域網(wǎng)網(wǎng)絡(luò)才能到達(dá)網(wǎng)站的邊界網(wǎng)絡(luò)。而真正的問題根因也可能發(fā)生在內(nèi)網(wǎng)服務(wù)器。

2、復(fù)雜的第三方平臺。大型網(wǎng)站常常通過第三方服務(wù)來增強(qiáng)邊界網(wǎng)絡(luò)的能力。比如說常見的CDN內(nèi)容分發(fā)網(wǎng)絡(luò)、運(yùn)營商DNS解析、云安全防護(hù)服務(wù)等等。排查第三方的問題通常需要在對專業(yè)技術(shù)持續(xù)學(xué)習(xí)掌握的同時，持續(xù)與第三方保持溝通，建立連接通道。以CDN服務(wù)為例，CDN技術(shù)使用復(fù)雜的域名調(diào)度策略，涉及對域名技術(shù)的深入理解；CDN運(yùn)營商在全國甚至世界各地部署緩存節(jié)點，實行復(fù)雜的緩存和災(zāi)備策略，出現(xiàn)問題時雙方技術(shù)人員需要配合共同分析，由于互相不清楚對方的架構(gòu)，會增加溝通成本。

3、IPv6/IPv4雙棧網(wǎng)絡(luò)。隨著國家IPv6規(guī)模部署的推進(jìn)，大型網(wǎng)站通常使用雙棧網(wǎng)絡(luò)提供互聯(lián)網(wǎng)服務(wù)，由于屏蔽底層網(wǎng)絡(luò)的變化，用戶通常不知道自己使用IPv6還是IPv4訪問的網(wǎng)站，排查雙棧網(wǎng)絡(luò)問題，將大大增加排查工作量。

二、互聯(lián)網(wǎng)邊界故障分析處置思路

面對復(fù)雜的網(wǎng)絡(luò)環(huán)境，很多運(yùn)維人員面對互聯(lián)網(wǎng)故障都感覺有點“懵”，感到難以下手，其實只要掌握基本技能，全局了解整體部署架構(gòu)后查問題猶如破案，不斷地獲取新證據(jù)進(jìn)行抽絲剝繭，大膽的推測分析，全面的檢驗求證，就不難找出真相。

第一步，獲取真實完全的故障現(xiàn)象。

證據(jù)，指的是事實，盡可能掌握更多的事實，這可以說是查問題最關(guān)鍵的部分，大部分常見問題，都能在現(xiàn)象中發(fā)現(xiàn)蛛絲馬跡，即使不能一次性定位問題，也能極大地縮小問題分析的范圍。但是如果獲得一個錯誤的事實，那么所有的努力都可能走偏，浪費(fèi)寶貴的生產(chǎn)故障處置時間。

通常面對互聯(lián)網(wǎng)故障場景，大部分報障外部用戶甚至是應(yīng)用運(yùn)維人員都無法說清楚全部問題現(xiàn)象。例如網(wǎng)站無法訪問的問題中，大部分報障信息可能就是某某網(wǎng)站無法訪問或者白屏。其實瀏覽器的報錯內(nèi)容至關(guān)重要，通常瀏覽器會直接告知訪問不通的原因，如域名無法解析、IP地址不可達(dá)、證書錯誤、403禁止訪問、404頁面找不到、500服務(wù)器內(nèi)部錯誤。圖2這個瀏覽器返回頁面顯示，訪問的域名為無效域名，直接可以定位為用戶側(cè)誤操作問題。如果是403、404、500等這些HTTP錯誤碼，則可以判斷網(wǎng)絡(luò)層無異常，用戶可以訪問到服務(wù)器，此問題發(fā)生在應(yīng)用層，需要在服務(wù)器側(cè)做進(jìn)一步分析，重點落在參與四七層應(yīng)用層處理設(shè)備上，如代理模式的負(fù)載均衡、安全設(shè)備、服務(wù)器等。反之，若系統(tǒng)應(yīng)用報警日志不友好，使用某個默認(rèn)錯誤頁面且無對應(yīng)ERROR代碼供分析比對，運(yùn)維人員將會消耗大量時間用于開發(fā)人員溝通。

圖2

第二步，判斷影響范圍。

事件發(fā)生時，通常決策者對了解故障應(yīng)用系統(tǒng)業(yè)務(wù)影響范圍的迫切度會高于了解故障原因本身，是個別、局部還是全局問題，影響到整個事件的范圍判斷以及資源協(xié)調(diào)組織。一般從兩方面去了解影響范圍，一是從用戶角度，通過報障信息的數(shù)量和分布情況可以比較直接的了解影響范圍；二是從網(wǎng)站監(jiān)控方面，查看是否存在應(yīng)用、系統(tǒng)、網(wǎng)絡(luò)、安全等方面的異常告警，確認(rèn)流量、交易量、可用性等關(guān)鍵指標(biāo)同比的變化量。

對于分析者來說這一步可以進(jìn)一步判斷排查的范圍，如果是個別問題，基本可以確認(rèn)是用戶側(cè)問題，全局問題通常是CDN或在數(shù)據(jù)中心服務(wù)側(cè)問題，局部問題則需要進(jìn)一步尋找發(fā)生問題的用戶的共性，如同一個運(yùn)營商、同一個地理位置、同一種瀏覽器、同一種品牌的手機(jī)等等。

第三步，準(zhǔn)備必要的信息。

開始分析前，需要準(zhǔn)備必要的信息，包括用戶側(cè)地址、用戶上網(wǎng)環(huán)境、故障發(fā)生時間、故障頻率、關(guān)鍵操作過程、業(yè)務(wù)流程等。這里面最重要的一項準(zhǔn)備工作是準(zhǔn)備網(wǎng)絡(luò)拓?fù)鋱D。拓?fù)鋱D可以將抽象的問題具象化，在拓?fù)鋱D上進(jìn)行演算，遠(yuǎn)比空想更有效率。拓?fù)鋱D通常有兩種，一種為物理拓?fù)鋱D，展示所有網(wǎng)絡(luò)路徑，常用于排查分析網(wǎng)絡(luò)的關(guān)鍵節(jié)點。當(dāng)?shù)谝徊酵ㄟ^事實推理出懷疑方向后，就可以把整個路徑的可疑點全部圈出，逐一排查；另一種為邏輯拓?fù)鋱D，常用于分析應(yīng)用層問題，展示所有四七層節(jié)點訪問關(guān)系，對于后續(xù)的分段抓包分析有極大的幫助。即使是對環(huán)境很熟悉的老手，也有必要準(zhǔn)備一個拓?fù)鋱D。

第四步，工具分析。

對于隱藏較深的棘手問題，就要借助工具?！肮び破涫?，必先利其器”，什么情況下要借助工具呢？

1、看指標(biāo)。指標(biāo)為生產(chǎn)運(yùn)行過程中計算出的數(shù)據(jù)，如速率、丟包率、帶寬占用率、延時等等，這些數(shù)據(jù)無法直接獲得，需要通過工具計算；

2、看趨勢。故障發(fā)生時一定會出現(xiàn)指標(biāo)異常，看趨勢可以明顯看出異常發(fā)生時間點，以及處置后是否已經(jīng)恢復(fù)；

3、查找關(guān)鍵特征。有些事件有明顯的特征，比如某個HTTP錯誤碼，某個交易流水號，某個域名，某個賬戶等等，通過查找關(guān)鍵特征可以快速定位問題；

4、抓包分析。底層數(shù)據(jù)包是包含數(shù)據(jù)鏈路層到應(yīng)用層的所有信息，所有問題一定能從數(shù)據(jù)包中找到答案，但是從海量的底層數(shù)據(jù)中分析出問題，對分析人員的技術(shù)和經(jīng)驗都有較高的要求，另外，對于需要快速處理的事件，抓包分析時間長，效率低，所以抓包分析更適合事后問題根因分析。

第五步，列出疑點和復(fù)盤。

有了充分的事實并通過工具觀察后，可以形成幾個可疑點，疑點可以有多個，但是一定要清晰的列在紙上，然后對每個疑點進(jìn)行逐一復(fù)盤。這里不是說事件處理后對整個事件處置的復(fù)盤，而是列出懷疑的點后，要基于這個推論重新對每一個故障現(xiàn)象進(jìn)行推理，看看這個疑點是否會導(dǎo)致所有現(xiàn)象的出現(xiàn)，如果全部符合，那么就可以基本判定這個推論就是故障的原因。如果有矛盾，那么繼續(xù)分析下一個最可疑的點，不斷重復(fù)這個過程。

三、經(jīng)典案例分析

案例一：邊界防火墻會話數(shù)突發(fā)超閾值告警

現(xiàn)象：

邊界防火墻經(jīng)常吐出日志報警，并發(fā)會話數(shù)超過平時十倍，瞬間恢復(fù)，查看火墻當(dāng)前的會話數(shù)排名，最高的通信對也只有幾百個會話。互聯(lián)網(wǎng)線路流量無異常，各互聯(lián)網(wǎng)業(yè)務(wù)都正常，無業(yè)務(wù)促銷秒殺等活動。DDOS設(shè)備、WAF設(shè)備等安全設(shè)備無告警。負(fù)載均衡流量、會話數(shù)無異常。

分析：

看起來是個很詭異的問題，一切都正常，就是有告警，因為告警時間相當(dāng)短，登陸上設(shè)備的時候已經(jīng)無法看到現(xiàn)象。但是即使動用探針，對流量數(shù)據(jù)進(jìn)行回溯，依然找不到異常的通信對，甚至連客戶端數(shù)量也沒有增長。其實，問題的關(guān)鍵在于防火墻是怎么工作的。防火墻準(zhǔn)確的說不能算一個四層設(shè)備，沒有完整的TCP協(xié)議棧，但是它有會話的概念，通常一個通信的五元組完成一次TCP三次握手后我們才認(rèn)為建成一個會話，但是火墻的會話不同，火墻的會話只有一個目的，讓策略允許通過的五元組通信對可以回包。

可能性一：雖然學(xué)過網(wǎng)絡(luò)的人都知道UDP是無連接的協(xié)議，但是在防火墻上，UDP也是有會話的（30秒超時），為了保證UDP請求的回包可以通過火墻。常見的UDP協(xié)議，主要就是DNS，某些客戶端短時間發(fā)起大量域名的查詢請求，導(dǎo)致火墻會話數(shù)短時間升高，常見DNS FLood攻擊。

可能性二：大量的SYN包掃描，由于TCP三次握手需要來回三次交互，所以第一個SYN包就可以在網(wǎng)絡(luò)防火墻上生成會話，如果大量的SYN包掃描，就有可能在火墻上短時間內(nèi)產(chǎn)生大量的半開連接會話。

基于這個推論重新復(fù)盤一下所有的現(xiàn)象，看看是否有矛盾的地方。不管是SYN包還是DNS包都很小，大量的訪問也無法引起流量的變化，同時對其他業(yè)務(wù)也不會造成影響，但是DDOS防護(hù)設(shè)備為什么沒有告警呢？DDOS告警取決于策略閾值，單個客戶IP的請求頻率和單個服務(wù)器IP的請求頻率，如果都未到達(dá)閾值，或者持續(xù)時間極短，則可能無法觸發(fā)告警。事實證明這兩種情況都有可能造成火墻會話數(shù)高的告警。

解決：

建立DNS請求量和SYN包請求量視圖，查看故障發(fā)生時曲線是否有異常升高，針對DNS FLood行為，可以增加單個IP發(fā)起DNS請求的域名數(shù)量統(tǒng)計指標(biāo)，對于掃描行為，可以增加單個IP訪問“目標(biāo)地址+端口”的數(shù)量統(tǒng)計指標(biāo)，都可以快速定位到異?？蛻舳?，提交給安全運(yùn)營或運(yùn)維安全人員跟蹤處置。

互聯(lián)網(wǎng)DNS網(wǎng)絡(luò)域名解析請求跟蹤圖：

圖3

SYN與SYNACK差異化網(wǎng)絡(luò)跟蹤圖：

圖4

案例二：部分移動用戶客戶端某個頁面APP白屏

現(xiàn)象：遠(yuǎn)程銀行中心接到少量用戶投訴，個別手機(jī)打開移動APP客戶端有出現(xiàn)白屏的情況，這些用戶都集中在個別省市，涉及某個運(yùn)營商，未接到其他省用戶投訴，且服務(wù)側(cè)各項監(jiān)控指標(biāo)無明顯異常。

分析：

這是一個典型的“局部問題”，在某市安排當(dāng)?shù)鼐哂邢嗤\(yùn)營商號段的科技人員使用手機(jī)卡流量上網(wǎng)協(xié)助進(jìn)行測試，發(fā)現(xiàn)復(fù)現(xiàn)該問題，但訪問行內(nèi)其他網(wǎng)站及同業(yè)APP正常，說明用戶本地運(yùn)營商網(wǎng)絡(luò)基本正常，域名解析正常。總部數(shù)據(jù)中心本地人員測試訪問正常，說明服務(wù)端正常。這時一個重要信息從應(yīng)用的開發(fā)人員處獲得，移動APP打開后會先加載一個靜態(tài)的廣告頁面，如果廣告頁面異常，有可能導(dǎo)致訪問APP失敗的情況。這個靜態(tài)的頁面，是從CDN獲取的。

CDN的工作原理是用戶通過域名訪問網(wǎng)站，CDN的域名服務(wù)器根據(jù)用戶IP所屬的地理位置，返回給用戶一個離他最近的緩存節(jié)點地址，然后用戶訪問最近的這個緩存節(jié)點獲取資源。問題原因到這已經(jīng)呼之欲出了，某省市的這個CDN緩存節(jié)點中有服務(wù)器可能有故障。

重新復(fù)盤一下，CDN某個緩存節(jié)點有故障，導(dǎo)致使用該緩存節(jié)點的用戶都獲取不到廣告頁面，導(dǎo)致APP白屏，而其他地區(qū)的用戶訪問其他緩存節(jié)點正常。由于CDN流量不會被源站監(jiān)控統(tǒng)計，所以指標(biāo)無法觀察到異常。

優(yōu)化解決：

1、要求CDN運(yùn)營商緊急隔離當(dāng)?shù)氐木彺婀?jié)點后業(yè)務(wù)恢復(fù)。2、手機(jī)APP增加加載資源超時跳出逃生功能，避免加載不到資源而被卡住。

案例三：部分地址無法訪問

現(xiàn)象：某公司部分員工反饋員工考勤app無法打開，進(jìn)一步驗證發(fā)現(xiàn)，相關(guān)員工手機(jī)訪問公司內(nèi)其他網(wǎng)站也無法打開，但可以訪問其他企業(yè)網(wǎng)站，分析源地址同為某一運(yùn)營商IP，切換地址后恢復(fù)。在互聯(lián)網(wǎng)入口抓包，發(fā)現(xiàn)大量的建鏈請求被服務(wù)端RST中斷。在WAF前端抓包，發(fā)現(xiàn)大量synack應(yīng)答包被客戶端RST中斷。

圖5

分析：

梳理一下現(xiàn)象：1、僅有一個運(yùn)營商地址有異常；2、只針對本公司的網(wǎng)站；3、WAF前端抓包能看到客戶端RST。如果僅從這三個現(xiàn)象看，這百分之百應(yīng)該是運(yùn)營商的問題，應(yīng)盡快找運(yùn)營商協(xié)查。但是在復(fù)盤時發(fā)現(xiàn)，第4個現(xiàn)象和我們的這個推斷并不相符：在互聯(lián)網(wǎng)入口看，RST是從服務(wù)端發(fā)出的。第3和第4個現(xiàn)象看起來很矛盾，只有一個解釋，中間有設(shè)備同時向兩邊發(fā)了RST。

拿出拓?fù)鋱D重新分析，從互聯(lián)網(wǎng)出口到內(nèi)網(wǎng)依次經(jīng)過接入交換機(jī)、接入防火墻、入侵檢測設(shè)備、負(fù)載均衡、加解密設(shè)備、WAF設(shè)備、WEB服務(wù)器。從抓包的情況看，設(shè)備應(yīng)該在互聯(lián)網(wǎng)出口到WAF之間，交換機(jī)和防火墻都沒有能力發(fā)RST可以排除。負(fù)載均衡、SSL設(shè)備在連接超時時會同時向兩端發(fā)送RST斷鏈，但是這些設(shè)備發(fā)出的RST包TTL值和真正的客戶端或者服務(wù)端不一樣，從抓包中看，TTL值完全符合客戶端和服務(wù)端發(fā)送的特征，所以也可以排除。重新觀察拓?fù)鋱D，拓?fù)鋱D中接入的安全設(shè)備進(jìn)入我們視野。該安全設(shè)備會檢測客戶端源地址，對黑名單中的IP進(jìn)行阻斷，并同時向客戶端及服務(wù)端發(fā)送RST。這個流程和我們看到的現(xiàn)象完全一致。

解決：

在攻擊黑IP地址名單中刪除相關(guān)攔截IP。

四、總結(jié)

互聯(lián)網(wǎng)邊界故障可以說是所有網(wǎng)絡(luò)故障中最難排查的問題之一，需要對整體架構(gòu)、技術(shù)產(chǎn)品、業(yè)務(wù)部署等全棧領(lǐng)域知識深入理解和長期運(yùn)維經(jīng)驗，互聯(lián)網(wǎng)邊界故障分析并沒有完全固定的套路，需要日常持之以恒的學(xué)習(xí)積累和實踐總結(jié)，將每一次故障處置作為練兵提升的機(jī)會，持續(xù)開展應(yīng)急處置和演練，提升科技運(yùn)營網(wǎng)絡(luò)隊伍的能力。本文對一些常見案例和分析思路進(jìn)行總結(jié)，希望能為后續(xù)互聯(lián)網(wǎng)邊界故障分析處置提供一些思路和靈感，后續(xù)我們將結(jié)合實際運(yùn)維場景，在實際工作中多總結(jié)、多思考，開展網(wǎng)絡(luò)持續(xù)優(yōu)化，提升工具和自動化處置能力，助力業(yè)務(wù)健康平穩(wěn)發(fā)展。

責(zé)任編輯：