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

---

CDN網絡訪問拓撲

既然提到了CDN網絡，那就順帶提一句吧。

這回可以開始廢話了吧？：大體的工作邏輯有用戶的訪問、localdns的解析、CDN資源調度、資源應答。

如果按照這種方式去運營CDN，估計CDN行業早就倒閉了，先不說資源調度的好壞，如果有惡意的攻擊流量，整個CDN系統就直接可以GG思密達了。

IIS7網站監控工具可以做到提前預防各類網站劫持，并且是免費在線查詢，通過查詢知道域名是否健康等等。

它可以做到24小時定時監控：

2、網站是否被劫持

3、域名是否被墻

4、DNS是否被污染

5、獨家檢測網站真實的完全打開時間

檢測地址：IIS7網站檢測

所以我這里也只是為了闡述運營商劫持行為，簡單的說明了一下CDN網絡，讀者千萬不要認為CDN如此的簡單，CDN需要更多更強大的調度系統、數據監控系統、nginx、lvs等系統技術（我也就知道這些了）。高端的CDN廠商還有自建專線、自建IDC、甚至用到了ISP的骨干策略MPLS-TE。這些都是不可小覷的技術，詳細的CDN知識我就不賣弄了，畢竟我只是做網絡的，對系統部分還很薄弱，喜歡了解的讀者可以閱讀《CDN技術詳解》來增長對CDN的見解。

運營商劫持概述

劫持的目的

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

劫持的方法

運營商/或者小區寬帶會有分光器設備，因此可以把用戶請求流量進行映射，從而獲取用戶請求響應，即可達到用戶需要什么，然后再根據搶先建立HTTP連接，優先傳給用戶數據，這樣真正提供資源的服務器返回來的數據就自然的被丟棄掉了。

劫持的演變

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

劫持類別

劫持大可分為三類：

– DNS解析劫持

– 域名302劫持

– NATip劫持

關于DNS劫持

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

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

1、把轉發列表寫到named.conf文件里，更新我們的轉發ip

2、然后編寫策略針對我們要去的域名從BGP出口出去，防止NAT。

http://x.x.x.x.com，（綁定hosts： http://xxxx.xxxx.com ）

zone "http://cdnxx.com" {

type forward;

forward first;

forwarders { x.x.x.x;x.x.x.x;x.x.x.x};

};

zone "http://cdnxx.com" {

type forward;

forward first;

forwarders { x.x.x.x;x.x.x.x;x.x.x.x };

};

場景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

HTTP302即為：訪問的資源暫時性轉移，得到新的資源位置，然后重新訪問獲取資源。

這其實就是典型的CDN運營架構了，CDN的資源調度就是這么去做的。假如北京的用戶需要訪問某個網站，CDN公司得到網站方的授權后，就會把直接訪問的URL做CNAME跳轉到CDN調度服務器上，接下來根據區域localdns的識別將北京的用戶請求，調度到就近的節點進行服務。

那么，CDN可以利用HTTP302進行調度，那么運營商“更”可以這么做了，這里說的“可以”中心意義是運營商有著近水樓臺的優勢，在IDC出口方向可以把流量做鏡像到自己的服務器上，該服務器可以將URL上的資源提取出來，然后查找自己的<span class="colour" style="color: rgb(120, 157, 191);">數據庫</span>、存儲資源是否有該資源，如果有那么就會302到自己的服務器上，為用戶提供資源，從而攔截了正常的請求響應。如果沒有該文件，運營商通常會統計資源的熱點程度，畢竟運營商的存儲設備也不是無限大的，為了提高利用率肯定要優先緩存訪問量高的文件。接著剛才的說，如果存儲設備里沒有該資源，那么運營商會監聽這個請求流，直到請求返回應答，這樣自己在本地也就可以備份一份資源了，如再有請求過來，就可以直接吐給用戶數據。這樣就做到了劫持。

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

解決辦法

原理和現象比較好說，但是說到解決辦法其實并沒有什么主動出擊，考自己攻破的方法，只能求爺爺告奶奶的去找我們的IDC機房，讓他們把我們劫持的現象(HTTP302)、訴求、相關數據上傳到集團哪里，找到相對應的人員才可以解決。運營商一般處理辦法就是在他們自己的緩存設備上把劫持的域名加入白名單，然后清除緩存。這樣再過來請求的流就不會被劫持了。

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

• 我們應該向客戶說明情況并收集一些證據如劫持證據、證明CDN授權、監控數據等。
• 聯系劫持ip歸屬地的IDC機房負責人或者運營商的人來說明情況。
• 有些運營商也建議直接找當地公安局、網警進行報案，并配合處理。
• 自行去當地機房查看設備情況，一同排查內部架構。
• 找到被劫持的友商了解情況，通過公司高層、集團領導出面處理。
• 技術過硬的話可以采取HTTPS進行加密傳輸，或者其他技術手段避開數據采集。
• 最后一點，希望以上建議可以解決問題，如不能，請看下一條。
• 最最后一條，終極奧義！以其人之道還治其人之身！

收個尾巴

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

2017年10月25日

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

我先說現象：

抓包看到，客戶端有request請求包過來，然后按理說服務器需要回response返回給客戶端，但是隨即又收到了客戶端發來的RST這就表示客戶端又把連接關閉，起初排查時候認為是下載速遞有影響導致客戶端等待不及就把連接手工斷開了，或者是客戶端的故障導致重新建聯，隨后找到運營商那邊了解情況，發現業務訪問沒有影響，細查后發現是有緩存設備。

緩存原理：

當客戶端（真）發起請求時，經過一系類的dns解析、調度來我們服務器，然后建立tcp連接后準備請求數據，然后緩存服務器進行數據流分析，根據文件類型做匹配，如果匹配到緩存服務器中有該請求文件，則做2個動作，第一是返給客戶端302跳轉到自己的緩存存儲服務器上請求數據，第二是模仿客戶端的ip地址向真正的業務服務器發起斷開連接，服務器會認為客戶端（假）取消了建聯，進而切斷了真的客戶端與服務器之間的數據交互。然后緩存服務器把資源吐給客戶端。

排查后就需要聯系緩存業務的人員取消劫持，只是在排查過程中很難發現有“中間人”在從中搗亂。