隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展，銀行互聯(lián)網(wǎng)邊界網(wǎng)絡(luò)作為對(duì)公眾以及互聯(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ù)雜，個(gè)別系統(tǒng)運(yùn)維人員難以全局了解整體架構(gòu)，涉及到互聯(lián)網(wǎng)邊界各類問題需要網(wǎng)絡(luò)運(yùn)維人員共同研究和討論分析，這也成為網(wǎng)絡(luò)運(yùn)維的難點(diǎn)。本文結(jié)合近年來我行互聯(lián)網(wǎng)服務(wù)區(qū)域網(wǎng)絡(luò)運(yùn)維安全運(yùn)營(yíng)的經(jīng)驗(yàn)，聊聊互聯(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)營(yíng)商互聯(lián)互通問題和多數(shù)據(jù)中心部署，多中心多出口多活是各大銀行的常規(guī)配置，配套需要部署多組DNS設(shè)備通過GSLB智能地址解析實(shí)現(xiàn)在各互聯(lián)網(wǎng)出口線路中進(jìn)行流量調(diào)度；

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

3、安全資源接入，承載互聯(lián)網(wǎng)邊界的安全防護(hù)能力。安全設(shè)備包括防火墻、入侵檢測(cè)、加解密、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ò)猶如一個(gè)精密的機(jī)器，分層部署環(huán)環(huán)相扣，在這樣一個(gè)網(wǎng)絡(luò)中定位一個(gè)問題是難度是極大的。然而，一個(gè)實(shí)際互聯(lián)網(wǎng)系統(tǒng)訪問異?？赡鼙冗@個(gè)更為復(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)過的整個(gè)互聯(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ò)和移動(dòng)網(wǎng)絡(luò)，中間還可能經(jīng)過多個(gè)運(yùn)營(yíng)商的廣域網(wǎng)網(wǎng)絡(luò)才能到達(dá)網(wǎng)站的邊界網(wǎng)絡(luò)。而真正的問題根因也可能發(fā)生在內(nèi)網(wǎng)服務(wù)器。

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

3、IPv6/IPv4雙棧網(wǎng)絡(luò)。隨著國(guó)家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)邊界故障分析處置思路

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

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

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

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

圖2

第二步，判斷影響范圍。

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

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

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

開始分析前，需要準(zhǔn)備必要的信息，包括用戶側(cè)地址、用戶上網(wǎng)環(huán)境、故障發(fā)生時(shí)間、故障頻率、關(guān)鍵操作過程、業(yè)務(wù)流程等。這里面最重要的一項(xiàng)準(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é)點(diǎn)。當(dāng)?shù)谝徊酵ㄟ^事實(shí)推理出懷疑方向后，就可以把整個(gè)路徑的可疑點(diǎn)全部圈出，逐一排查；另一種為邏輯拓?fù)鋱D，常用于分析應(yīng)用層問題，展示所有四七層節(jié)點(diǎn)訪問關(guān)系，對(duì)于后續(xù)的分段抓包分析有極大的幫助。即使是對(duì)環(huán)境很熟悉的老手，也有必要準(zhǔn)備一個(gè)拓?fù)鋱D。

第四步，工具分析。

對(duì)于隱藏較深的棘手問題，就要借助工具?！肮び破涫拢叵壤淦鳌?，什么情況下要借助工具呢？

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

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

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

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

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

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

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

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

現(xiàn)象：

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

分析：

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

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

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

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

解決：

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

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

圖3

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

圖4

案例二：部分移動(dòng)用戶客戶端某個(gè)頁面APP白屏

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

分析：

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

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

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

優(yōu)化解決：

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

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

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

圖5

分析：

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

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

解決：

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

四、總結(jié)

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

責(zé)任編輯：