運營商劫持 DNS HTTP302

2021-08-20 10:57:31 字數 3227 閱讀 1435

本人以網路技術出身,近兩年接觸cdn網路,處理了一些cdn方面的網路問題,大多數以運營商丟包,延遲抖動為主,也處理一些硬體故障,比如機械硬碟的讀寫io測試,記憶體條相容性測試,伺服器ipmi規劃等。這篇文章打算把自己對運營商對資源請求的劫持寫下來,這個其實不是很罕見的事例,也不是網上找不到解決辦法,也不是無法理解的尖鑽技術,只是羅列一下自己的所知。

既然提到了cdn網路,那就順帶提一句吧。

廢話不多說,先上圖。

這回可以開始廢話了吧?:大體的工作邏輯有使用者的訪問、localdns的解析、cdn資源排程、資源應答。

如果按照這種方式去運營cdn

架構,估計cdn行業早就倒閉了,先不說資源排程的好壞,如果有惡意的攻擊流量,整個cdn系統就直接可以gg思密達了。

其實目的很簡單,關於運營商劫持,一般運營商也不是無故做劫持,畢竟他們維護伺服器,維護相應裝置(比如分光器、分流器)也需要成本,運營商主要劫持出省流量,對於「小」運營商來說他們有省內流量考核,跨省訪問會增加成本輸出,集團控制出省流量,所以劫持往往發生在省間傳輸上。其次所有運營商都可能會做劫持,目的是減少省骨幹網路鏈路的負載壓力,盡可能的減少中繼鏈路、遠距離骨幹鏈路,負載能力弱的鏈路上的流量,則會出現劫持的現象。

運營商/或者小區寬頻會有分光器裝置,因此可以把使用者請求流量進行對映,從而獲取使用者請求響應,即可達到使用者需要什麼,然後再根據搶先建立http連線,優先傳給使用者資料,這樣真正提供資源的伺服器返回來的資料就自然的被丟棄掉了。

劫持的邏輯,慢慢的轉化為了目前的cdn廠商在做的事,當然cdn廠商的流量排程主要是為了解決客戶資源的分布式訪問,避免使用者訪問資源時長時間等待。我也是在接觸cdn網路以後,才慢慢接觸到了運營商劫持,運營商主要的劫持動作還是修改訪問資源的ip,也就是網域名稱302了。

劫持大可分為三類:

– dns解析劫持

– 網域名稱302劫持

– natip劫持

dns劫持也可以理解為使用者的請求去往了錯誤的dns伺服器進行查詢解析,返回來的目的主機ip自然不是我們想要達到的資源伺服器主機,這往往發生在使用者請求的第一步,目前在鵬博士網內遇見的比較常見。

長寬資源經常出現被劫持和**錯誤的現象。解決辦法如下:

1、把**列表寫到named.conf檔案裡,更新我們的**ip

2、然後編寫策略針對我們要去的網域名稱從bgp出口出去,防止nat。

x.x.x.x.com,(繫結hosts: ***x.***x.com )

zone "cdnxx.com" ;

};zone "cdnxx.com" ;

};場景1:

dns伺服器為本地運營商的dnsip,但是解析到的目標cache是其他省市的ip。

原因是**或者nat沒有做好,沒有**到我們指定的dns伺服器上進行解析,或者從nat口出去,改變了長寬的源位址。

場景2:

dns伺服器為本地運營商的dnsip,但是解析到的目標cache是本省市的ip。

原因是本地運營商有cache快取,相當於小型的cdn節點伺服器(瀏覽器的cookie),要把我們需要的網域名稱新增到快取黑名單裡,不進行本地快取。

場景3:

dns伺服器為本地運營商的dnsip,但是解析出來的ip,有時候是正確的,有時候是其他運營商的。

原因是該地市有多個cache伺服器,需要在快取伺服器裡把所有的**ip和網域名稱都做好快取黑名單。

運營商解決時需要新增的列表:

ixcache快取裝置 panabit(流控)把不做快取的網域名稱加入到名單裡。

場景4:

dns解析有時候成功有時候失敗。

原因是長寬本地會有快取伺服器,之上有乙個快取控制器,如果我們的解析被快取伺服器命中,就會本地直接返回結果,所以要在控制器上做策略,禁止呼叫到快取。

其實我在排版的時候一直在糾結,我這個圖應該放在這部分的前面還是後面,左右了半天還是決定貼在後面吧,這樣不會衝亂dns forward的配置。

http302即為:訪問的資源暫時性轉移,得到新的資源位置,然後重新訪問獲取資源。

