继My Opera后BlogSpot也被封了

刚刚在Google Talk上由徐杰告知的，估计和昨天被封的My Opera脱不了干系。和My Opera一样，BlogSpot上托管的Blog普遍都是些宣扬民主政治的人士，而且这两个BSP都是不受国内相关法令所限制的，因此在言论封锁日益增强的今日这一情况并不难预见，只是BlogSpot这次被封的间隔太短了，居然只有一个月不到。按照前两次被封的历史规律来看这次也得经过3次解封才能获得一段较长时间的解封期。

各位仍然坚持使用BlogSpot托管Blog的用户相信也已经有了这种心理准备了，引用无间道里曾志伟的一句话就是“出来行，迟早要还嘎”。根据前两次的封锁时间来看大概会持续一个月左右，临时的应对方案和上次一样，我就不详细写了。我推荐使用以下这种临时应对方案。

编辑WINDOWS\system32\drivers\etc\hosts 文件，加入72.14.207.190 xxx.blogspot.com ，其中xxx是你要访问的Blog在BlogSpot上的二级域名。比如IwfWcf's Blog的格式就是72.14.207.190 iwfwcf.blogspot.com。这里提供一份汇集了500多个BlogSpot上托管的Blog的host列表。

BlogSpot第三次解封

这是本次BlogSpot封锁的第三次解封了，从目前的情况来看和上一次封锁的情况惊人的相似，因此我在BlogSpot再次解封一文中表示根据历史规律来看这次解封将会持续较长的一段时间，各位和我一样仍在坚持使用BlogSpot托管的用户可以以一个较为平和的心态开始一段较长时间的稳定Blogging了。

尽管前两次解封我一直希望不符合历史规律，但这次我只能希望不要打破历史规律了......如果不幸再次被我言中打破了历史规律，请参考此文中的方法访问用BlogSpot托管的Blog。

PS：pkblogs.com和inblogs.net反反复复好几次恢复现在又无法访问了，估计是来自中国的流量过大导致站长被迫将网站下线。

BlogSpot再次解封（Update：4月5日再次被封）

我暂时无法确定这是不是GFW在愚人节给我们开的玩笑（不过为何在愚人节后一天开呢？难道是GFW的工作人员的时差问题？）。不过我建议大家不要报太大希望，有了不久前的第一次解封的经验教训以及历史规律来看这应该不会是最终解封，这可能只是进入第二封锁阶段的前兆罢了......不过值得庆幸的是这一次和上次不同的是，www2.blogger.com没有被封，也许是个好兆头。

总之，大家尽情享受这可能极为短暂的快乐时光吧......当然，我很希望这次不符合历史规律，给我们带来一个较为长久的平和Blogging状态。如果真的被我不幸言中，那你可以参照此文的方法访问BlogSpot。

Update：果然是GFW给我们开的愚人节玩笑，而且也应验了历史的规律，不过这样也好，大家可以确定下一次解封可以持续较长的一段时间了。不过郁闷的是pkblogs.com不知道怎么了，好像被人连锅端掉了，现在主页都被删除了。所以我将BlogSpot被封（文中含封锁分析及临时解决方案）一文中的pkblos.com部分换成了inblogs.net（之前之所以不推荐使用是因为inblogs.net的页面默认包含广告）。

BlogSpot被封（文中含封锁分析及临时解决方案）

真的被GG不幸言中，BlogSpot今天再次被封了。我介绍一些临时解决方案供各位将Blog托管在BlogSpot上的Blogger以及这些Blog的读者参考。主要的方法和上次我介绍过的基本相同，只是这次更加具体一些。

首先说一下这次GFW（99%是这种可能）封锁的方法，和上次一样，将BlogSpot服务器的IP封了，只不过上次封的IP是72.14.219.191而这次封的IP是72.14.207.191。Blogger(blogger.com)和上次一样，在第一封锁阶段暂时没有被封（不知道历史是否会重演，在第二封锁阶段将被封）。

目前有3种临时解决方案：

1.这种是最彻底的解决方案但也是普及难度最大的解决方案，适合托管在BlogSpot上的Blog的读者以及Blogger使用。

