众所周知,在国内上网会遇到各种各样不同的人为网络故障,使得我们无法正常访问很多网站。但由于很多人并不熟悉网络,很多时候会无法区分不同的网络故障,导致明明是网络故障,却认为是服务器故障;或明明是服务器故障,却认为是网络故障的情况。我觉得有必要说明一下不同网络故障的特征,以及区分它们并解决它们的方法。 在国内上网环境中,我们经常遇到的网络故障有: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或利用系统的漏洞了。