在线乱码卡一卡二卡新HD,最近韩国免费观看视频,国产色无码精品视频国产,亚洲男人的天堂久久香蕉

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

【資料圖】

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

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

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

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

圖1

從以上的介紹中可以看到，互聯網邊界網絡猶如一個精密的機器，分層部署環環相扣，在這樣一個網絡中定位一個問題是難度是極大的。然而，一個實際互聯網系統訪問異?？赡鼙冗@個更為復雜：

1、涉及范圍廣?；ヂ摼W故障所涉及的網絡范圍遠遠不止數據中心運維人員維護的數據中心資源范疇，還包括從用戶端到銀行互聯網邊界線路所經過的整個互聯網，包括用戶側網絡，可能是家庭網絡也可能是企業網絡，可能是有線網絡也可能是無線網絡，無線網絡還需要區分WIFI網絡和移動網絡，中間還可能經過多個運營商的廣域網網絡才能到達網站的邊界網絡。而真正的問題根因也可能發生在內網服務器。

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

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

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

第一步，獲取真實完全的故障現象。

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

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

圖2

第二步，判斷影響范圍。

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

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

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

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

第四步，工具分析。

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

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

2、看趨勢。故障發生時一定會出現指標異常，看趨勢可以明顯看出異常發生時間點，以及處置后是否已經恢復；

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

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

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

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

案例一：邊界防火墻會話數突發超閾值告警

現象：

邊界防火墻經常吐出日志報警，并發會話數超過平時十倍，瞬間恢復，查看火墻當前的會話數排名，最高的通信對也只有幾百個會話?；ヂ摼W線路流量無異常，各互聯網業務都正常，無業務促銷秒殺等活動。DDOS設備、WAF設備等安全設備無告警。負載均衡流量、會話數無異常。

分析：

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

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

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

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

解決：

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

互聯網DNS網絡域名解析請求跟蹤圖：

圖3

SYN與SYNACK差異化網絡跟蹤圖：

圖4

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

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

分析：

這是一個典型的“局部問題”，在某市安排當地具有相同運營商號段的科技人員使用手機卡流量上網協助進行測試，發現復現該問題，但訪問行內其他網站及同業APP正常，說明用戶本地運營商網絡基本正常，域名解析正常?？偛繑祿行谋镜厝藛T測試訪問正常，說明服務端正常。這時一個重要信息從應用的開發人員處獲得，移動APP打開后會先加載一個靜態的廣告頁面，如果廣告頁面異常，有可能導致訪問APP失敗的情況。這個靜態的頁面，是從CDN獲取的。

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

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

優化解決：

1、要求CDN運營商緊急隔離當地的緩存節點后業務恢復。2、手機APP增加加載資源超時跳出逃生功能，避免加載不到資源而被卡住。

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

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

圖5

分析：

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

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

解決：

在攻擊黑IP地址名單中刪除相關攔截IP。

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

關鍵詞：