编辑WINDOWS\system32\drivers\etc\hosts 文件，然后加入72.14.207.190 xxx.blogspot.com，其中xxx是你要访问的Blog在BlogSpot上的二级域名。比如IwfWcf's Blog的格式就是72.14.207.190 iwfwcf.blogspot.com。这里提供一份汇集了500多个BlogSpot上托管的Blog的host列表。

2.通过Tor/PHPProxy等代理服务以及寻找可用的外国代理服务器来访问。推荐一个速度较快的PHPProxy服务FlyProxy.com。这里介绍一个有趣的应用，利用Google的翻译服务作为在线代理来访问用BlogSpot托管的Blog，具体方法是通过类似http://translate.google.com/translate?u=http%3A%2F%2Fiwfwcf.blogspot.com&langpair=zh-CN%7Czh-CN&hl=zh-CN&newwindow=1&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools这样的URL来访问。将其中的"iwfwcf.blogspot.com"替换你要访问的BlogSpot二级域名即可。如果要访问的是英文Blog则将"zh-CN"替换为"en"即可。只是有个缺陷是不能将页面上的链接也自动转换为这种形式，必需用目标网页的URL替换"http%3A%2F%2Fiwfwcf.blogspot.com"。

3.通过pkblogs.com来访问。具体方法是你要访问的Blog的BlogSpot二级域名是xxx.blogspot.com则你通过pkblogs.com来访问的地址就是http://www.pkblogs.com/xxx（例如IwfWcf's
Blog用pkblog.com来访问的地址就是http://www.pkblogs.com/IwfWcf）。
pkblogs.com是一个供印度、巴基斯坦、伊朗、中国等封锁了BlogSpot托管的Blog的国家的用户用来访问这些Blog的服务。优点是操作简单，缺点是速度较慢以及部分Hack无法正常显示（如Blogger内置的反向链接、我添加的相关文章Hack以及许多Ajax服务）。

4.这个方法的原理是将所有BlogSpot的二级域名都DNS重定向到了72.14.219.190这个IP。

由Dancer In The Dark提供的方法：

打开Notepad（或者其他的编辑器），输入如下内容：

function FindProxyForURL(url,host){
if(dnsDomainIs(host, ".blogspot.com")){
return "PROXY 72.14.219.190:80";
}
}

另存为proxy.pac保存到C盘的根目录下，然后分别对Firefox和IE进行设置：

Firefox： 打开Firefox，依次点击工具->选项-> 高级->网络->设置，选中自动代理配置url，在下面填写：

file:///C:/proxy.pac

点击重新载入 ，然后一路确定即可。

IE：打开IE，依次点击工具->Internet选项->连接->局域网设置，选中使用自动配置脚本，在下面填写：

file://C:\proxy.pac（注意，IE的路径和Firefox的路径不同）

点击确定即可（via GG）。

请所有IwfWcf's Blog的读者订阅我用FeedBurner烧制的Feed，我已将源Feed地址改为了http://www.pkblogs.com/IwfWcf/feeds/posts/default，推荐各位有用FeedBurner等Feed烧制服务的使用BlogSpot托管Blog的Blogger也将源Feed地址改为http://www.pkblogs.com/xxx/feeds/posts/default，其中xxx如上文一样，是指你的Blog的BlogSpot二级域名。这样更改后读者点击你的Feed
Item将直接打开在pkblogs.com上的镜像页面。评论等功能由于是使用Blogger的服务器所以暂时未受影响。

目前只能期望这是像上次Google Page Creator临时被封那样，只是因为临时更换了一组GFW服务器，而这组GFW服务器是封锁了BlogSpot的那组服务器，尽快换回没封BlogSpot的那组服务器。

不过似乎更加符合实际的期望是Google 中国尽快与中国政府完成交涉，解封BlogSpot。Google在进入中国1年后都还未能解决最基本的使用问题，我想在这种状态下再铁杆的Google Fans都无法对Google 中国抱有多大期望了。

Google Page Creator恢复访问（中国）

相信大家看到标题都应该知道是怎么回事了吧？没错，GPC在中国全面解封了，原因好像是15号修好了某条光缆，所以GFW服务器也切换回原来的服务器了……而原来的服务器google pages是没有被封锁的（via GG）。

