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

標籤：http   ar   使用   sp   for   strong   on   資料   art   

add by zhj：學習了，原來GFW可利用的手段這麼多啊，當然，我猜測真正的手段應該比這還多。而且GFW經常不斷的升級。

作者Twitter：@davidsky2012 投稿到月光部落格發表  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劫持可以通過把網域名稱解析伺服器更換為國外的來解決問題，所以GFW需要使用DNS汙染來封鎖一些網域名稱。這樣，即使使用國外的網域名稱伺服器也得不到伺服器的正確IP，所以也就無法訪問這些伺服器了。比如現在著名的微部落格始祖twitter首頁就遭到了DNS汙染。

　 　如果需要確認網域名稱遭到了DNS汙染而不是其他的故障，首先要瞭解，DNS劫持是由國內的網域名稱伺服器完成的，所以我們把網域名稱伺服器換成國外的就可以解決問 題；而DNS汙染是由GFW完成的，所以即使更換了網域名稱伺服器，GFW仍舊可以發送偽造的網域名稱解析結果替換正確的解析結果。所以我們可以通過使用一個不存在的 國外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或利用GFW的漏洞了。

　　3、IP封鎖

　　這裡IP封鎖指的是國內把國外伺服器的IP加入了GFW的黑名單，導致大部分地區甚至全國無法直接存取伺服器。由於GFW是分布式的，所以有可能出現部分地區可以訪問，部分地區不能訪問的情況。比如現在知名的雲端儲存體服務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或利用GFW的漏洞進行訪問這些網站了。

　　5、基於關鍵詞的TCP串連重設

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

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

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

　　6、無狀態的TCP串連重設

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

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

　　7、SSL認證過濾

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

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

　　8、SSL劫持

　 　斷開https串連雖然能阻止民眾訪問“有害資訊”，但並不知道訪問了什麼有害資訊。基於這一點，針對https的弱點（信任所有憑證授權單位 CA），CNNIC申請成為了頂級憑證授權單位（Root CA），從而可以發假認證進行中間人攻擊，從而破解https傳輸的內容。詳見月光部落格《破解Google Gmail的https新思路》。

　　如果遭到了SSL劫持，很難發現。我們通過https訪問國外網站的時候必須每次檢查一下認證是否為國內的憑證授權單位頒發。如果為國內的憑證授權單位頒發，那麼很可能遭到了SSL劫持，必須馬上停止繼續訪問。

　　如果要解決SSL劫持，我們可以去瀏覽器中禁止比如CNNIC那樣的國內憑證授權單位的認證（比如《CNNIC，我不信任你》）。但這並不能完全解決問題，如果某一天一個不知名的國內憑證授權單位參與了SSL劫持就很難發現。最終我們還需要依賴加密代理或VPN。

　　9、HTTP工作階段劫持

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

　　要解決HTTP工作階段劫持，月光部落格中也提供了一種解決思路——《解除ADSL彈出廣告的方法》。 使用瀏覽器外掛程式屏蔽廣告能解決部分問題，也不能完全解決問題。如果要從技術手段解決HTTP工作階段劫持，一種辦法是使用加密代理和VPN訪問所有的網站，包 括國內的，但也不能完全解決問題，如果HTTP工作階段劫持是在伺服器附近的路由器上設定的，這種方法也無法解決；另一種辦法是針對不同的HTTP工作階段劫持， 我們通過刷路由器韌體的方式再劫持回來（dd-wrt和tomato路由器韌體支援自訂，可能可以把HTTP會話再劫持回原來的資料），或者針對不同的 HTTP工作階段劫持，使用不同的本地應用程式層Proxy 伺服器進行廣告過濾。

　　在國內常見的人為網路故障都介紹完了，同學們都可以區分不同的故障了並加以解決嗎？

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

如何區分國內上網環境中不同的人為網路故障（轉）