还有,凤姐的那句”舒服”,太TM销魂了~艹!!!

众所周知，在国内上网会遇到各种各样不同的人为网络故障，使得我们无法正常访问很多网站。但由于很多人并不熟悉网络，很多时候会无法区分不同的网络故障，导致明明是网络故障，却认为是服务器故障；或明明是服务器故障，却认为是网络故障的情况。我觉得有必要说明一下不同网络故障的特征，以及区分它们并解决它们的方法。

　　在国内上网环境中，我们经常遇到的网络故障有：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解析、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传输的内容。详见月光博客《破解Google Gmail的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会话劫持，使用不同的本地应用层代理服务器进行广告过滤。

　　在国内常见的人为网络故障都介绍完了，同学们都可以区分不同的故障了并加以解决吗？

本文来自：月光博客

Visual Studio2010网剧 第一集：《想做你的Code》

Visual Studio2010网剧 第二集《让爱延长》

Visual Studio2010网剧 第三集：《幸福也需要敏捷》