但通过这次地震导致的GPC被封事件我可以确定GFW对于全国各地或各地的ISP用的是不同的服务器，因为在我的调查中某些地区的电信可以缓慢访问GPC，几乎所有联通用户都可以用正常速度访问GPC。也算是一个意外收获，这也解答了我以前某些RP极好地碰到Google快照解封把这个消息发到TLF上但大部分人的测试结果都是GFW依旧，结果第二天我也不能用了。

这确实是一个振奋人心的好消息，但鉴于目前已经找到一个稳定和快速的国内的空间，暂时不需要用到GPC了（当然，更主要是因为害怕GFW不时的发疯）。

Blogger 自定义域服务被封

昨晚访问色彩斑斓（注：目前已取消自定义域名绑定）的时候发现无法访问，但其他使用BlogSpot托管的Blog都很正常，觉得很奇怪，今天看了月光博客才知道原因，原来又是我们伟大的共产党“为人民服务”。唉，正如咖啡鱼所说，“不会心痛了，习以为常”。早就预料到了这个结果，只是没想到会来的这么快。

为了使结果更具说服力，我们来进行技术上的分析。

Trace 64.233.179.121这个ip（ghs.google.com），得到如下结果
可以看到，访问到202.97.35.49这个IP后就无法继续访问了。

202.97.35.49这个IP又是何方神圣呢？通过查询得知是“中国电信骨干路由器”，这下明白了吧（via William）。

为了进一步确认，我用韩国代理访问，一切正常。

身在中国，我们还是要有一点基本的觉悟啊，自由不是那么容易获得的。还是老老实实地继续用BlogSpot托管，每天祈祷GFW不要发疯。

Google说，Don't be evil。这，比登天还难(via keso)。

醒过来了？Blogger（beta、blogspot）已可正常访问

blogspot及beta.blogger.com在上个月25日左右结实地撞了一下墙，晕了近一个月。刚才"枯藤昏鸦"（感谢！）在邮件里提醒我，它们已经醒过来了。大家可以试一下：

　　beta.blogger.com

　　googleblog.blogspot.com

　　大赦天下？走着看。

PS：这已经是被封后第三次解封了，希望这次不是临时故障。

出处：GSeeker

时辰到了？这次是Google Page Creator

　　今天收到18封来自全国各地的读者邮件，询问的都是同一件事：Google Page Creator怎么无法访问了？很抱歉，目前我还没有得到确定的消息。不过作为普通的用户，我们可以用简单的方法来做个试验。


　　首先我们ping它一下：



　　Ooooooops!

　　接下来我们TP它一下：



　　初步的结论是Google Page Creator遭遇了中国网络特有的百慕大三角效应，或者说在前进的时候不小心撞了著名的墙而暂时昏了过去。

PS：看来我很有必要作个专题来介绍那些被GFW的Google Services了，实在不想看到那么多好的服务都不为人所知。

出处：GSeeker

中文维基百科解封

　　从昨天起（2006年11月09日），中文维基百科似乎已经完全解封了，无论电信还是网通的用户都可以访问正常。

　　自从去年10月中文维基百科被封起，到现在已经整整一年多了，实际上，从10月份就有报道说，中国部分地区可以访问中文维基百科了，但是我用自己的线路（电信ADSL）尝试了一下，还是无法连接上中文维基百科，搜索其域名连接会被重置，说明那时其域名还是在黑名单中。

　　但是我估计中国北部的小部分地区已经可以正常访问维基百科了，因为我查看百度搜索引擎的网页快照，10月份搜索“维基百科”，已经可以发现中文维基百科的域名和百度快照了，说明百度的Spider已经可以连接中文维基百科了。

　　而从昨天晚上起，各处都传来可以正常访问中文维基百科的消息，我自己也可以正常访问，为了验证这不是临时解封，我还是耐心等待了一天的时间，发现至今为止中文维基百科都是可以正常访问的，看来这次可能是真正解封了。