這其實就是典型的cdn運營架構了,cdn的資源排程就是這麼去做的。假如北京的使用者需要訪問某個**,cdn公司得到**方的授權後,就會把直接訪問的url做cname跳轉到cdn排程伺服器上,接下來根據區域localdns的識別將北京的使用者請求,排程到就近的節點進行服務。

那麼,cdn可以利用http302進行排程,那麼運營商「更」可以這麼做了,這裡說的「可以」中心意義是運營商有著近水樓台的優勢,在idc出口方向可以把流量做映象到自己的伺服器上,該伺服器可以將url上的資源提取出來,然後查詢自己的

資料庫、儲存資源是否有該資源,如果有那麼就會302到自己的伺服器上,為使用者提供資源,從而攔截了正常的請求響應。如果沒有該檔案,運營商通常會統計資源的熱點程度,畢竟運營商的儲存裝置也不是無限大的,為了提高利用率肯定要優先快取訪問量高的檔案。接著剛才的說,如果儲存裝置裡沒有該資源,那麼運營商會監聽這個請求流,直到請求返回應答,這樣自己在本地也就可以備份乙份資源了,如再有請求過來,就可以直接吐給使用者資料。這樣就做到了劫持。

當然,再進一步講,劫持動作可以做到你家門口,原理、意義,同上。

原理和現象比較好說,但是說到解決辦法其實並沒有什麼主動出擊,考自己攻破的方法,只能求爺爺告奶奶的去找我們的idc機房,讓他們把我們劫持的現象(http302)、訴求、相關資料上傳到集團**,找到相對應的人員才可以解決。運營商一般處理辦法就是在他們自己的快取裝置上把劫持的網域名稱加入白名單,然後清除快取。這樣再過來請求的流就不會被劫持了。

我還見過其他方式的劫持,不是運營商自己做的,而是和競爭廠商一起做的,比如a公司和b公司為行業利益相爭的友商,不湊巧的是a公司的實力比較雄厚可以收攏運營商的人,或者某個idc機房的人,在機房出口或者小區出口架設分流器等裝置來採集通過的業務流量,一旦流量被匹配上之後也直接做劫持,這種情況再工作中雖然不常見,但是只要遇到解決起來極其的費勁

暫且,個人對運營商劫持的理解也就到這個層次,但是我相信,在我職業生涯中這裡面的貓膩肯定不是只有這些,運營商想搞事情,誰攔得住?!

2023年10月25日

工作中遇到新的劫持現象,http狀態碼499突增。

我先說現象:

快取原理:

當客戶端(真)發起請求時,經過一系類的dns解析、排程來我們伺服器,然後建立tcp連線後準備請求資料,然後快取伺服器進行資料流分析,根據檔案型別做匹配,如果匹配到快取伺服器中有該請求檔案,則做2個動作,第一是返給客戶端302跳轉到自己的快取儲存伺服器上請求資料,第二是模仿客戶端的ip位址向真正的業務伺服器發起斷開連線,伺服器會認為客戶端(假)取消了建聯,進而切斷了真的客戶端與伺服器之間的資料互動。然後快取伺服器把資源吐給客戶端。

排查後就需要聯絡快取業務的人員取消劫持,只是在排查過程中很難發現有「中間人」在從中搗亂。

運營商的前途

自從3g和重組的訊息放出以來,很多運營商的前輩紛紛退居二線。事情當然不是偶然。以前,我都曾經說過,在中國gsm至少還有5 10年的主流作用道路要走。然而,這也不過是 保守估計。那時事2006年,後來,厥大炮也曾經預言運營商要轉型。而我覺得,運營商只是需要轉變業務側重而已,原因很簡單 通訊技術的成熟和...

CoreTelephony運營商資訊

coretelephony是蘋果提供的用來訪問使用者的移動服務提供商的資訊,比如它的唯一識別符號,以及是否允許voip通話。獲取當前通過的id以及狀態。coretelephony在ios7之前是私有api,在ios7之後蘋果公開了coretelephony。1.可以用coretelephony獲取手...

Cache對運營商的意義,對小運營商的意思更大

cache對運營商的意義 摘要 各網際網路運營商與chinanet等互聯,每月付大量的頻寬租用費,在互聯互通出口 省分節點 都會網路出口或pop點 地市節點,部署使用cache,把大量的內容快取在本地服務域,即把使用者所要訪問的資料 推送 或 分發 到靠近使用者端,最大限度減少上聯出口的流量,對於節...