如何區分國內上網環境中不同的人爲網絡故障

原文鏈接:http://www.williamlong.info/archives/2195.html 

衆所周知,在國內上網會遇到各種各樣不同的人爲網絡故障,使得我們無法正常訪問很多網站。但由於很多人並不熟悉網絡,很多時候會無法區分不同的網絡故障,導致明明是網絡故障,卻認爲是服務器故障;或明明是服務器故障,卻認爲是網絡故障的情況。我覺得有必要說明一下不同網絡故障的特徵,以及區分它們並解決它們的方法。

  在國內上網環境中,我們經常遇到的網絡故障有:DNS劫持、DNS污染、IP封鎖、服務器防火牆IP過濾、服務器宕機、基於關鍵詞的TCP連接重置、無狀態的TCP連接重置、SSL證書過濾、SSL劫持、HTTP會話劫持等網絡故障。下面我就依次進行說明:

  1、DNS劫持

  DNS劫持會導致我們訪問了一些不存在的或不穩定的網站的時候,訪問到的卻是電信114搜索(詳見月光博客《斷網後互聯星空的瀏覽器劫持》)或訪問Google卻顯示了Baidu的主頁(詳見月光博客《Google博客搜索搖身一變成百度》)。

  如果需要確認自己是否處在DNS劫持的環境中,我們可以在Windows命令行cmd中使用Windows自帶的網絡診斷工具nslookup查找一個不存在或不穩定的域名進行一下網絡診斷:

  C:\>nslookup www.SomeRandomDomainName.com

  Server: ns-pd.online.sh.cn

  Address: 202.96.209.133

  Non-authoritative answer:

  Name: www.SomeRandomDomainName.com

  Address: 218.83.175.155

  我們看到,www.SomeRandomDomainName.com本應該是一個不存在的域名,DNS服務器應該告訴我們這個域名不存在,但我們卻看到DNS服務器告訴我們這個域名的IP爲218.83.175.155(不同地區的114搜索的IP都不同,可能得到的IP並不是218.83.175.155,而是自己所在地區的114搜索的服務器IP地址),而這個IP卻是114搜索的IP,導致我們在瀏覽器中訪問這個網站時看到的是114搜索的網頁。

  如果需要解決DNS劫持的問題,可以把自己的域名解析服務器換乘國外的,比如OpenDNS(詳見月光博客《使用OpenDNS解決DNS域名劫持》)或Google DNS(詳見月光博客《Google推出免費DNS服務》)。

  解決之後我們再次使用nslookup查找一下這個網站:

  C:\>nslookup www.SomeRandomDomainName.com

  Server: google-public-dns-a.google.com

  Address: 8.8.8.8

  *** google-public-dns-a.google.com can't find www.SomeRandomDomainName.com: Non-existent domain

  我們看到DNS服務器正確的告訴了我們這個域名不存在,我們不會被劫持到114搜索了。

  不過,正如《使用OpenDNS解決DNS域名劫持》中最後一段所說的那樣,“但是對於DNS污染的劫持,使用OpenDNS也無法解決問題”。那麼接下來,我就介紹一下DNS污染。

  2、DNS污染

  由於DNS劫持可以通過把域名解析服務器更換爲國外的來解決問題,所以系統需要使用DNS污染來封鎖一些域名。這樣,即使使用國外的域名服務器也得不到服務器的正確IP,所以也就無法訪問這些服務器了。比如現在著名的微博客始祖twitter主頁就遭到了DNS污染。

  如果需要確認域名遭到了DNS污染而不是其他的故障,首先要了解,DNS劫持是由國內的域名服務器完成的,所以我們把域名服務器換成國外的就可以解決問題;而DNS污染是由系統完成的,所以即使更換了域名服務器,系統仍舊可以發送僞造的域名解析結果替換正確的解析結果。所以我們可以通過使用一個不存在的國外IP作爲我們的域名服務器進行診斷究竟是DNS劫持還是DNS污染。我們仍舊通過使用nslookup進行網絡診斷,選一個不存在的國外IP爲144.223.234.234:

  C:\>nslookup twitter.com 144.223.234.234

  DNS request timed out.

  timeout was 2 seconds.

  *** Can't find server name for address 144.223.234.234: Timed out

  Server: UnKnown

  Address: 144.223.234.234

  Name: twitter.com

  Address: 93.46.8.89

  我們看到,由於144.223.234.234不存在,理應沒有任何返回。但我們卻得到了一個錯誤的IP:93.46.8.89。我們再測試一下剛纔被DNS劫持的IP的情況:

  C:\>nslookup www.SomeRandomDomainName.com 144.223.234.234

  DNS request timed out.

  timeout was 2 seconds.

  *** Can't find server name for address 144.223.234.234: Timed out

  Server: UnKnown

  Address: 144.223.234.234

  DNS request timed out.

  timeout was 2 seconds.

  DNS request timed out.

  timeout was 2 seconds.

  *** Request to UnKnown timed-out

  我們看到,www.SomeRandomDomainName.com 沒有返回結果,那麼它沒有被DNS污染。

  如果要解決DNS污染,我們只能使用各種加密代理進行遠程DNS解析、***或利用系統的漏洞了。

  3、IP封鎖

  這裏IP封鎖指的是國內把國外服務器的IP加入了系統的黑名單,導致大部分地區甚至全國無法直接訪問服務器。由於系統是分佈式的,所以有可能出現部分地區可以訪問,部分地區不能訪問的情況。比如現在知名的雲存儲服務Dropbox的主頁,就是遭到了IP封鎖。

  首先我們把域名服務器設置爲國外的,排除了DNS劫持的問題。之後我們診斷一下dropbox的域名是否遭到了DNS污染:

  C:\>nslookup www.dropbox.com 144.223.234.234

  DNS request timed out.

  timeout was 2 seconds.

  *** Can't find server name for address 144.223.234.234: Timed out

  Server: UnKnown

  Address: 144.223.234.234

  DNS request timed out.

  timeout was 2 seconds.

  DNS request timed out.

  timeout was 2 seconds.

  *** Request to UnKnown timed-out

  顯然也沒有遭到DNS污染。那麼接下去我們可以在沒有過濾ICMP協議的網絡環境中(有些小區寬帶和有些公司的內部網絡過濾了ICMP協議,無法使用tracert),我們可以在Windows命令行cmd中使用Windows自帶的網絡診斷工具tracert進行一下網絡診斷是網站遭到了IP封鎖還是其他的故障:

  C:\>tracert -d www.dropbox.com

  Tracing route to www.dropbox.com [174.36.30.70]

  over a maximum of 30 hops:

  1 18 ms 19 ms 26 ms 58.35.240.1

  2 15 ms 20 ms 29 ms 58.35.240.1

  3 13 ms 10 ms 14 ms 124.74.20.45

  4 14 ms 14 ms 15 ms 124.74.209.137

  5 10 ms 15 ms 14 ms 61.152.86.58

  6 * * * Request timed out.

  7 * * * Request timed out.

  8 * * * Request timed out.

   ……

  我們看到,最後一個IP爲61.152.86.58(不同地區的IP不一樣),之後就不通了,顯然在61.152.86.58附近遭到了IP封鎖。那麼我們打開ip138查一下61.152.86.58是誰在掌控:

  您查詢的IP:61.152.86.58

  * 本站主數據:上海市 電信

  * 參考數據一:上海市 電信

  * 參考數據二:上海市 電信

  顯然,問題在上海電信這裏(其他地區可能是地區的本地電信),而不是dropbox服務器的問題。

  4、服務器防火牆IP過濾和服務器宕機

  把這兩點放在一起寫是因爲這兩種情況的對外表現是一樣的。但和IP封鎖卻有很大區別。IP封鎖的最後一個可達IP是中國的,而服務器防火牆IP過濾和服務器當機時的最後一個可達IP卻是國外的。比如我們拿75.101.142.137做試驗,之前在上面部署過alexa的網站,現在這個IP上暫時沒有服務器(可以看成服務器宕機):

  C:\>tracert -d 75.101.142.237

  Tracing route to 75.101.142.237 over a maximum of 30 hops

  1 25 ms 18 ms 18 ms 58.35.240.1

  2 25 ms 42 ms 27 ms 58.35.240.1

  3 10 ms 15 ms 14 ms 124.74.37.9

  4 49 ms 59 ms 12 ms 124.74.209.129

  5 14 ms 14 ms 14 ms 61.152.86.142

  6 10 ms 14 ms 15 ms 202.97.35.154

  7 14 ms 15 ms 14 ms 202.97.34.126

  8 194 ms 195 ms 194 ms 202.97.51.138

  9 171 ms 170 ms 173 ms 202.97.50.54

  10 215 ms 179 ms 175 ms 63.146.27.133

  11 279 ms 280 ms 278 ms 67.14.36.6

  12 * * * Request timed out.

  13 249 ms 249 ms 244 ms 72.21.199.40

  14 254 ms 254 ms 254 ms 72.21.222.157

  15 250 ms 250 ms 249 ms 216.182.232.53

  16 270 ms 270 ms 273 ms 216.182.224.22

  17 272 ms 269 ms 289 ms 75.101.160.35

  18 * * * Request timed out.

  19 * * * Request timed out.

  20 * * * Request timed out.

  我們看到最後一個可達IP爲75.101.160.35,然後我們查一下這個IP是誰的呢:

  您查詢的IP:75.101.160.35

  * 本站主數據:美國

  * 參考數據一:美國

  * 參考數據二:美國 華盛頓州金縣西雅圖市亞馬遜公司

  顯然,這個是服務器故障。

  如果要解決IP封鎖,我們只能通過加密代理、***或利用系統的漏洞進行訪問這些網站了。

  5、基於關鍵詞的TCP連接重置

  國內的系統在人們通過http協議訪問國外網站時會記錄所有的內容,一旦出現某些比較“敏感”的關鍵詞時,就會強制斷開TCP連接,記錄雙方IP並保留一段時間 (1分鐘左右),我們的瀏覽器也就會顯示“連接被重置”。之後在這一段時間內(1分鐘左右),由於我們和服務器的IP被攝查系統記錄,我們就無法再次訪問這個網站了。我們必須停止訪問這個網站,過了這段時間再次訪問沒有這些關鍵詞的網頁,就又能訪問這個網站了。

  由於這些特徵,我們判斷是否遭到了基於關鍵詞的TCP連接重置的情況也比較容易。如果瀏覽器顯示“連接被重置”,並且在一段時間內無法再次訪問這個網站,之後過了這段時間訪問這個網站上沒有這些關鍵詞的網頁又能訪問的時候,我們就是遭到了基於關鍵詞的TCP連接重置的故障。

  正是因爲http協議是明文傳輸的,所以才能基於關鍵詞進行TCP連接重置。所以如果網站支持https加密訪問,我們可以通過https方式訪問網站,從而解決這個問題。但如果網站不支持https方式訪問,我們只能通過加密代理、***或利用系統的漏洞進行訪問了。而且國內的系統對付https也不是沒有其他手段了。除了IP封鎖外,還有無狀態的TCP連接重置、SSL證書過濾、SSL劫持等手段,下面進行依次介紹。

  6、無狀態的TCP連接重置

  由於https是加密傳輸數據的協議,系統無法知道通過https協議傳輸了什麼內容,但又不允許民衆使用https訪問“有害信息”,所以系統只要監測到(系統只是知道訪問了這個網站的https協議,並不知道其中傳輸的內容)訪問了指定網站的https協議(比如Google Docs的https訪問方式),就會強制斷開TCP連接。這樣,這些網站的https協議在國內就無法直接使用了,很多人被迫使用http協議,從而傳輸的所有內容被系統所記錄。

  無狀態的TCP連接重置的結果也是瀏覽器顯示“連接被重置”,只不過無論訪問這個服務器上的任何網頁都會被重置。如果要解決這個問題,也只能依靠加密代理、***或利用系統的漏洞了。

  7、SSL證書過濾

  和無狀態的TCP連接重置一樣,由於https是加密傳輸數據的協議,系統無法知道通過https協議傳輸了什麼內容,但又不允許民衆使用https訪問“有害信息”,除了域名污染和無狀態的TCP連接重置防止無法審查內容外,還有SSL證書過濾的審查手段。由於https傳輸過程中,SSL證書卻是明文傳輸的,所以可以監測SSL證書是否掰發給指定域名的。如果確實如此,那麼就強制斷開TCP連接,瀏覽器也會顯示“連接被重置”。SSL證書過濾只發生在使用https訪問網站的時候。

  SSL證書過濾的情況比較少。如果需要解決這個問題,也只能依靠加密代理、***或利用系統的漏洞了。

  8、SSL劫持

  斷開https連接雖然能阻止民衆訪問“有害信息”,但並不知道訪問了什麼有害信息。基於這一點,針對https的弱點(信任所有證書頒發機構CA),CNNIC申請成爲了頂級證書頒發機構(Root CA),從而可以發假證書進行中間人***,從而破解https傳輸的內容。詳見月光博客《破解Google Gmail的https新思路》。

  如果遭到了SSL劫持,很難發現。我們通過https訪問國外網站的時候必須每次檢查一下證書是否爲國內的證書頒發機構頒發。如果爲國內的證書頒發機構頒發,那麼很可能遭到了SSL劫持,必須馬上停止繼續訪問。

  如果要解決SSL劫持,我們可以去瀏覽器中禁止比如CNNIC那樣的國內證書頒發機構的證書(比如《CNNIC,我不信任你》)。但這並不能完全解決問題,如果某一天一個不知名的國內證書頒發機構參與了SSL劫持就很難發現。最終我們還需要依賴加密代理或***。

  9、HTTP會話劫持

  HTTP會話劫持是修改正常的http返回結果,可以在其中加入廣告,甚至是病毒***。而一般上網被http會話劫持加入廣告,很有可能認爲是網站自己的廣告。由於http協議是明文傳輸的,http會話劫持也就可以做到。月光博客中《電信級的網絡彈出廣告》、《獲取了電信惡意彈出廣告的罪證》和《誰控制了我們的瀏覽器?》也有詳細介紹http會話劫持。HTTP會話劫持通常是ISP爲了推送廣告而實施的,但並不排除這一手段今後會被系統所利用。

  要解決HTTP會話劫持,月光博客中也提供了一種解決思路——《解除ADSL彈出廣告的方法》。使用瀏覽器插件屏蔽廣告能解決部分問題,也不能完全解決問題。如果要從技術手段解決HTTP會話劫持,一種辦法是使用加密代理和***訪問所有的網站,包括國內的,但也不能完全解決問題,如果HTTP會話劫持是在服務器附近的路由器上設置的,這種方法也無法解決;另一種辦法是針對不同的HTTP會話劫持,我們通過刷路由器固件的方式再劫持回來(dd-wrt和tomato路由器固件支持自定義,可能可以把HTTP會話再劫持回原來的數據),或者針對不同的HTTP會話劫持,使用不同的本地應用層代理服務器進行廣告過濾。

  在國內常見的人爲網絡故障都介紹完了,同學們都可以區分不同的故障了並加以解決嗎?

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章