　　我去年就曾经说过，封杀中文维基百科这么优秀的而庞大的知识宝库是一种很不负责任的做法，“知识改变命运”，维基百科是一个名副其实的百科全书，封杀这样的网站实在令人无法理解。然而，这次解封是不是临时的解封呢？会不会过段时间再封掉这个网站呢？这还是难以判断的。BlogSpot就是解封2个月后又被重新封锁，中文维基百科会不会步BlogSpot的后尘呢？目前离维基被封正好一年时间，会不会当时封的时候就设定了时间，一年后自动解封呢？

　　另外一个值得注意的网站是维客网，这个网站曾经在中文维基百科被封的当天正式运营，并且大量复制维基百科的内容而不注明出处，因而引起很大争议，后来由于维客中国的服务器被黑客攻破而被删除了全部数据，维客中国也不得不在仅仅生存了十天的情况下黯然关闭。新的维客于今年5月份悄然上线，不过维客网依旧使用的是中文维基百科的数据库。新版的维客网增加了类似百度贴吧的维客帖吧，其界面几乎和百度贴吧一模一样。经过一些使用发现，对于中文用户来说，贴吧的形式比维基的“讨论”形式更贴近普通用户一些。

　　目前，中文维基百科已经可以正常访问了，不过，如果你访问的时候出现“page not found”等提示，请修改一下hosts文件，将原先增加的一些IP删除即可正常。当然，这次中文维基百科是否是永久的解封，还需要再多观察一段时间。

出处：月光博客

解决无法访问Blogger beta

72.14.219.190真是个神奇的IP啊，不仅能用它访问BlogSpot，今天看了Yee's Blog才知道可以用来访问Blogger beta，谁知道这个IP的具体资料麻烦告诉我。hoho，写文章再也不用忍受Torpark的痛苦了。

具体方法：编辑WINDOWS\system32\drivers\etc\hosts 文件，然后加入72.14.219.190 beta.blogger.com

BlogSpot再次解封？

今天早上起来发现BlogSpot又可以正常访问了，请继续关注我的后续报道。

Update:果然和上次一样，只是暂时故障罢了。不过这次GFW做得够绝，把beta.blogger.com都给封了（我现在在用Torpark来上的），www.blogger.com目前还可以正常访问。

独家：BlogSpot已经恢复正常

目前尚不清楚是GFW解封还是BlogSpot解决了自身的问题

Update:今天早上起来又有问题了，看来昨晚只是GFW的一时错误解封

BlogSpot疑似再次被封

我很愤怒，我们就这么被GFW玩弄于鼓掌之中，我们的权力就这么被肆无忌惮地侵犯但我们却没有一点办法抵抗。实在想不明白原因，难道是为了推广博客实名制？但为什么那么多外国的BSP提供商只是封Google的Blogger呢？想起Google的众多功能都被GFW封了，不禁怀疑这是商业上的操作。

从昨天晚上开始，不少人反应Google的博客服务BlogSpot再次无法访问。

我自己验证了一下，我的确也无法访问，根据我的检测，无法访问的原因是72.14.219.191的IP无法访问，具体原因不能确认，可能是BlogSpot更改IP地址，也可能是这个IP本身就被GFWed了。

最后，对于BlogSpot的博客，通过修改hosts文件还是可以间接访问的，具体方法是：编辑WINDOWS\system32\drivers\etc\hosts 文件，然后加入72.14.219.190 xxx.blogspot.com ，其中xxx是你的用户名，即可访问到你自己的BlogSpot了。

或者通过http://www.pkblogs.com/username（例如本Blog就是http://www.pkblogs.com/iwfwcf）

部分内容引用自月光博客的《BlogSpot疑似再次被封》

英文维基百科已经解封

但Wikipedia中文目前仍然无效.

访问：http://www.wikipedia.org/

知识文章:找出GFW在Internet中的位置

看到这篇文章的标题,可能有人要问GFW到底是什么?虽然GFW在一部分人的眼睛里并不陌生了,但相对与大部分人来说还是非常陌生的,引用我在Google里找到的一段话:

The Great Fire Wall of China的简写,意指“中国网络防火墙”(字面意为“中国防火长城”),这是对“国家公共网络监控系统”的俗称,国内简称“防火长城”.

