| 導購 | 订阅 | 在线投稿
分享
 
 
 

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

來源:互聯網  2011-12-04 03:10:38  評論

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

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

1、DNS劫持

DNS劫持會導致我們訪問了一些不存在的或不穩定的網站的時候,訪問到的卻是電信114搜索或訪問Google卻顯示了Baidu的主頁》。

如果需要確認自己是否處在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或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解析、VPN或利用系統的漏洞了。

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封鎖,我們只能通過加密代理、VPN或利用系統的漏洞進行訪問這些網站了。

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

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

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

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

6、無狀態的TCP連接重置

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

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

7、SSL證書過濾

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

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

8、SSL劫持

斷開https連接雖然能阻止民衆訪問“有害信息”,但並不知道訪問了什麽有害信息。基于這一點,針對https的弱點(信任所有證書頒發機構CA),CNNIC申請成爲了頂級證書頒發機構(Root CA),從而可以發假證書進行中間人攻擊,從而破解https傳輸的內容。

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

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

9、HTTP會話劫持

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

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

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

來源:讀者投稿。 作者Twitter:@davidsky2012,作者Google Reader: https://www.google.com/reader/shared/lehui99

原創文章如轉載,請注明:轉載自月光博客 [ http://www.williamlong.info/ ]

本文鏈接地址:http://www.williamlong.info/archives/2195.html

  衆所周知,在國內上網會遇到各種各樣不同的人爲網絡故障,使得我們無法正常訪問很多網站。但由于很多人並不熟悉網絡,很多時候會無法區分不同的網絡故障,導致明明是網絡故障,卻認爲是服務器故障;或明明是服務器故障,卻認爲是網絡故障的情況。我覺得有必要說明一下不同網絡故障的特征,以及區分它們並解決它們的方法。   在國內上網環境中,我們經常遇到的網絡故障有:DNS劫持、DNS汙染、IP封鎖、服務器防火牆IP過濾、服務器宕機、基于關鍵詞的TCP連接重置、無狀態的TCP連接重置、SSL證書過濾、SSL劫持、HTTP會話劫持等網絡故障。下面我就依次進行說明:   1、DNS劫持   DNS劫持會導致我們訪問了一些不存在的或不穩定的網站的時候,訪問到的卻是電信114搜索或訪問Google卻顯示了Baidu的主頁》。   如果需要確認自己是否處在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或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解析、VPN或利用系統的漏洞了。   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封鎖,我們只能通過加密代理、VPN或利用系統的漏洞進行訪問這些網站了。   5、基于關鍵詞的TCP連接重置   國內的系統在人們通過http協議訪問國外網站時會記錄所有的內容,一旦出現某些比較“敏感”的關鍵詞時,就會強制斷開TCP連接,記錄雙方IP並保留一段時間 (1分鍾左右),我們的浏覽器也就會顯示“連接被重置”。之後在這一段時間內(1分鍾左右),由于我們和服務器的IP被攝查系統記錄,我們就無法再次訪問這個網站了。我們必須停止訪問這個網站,過了這段時間再次訪問沒有這些關鍵詞的網頁,就又能訪問這個網站了。   由于這些特征,我們判斷是否遭到了基于關鍵詞的TCP連接重置的情況也比較容易。如果浏覽器顯示“連接被重置”,並且在一段時間內無法再次訪問這個網站,之後過了這段時間訪問這個網站上沒有這些關鍵詞的網頁又能訪問的時候,我們就是遭到了基于關鍵詞的TCP連接重置的故障。   正是因爲http協議是明文傳輸的,所以才能基于關鍵詞進行TCP連接重置。所以如果網站支持https加密訪問,我們可以通過https方式訪問網站,從而解決這個問題。但如果網站不支持https方式訪問,我們只能通過加密代理、VPN或利用系統的漏洞進行訪問了。而且國內的系統對付https也不是沒有其他手段了。除了IP封鎖外,還有無狀態的TCP連接重置、SSL證書過濾、SSL劫持等手段,下面進行依次介紹。   6、無狀態的TCP連接重置   由于https是加密傳輸數據的協議,系統無法知道通過https協議傳輸了什麽內容,但又不允許民衆使用https訪問“有害信息”,所以系統只要監測到(系統只是知道訪問了這個網站的https協議,並不知道其中傳輸的內容)訪問了指定網站的https協議(比如Google Docs的https訪問方式),就會強制斷開TCP連接。這樣,這些網站的https協議在國內就無法直接使用了,很多人被迫使用http協議,從而傳輸的所有內容被系統所記錄。   無狀態的TCP連接重置的結果也是浏覽器顯示“連接被重置”,只不過無論訪問這個服務器上的任何網頁都會被重置。如果要解決這個問題,也只能依靠加密代理、VPN或利用系統的漏洞了。   7、SSL證書過濾   和無狀態的TCP連接重置一樣,由于https是加密傳輸數據的協議,系統無法知道通過https協議傳輸了什麽內容,但又不允許民衆使用https訪問“有害信息”,除了域名汙染和無狀態的TCP連接重置防止無法審查內容外,還有SSL證書過濾的審查手段。由于https傳輸過程中,SSL證書卻是明文傳輸的,所以可以監測SSL證書是否掰發給指定域名的。如果確實如此,那麽就強制斷開TCP連接,浏覽器也會顯示“連接被重置”。SSL證書過濾只發生在使用https訪問網站的時候。   SSL證書過濾的情況比較少。如果需要解決這個問題,也只能依靠加密代理、VPN或利用系統的漏洞了。   8、SSL劫持   斷開https連接雖然能阻止民衆訪問“有害信息”,但並不知道訪問了什麽有害信息。基于這一點,針對https的弱點(信任所有證書頒發機構CA),CNNIC申請成爲了頂級證書頒發機構(Root CA),從而可以發假證書進行中間人攻擊,從而破解https傳輸的內容。   如果遭到了SSL劫持,很難發現。我們通過https訪問國外網站的時候必須每次檢查一下證書是否爲國內的證書頒發機構頒發。如果爲國內的證書頒發機構頒發,那麽很可能遭到了SSL劫持,必須馬上停止繼續訪問。   如果要解決SSL劫持,我們可以去浏覽器中禁止比如CNNIC那樣的國內證書頒發機構的證書(比如《CNNIC,我不信任你》)。但這並不能完全解決問題,如果某一天一個不知名的國內證書頒發機構參與了SSL劫持就很難發現。最終我們還需要依賴加密代理或VPN。   9、HTTP會話劫持   HTTP會話劫持是修改正常的http返回結果,可以在其中加入廣告,甚至是病毒木馬。而一般上網被http會話劫持加入廣告,很有可能認爲是網站自己的廣告。由于http協議是明文傳輸的,http會話劫持也就可以做到。月光博客中《電信級的網絡彈出廣告》、《獲取了電信惡意彈出廣告的罪證》和《誰控制了我們的浏覽器?》也有詳細介紹http會話劫持。HTTP會話劫持通常是ISP爲了推送廣告而實施的,但並不排除這一手段今後會被系統所利用。   要解決HTTP會話劫持,月光博客中也提供了一種解決思路——《解除ADSL彈出廣告的方法》。使用浏覽器插件屏蔽廣告能解決部分問題,也不能完全解決問題。如果要從技術手段解決HTTP會話劫持,一種辦法是使用加密代理和VPN訪問所有的網站,包括國內的,但也不能完全解決問題,如果HTTP會話劫持是在服務器附近的路由器上設置的,這種方法也無法解決;另一種辦法是針對不同的HTTP會話劫持,我們通過刷路由器固件的方式再劫持回來(dd-wrt和tomato路由器固件支持自定義,可能可以把HTTP會話再劫持回原來的數據),或者針對不同的HTTP會話劫持,使用不同的本地應用層代理服務器進行廣告過濾。   在國內常見的人爲網絡故障都介紹完了,同學們都可以區分不同的故障了並加以解決嗎?   來源:讀者投稿。 作者Twitter:@davidsky2012,作者Google Reader: https://www.google.com/reader/shared/lehui99   原創文章如轉載,請注明:轉載自月光博客 [ http://www.williamlong.info/ ]   本文鏈接地址:http://www.williamlong.info/archives/2195.html
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有