精英意识会让人走向孤独

不知道是不是因为前端时间的邮件551拦截错误
GFW做了调整
但是，wiki怎么会解禁了呢
而且搞的sohu都出新闻了
暗自里边猜一下，难道是因为邮件551错误影响太大，但是相关技术人员调试不出来，所以GFW暂时离线了？

sohu的报道：
http://it.sohu.com/20070725/n251233187.shtml

wiki中文：
http://zh.wikipedia.org

－－－－－－－－－－－－－－－－

更新：
wiki虽然能上了，但是，一搜索关键字，就会发现页面出现的零点几秒内，迅速消失了
然后显示404找不到网页，虽然刚才一瞬间貌似出现了搜索结果
这个现象和google上搜索一些“关键字”效果是相同的
因此，应该说是GFW对wiki的过滤方式变化了

原来是DNS劫持和IP封锁的方法，即根本上不去，IP层就不通
现在是允许访问非加密的http主站了，然后做了7层内容过滤
通过主干网路由器上的检查模块，实时拆包分析
发现屏蔽关键字后，抢在wiki的web server应答数据包之前
向浏览器客户端发出RST中断包，此时浏览器看起来就像网络超时一样，页面404错误打不开
这种过滤方式和针对google的一样
因此可以说是wiki被部分放开了，只要不搜索“key word”，就能上

ps：感慨一下，Cisco的设备还是很牛的
几十Gbps的国际骨干网出口上，居然能做7层协议分析
能达到这个性能，其相关过滤模块的计算能力太太太太太太太太太强大了
一个芯片就盖若干个Xeon的计算能力
这个过滤模块应该是RISC架构或者ASIC架构的吧

－－－－－－－－－－－－－－－－－－

继续更新：7月25日晚上又上不去了，看来GFW调试完毕了
何以见得是GFW再次封杀？请看下边分析。

首先我用firefox访问一个肯定不存在的网址，返回下边的页面：“找不到网页”

现在我访问一下wiki，看看报告什么错误，“连接被重置”，哈，看出真相了吧

抓包分析

序号是No.88蓝色标记那行数据包，是我的ip 192.168.0.130 访问wiki的80端口的SYN包
这个时候双方试图建立连接
wiki的服务器接收了我的SYN后，会返回ACK包

序号是No.89绿色标记的那行数据包，是wiki服务器返回给我的ACK包

序号是No.90/91/92的包，是我返回的ACKed数据包，表示建立连接完成
这样，整个TCP三次握手SYN、ACK、ACK+1就都顺利完成了

wiki服务器收到ACK+1后，该把具体的http页面传送过来了
就在这个时候，棕色的数据包出现了，wiki传输过来的不是具体数据，而是RST中断连接数据包
wiki服务器是不会主动断掉连接的，那么是怎么回事呢？

答案很简单，其实哪个RST不是wiki服务器发出的，而是中间的GFW过滤设备
GFW模拟了wiki的ip地址，向浏览器客户端发送了RST中断连接
同时GFW还会模拟客户端浏览器的IP地址，向Wiki服务器发出RST
这样，对于浏览器和wiki服务器看了起来，双方都是RST断开了。。。

如何进一步证明？抓包的时候，看一下第三层IP层的TTL，即数据包的生存期
当浏览器发出一个数据包的时候，默认是128
这是因为Windows默认所有数据包TTL都是128
Unix会默认254
每经过一个路由器，TTL就减少1
查看wiki服务器一开始应答SYN数据包的ACK包，正常的包是TTL是43。

再查查看RST数据包的TTL
就知道中间是被动过手脚的了——两次走的路由跳数都不一样。。。

又被屏蔽了，无语啊。。。只能继续反向SSL代理，哈
最近迷上了openvpn，也不错，BBC什么都能上。。。