GFW是“金盾工程”的一个子功能.“金盾工程”是以公安信息网络为先导,以各项公安工作信息化为主要内容,建立统一指挥、快速反应、协同作战机制,在全国范围内开展公安信息化的工程,主要包括建设公安综合业务通信网、公安综合信息系统、全国公安指挥调度系统以及全国公共网络监控中心等.该项目2003年开始生效.一般所说的GFW,主要指公共网络监控系统,尤其是指对境外涉及敏感内容的网站、IP地址、关键词、网址等的过滤.

GFW的效果通常为,国内网络用户无法访问某些国外网站或者网页;或者国外网络用户无法访问国内的某些网站或者网页.这里的无法访问,有永久性的无法访问(比如色情网站),也有因为URL中含有敏感关键词或者网页上有敏感内容而暂时性的无法访问.

国家防火墙并非中国的专利.实际上,美国也有国家网络监控系统,对进出美国的每一封电子邮件进行内容扫描.不同的是,中国的国家防火墙会直接切断敏感连接,而美国的国家防火墙(考虑更名)则只是做数据监控记录.伊朗、巴基斯坦、乌兹别克斯坦、北非共和国、叙利亚、缅甸、马尔代夫、古巴、北韩、南韩、沙特阿拉伯、阿拉伯联合酋长国、也门使用与金盾类似的国家防火墙.

看了以上这段话相信大家都比较清楚GFW到底是什么了,但是一直有人说有GFW,但具体的位置在哪里呢?我们如何查出GFW到底在哪里呢?好象并没多少文章有介绍,所以我这里针对这点特别写了这篇文章.

GFW这个东西很早我就已经知道,并且为防止GFW的“骚扰”我已经想过了很多办法来避免了,但由于收到外界机制的影响,仍然不可能完全避过GFW,而最近我所在的公司发到国外的邮件总是受阻,严重影响了公司的正常业务,所以我必须给他们一个非常圆满的答复,才有了找到GFW的位置的想法.

最近我们公司总是有人反应发到日本的邮件会被退回来,我查看了一下退信内容,发现主要有如下内容:

:
xxx.xxx.xxx.xxx does not like recipient.
Remote host said: 551 User not local; please try
Giving up on xxx.xxx.xxx.xxx.
或者:
:
xxx.xxx.xxx.xxx does not like recipient.
Remote host said: 500 error
Giving up on xxx.xxx.xxx.xxx.

而在邮件服务器的日志上发现如下内容:

Sep 26 14:46:23 livedoor qmail: 1159253183.972578 delivery 118310: failure: xxx.xxx.xxx.xxx_does_not_like_recipient./Remote_host_said:_500_error/Giving_up_on_xxx.xxx.xxx.xxx./
由于总报这样的问题,所以我在公司的网关服务器上安装上snort这个入侵检测软件,当然我并没发挥入侵检测的功能,因为我只想要里面的sniff功能探测数据包,然后等待这种现象的再次来到.当邮件日志里再次出现上面的日志内容的时候,我进入网关服务器查找所有相关这个IP的记录,并且根据时间找到了:

-rw------- 1 root wheel 6941 Sep 26 14:44 TCP:60661-25

现在就请大家跟着我来分析这个文件:
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.643691 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x4E
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:32988 IpLen:20 DgmLen:64 DF
******S* Seq: 0x2E68FF24 Ack: 0x0 Win: 0xFFFF TcpLen: 44
TCP Options (8) => MSS: 1460 NOP WS: 1 NOP NOP TS: 121485349 0
TCP Options => SackOK EOL
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

这是我们公司的邮件服务器10.4.1.4向对方发送SYN的请求包,TTL为127,虽然我们的邮件服务器是FreeBSD,但我还是把TTL修改为128了,而邮件服务器和网关服务器之间有一个路由,所以TTL会减1,就成为了127.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

09/26-14:44:52.744474 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x4A
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:0 IpLen:20 DgmLen:60 DF
***A**S* Seq: 0x1527A9A1 Ack: 0x2E68FF25 Win: 0x16A0 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 9713757 121485349 NOP
TCP Options => WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

