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

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

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

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

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

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

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

圖1

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

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

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

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

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

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

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

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

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

圖2

第二步，判斷影響范圍。

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

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

第三步，準備必要的信息。

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

第四步，工具分析。

對于隱藏較深的棘手問題，就要借助工具。“工欲善其事，必先利其器”，什么情況下要借助工具呢？

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

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

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

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

第五步，列出疑點和復盤。

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

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

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

現(xiàn)象：

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

分析：

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

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

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

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

解決：

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

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

圖3

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

圖4

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

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

分析：

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

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

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

優(yōu)化解決：

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

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

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

圖5

分析：

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

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

解決：

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

四、總結(jié)

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

責任編輯：