这里为对方服务器向我们公司的服务器回复SYN+ACK包.可以看到TTL为49,由于对方也是FreeBSD系统,而FreeBSD的默认TTL值为 64,这样我们可以计算出我们的服务器到对方的服务器经过的路由数,64减49等于15,所以网关服务器到对方服务器经过了15个路由,使用 traceroute命令追踪了一下结果,如下:

gw2# traceroute -n 203.131.198.80
traceroute to 203.131.198.80 (203.131.198.80), 64 hops max, 40 byte packets
1 210.83.214.161 0.722 ms 0.699 ms 0.612 ms
2 210.83.193.49 0.595 ms 0.486 ms 0.615 ms
3 210.52.131.6 16.979 ms 16.978 ms 16.975 ms
4 210.52.130.10 46.711 ms 45.836 ms 45.838 ms
5 210.52.132.230 50.208 ms 49.957 ms 50.085 ms
6 210.53.126.2 50.083 ms 49.955 ms 50.334 ms
7 202.147.16.125 50.583 ms 50.207 ms 50.587 ms
8 202.147.16.205 51.204 ms 50.081 ms 50.209 ms
9 202.147.16.214 103.055 ms 103.050 ms 103.179 ms
10 202.147.0.206 99.803 ms 99.677 ms 99.806 ms
11 203.192.131.250 103.802 ms 103.549 ms 103.430 ms
12 203.174.64.13 99.804 ms 100.053 ms 100.681 ms
13 203.174.64.146 100.056 ms 100.799 ms 102.075 ms
14 203.174.64.214 101.012 ms 99.676 ms 100.179 ms
15 203.131.198.80 100.805 ms 99.926 ms 99.929 ms
gw2#

这里可以很清楚的看到为15跳,充分证明了TTL没有任何问题,而对方的服务器也没有使用防火墙以及NAT来映射25号端口.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

09/26-14:44:52.744633 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x42
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33011 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x2E68FF25 Ack: 0x1527A9A2 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485450 9713757
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
这里是我们公司返回一个ACK包,这样整个TCP连接的握手成功,接下来就要开始传输数据了.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.845542 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x93
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:37317 IpLen:20 DgmLen:133 DF
***AP*** Seq: 0x1527A9A2 Ack: 0x2E68FF25 Win: 0x16A0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 9713767 121485450
32 32 30 20 35 61 2D 70 30 37 2D 62 33 2E 64 61 220 5a-p07-b3.da
74 61 2D 68 6F 74 65 6C 2E 6E 65 74 20 46 2D 53 ta-hotel.net F-S
65 63 75 72 65 2F 76 69 72 75 73 67 77 5F 73 6D ecure/virusgw_sm
74 70 2F 32 32 30 2F 35 61 2D 70 30 37 2D 62 33 tp/220/5a-p07-b3
2E 64 61 74 61 2D 68 6F 74 65 6C 2E 6E 65 74 0D .data-hotel.net.
0A .
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
首先是对方服务器给了我们一个220的服务器信息.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.845826 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x54
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33066 IpLen:20 DgmLen:70 DF
***AP*** Seq: 0x2E68FF25 Ack: 0x1527A9F3 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485551 9713767
48 45 4C 4F 20 6C 69 76 65 64 6F 6F 72 2E 63 6E HELO livedoor.cn
0D 0A ..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
我们的服务器给对方发送了一个SMTP协议所需要的HELO信息.由于内容太多中间SMTP协议的握手我就不再详细介绍了,所以我这里直接跳到出问题的地方.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.049710 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x6B
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33110 IpLen:20 DgmLen:93 DF
***AP*** Seq: 0x2E68FF56 Ack: 0x1527AA19 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485755 9713787
52 43 50 54 20 54 4F 3A 3C 6A 69 6D 67 72 65 65 RCPT TO:6E 40 6E 65 70 74 75 6E 65 2E 6C 69 76 65 64 6F x_at_neptune.livedo
6F 72 2E 63 6F 6D 3E 0D 0A or.com>..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
在这里,当我们的服务器发送RCPT To的信息到对方服务器以后,按照SMTP协议的原理,对方在有这个用户的情况下应该返回250 ok这个信息,但是这个时候问题出现了,我们的服务器马上收到一个如下的信息:
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.103763 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x41
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:57 TOS:0x0 ID:64 IpLen:20 DgmLen:51
***AP*** Seq: 0x1527AA19 Ack: 0x2E68FF7F Win: 0x0 TcpLen: 20
35 30 30 20 65 72 72 6F 72 0D 0A 500 error..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
500 error的信息,再看看TTL的值,57?对端服务器的TTL由49突然变成了57?理论上来说说不过去,再接着看后面的信息:
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.154738 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x4A
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:37321 IpLen:20 DgmLen:60 DF
***AP*** Seq: 0x1527AA19 Ack: 0x2E68FF7F Win: 0x16A0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 9713798 121485755
32 35 30 20 4F 6B 0D 0A 250 Ok..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
这才是真是服务器发送过来的信息,而由于500 error的错误信息比250 Ok的正确信息先到达我们的服务器,所以我们的服务器这个时候就已经认为对方服务器错误,所以按照SMTP协议必须终止邮件的发送,所以这个时候我们的服务器发送:
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.155026 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x48
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33131 IpLen:20 DgmLen:58 DF
***AP**F Seq: 0x2E68FF7F Ack: 0x1527AA24 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485860 9713787
51 55 49 54 0D 0A QUIT..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
QUIT退出……,就这样一封正常的邮件被活生生的截断了.
现在我们来开始看那个TTL为57的信息,根据我的经验对方的TTL默认值应该是64,所以64减57等于7,也就是说这个阻断我们信息的信号来自和第7个路由同网断或者就是第7个路由.现在再看看我最上面的traceroute的结果:
gw2# traceroute -n 203.131.198.80
traceroute to 203.131.198.80 (203.131.198.80), 64 hops max, 40 byte packets
1 210.83.214.161 0.722 ms 0.699 ms 0.612 ms
2 210.83.193.49 0.595 ms 0.486 ms 0.615 ms
3 210.52.131.6 16.979 ms 16.978 ms 16.975 ms
4 210.52.130.10 46.711 ms 45.836 ms 45.838 ms
5 210.52.132.230 50.208 ms 49.957 ms 50.085 ms
6 210.53.126.2 50.083 ms 49.955 ms 50.334 ms
7 202.147.16.125 50.583 ms 50.207 ms 50.587 ms <——可能发送错误信息的IP
8 202.147.16.205 51.204 ms 50.081 ms 50.209 ms
9 202.147.16.214 103.055 ms 103.050 ms 103.179 ms
10 202.147.0.206 99.803 ms 99.677 ms 99.806 ms
11 203.192.131.250 103.802 ms 103.549 ms 103.430 ms
12 203.174.64.13 99.804 ms 100.053 ms 100.681 ms
13 203.174.64.146 100.056 ms 100.799 ms 102.075 ms
14 203.174.64.214 101.012 ms 99.676 ms 100.179 ms
15 203.131.198.80 100.805 ms 99.926 ms 99.929 ms <——真实服务器的IP
gw2#
使用 http://www.linkwan.com/gb/broadmeter/VisitorInfo/QureyIP.asp 的IP地址查询查到 202.147.16.125 属于澳大利亚,难道澳大利亚在监视我们的网络,想想虽然有这个可能性,但应该不会明显到这个程度.所以我想应该不是这个IP地址,然后我查了查第6跳的 IP地址 210.53.126.2 ,通过查询显示为“中国网通”很明显6和7之间就是中国网通的出口路由,那么GFW就顺理成章安装在 210.53.126.2 这个IP之后.

从上面的分析我们就可以完全的肯定阻断公司邮件正常来往的就是 210.53.126.2 之后的GFW发送的假信息.还好公司的邮件全都是正常的,GFW并不会完全封死,所以过段时间以后会自动恢复.由于发送的邮件非常多,也不一定是同一个服务器,所以不能用VPN来解决,不太现实.当碰到这样的问题的时候我们目前只怕唯一能做的就是等待,直到 GFW恢复我们的网络.

作者:刘宏光
邮件:iceblood_at_163.com
网址:http://www.nettf.net
日期:2006-9-26

终于可以再次访问wiki了

和不知道怎样访问的人share一下，不需要用代理（我用了N个也访问不了）

https://secure.wikimedia.org/wikipedia/zh/wiki/