标签 ctc 下的文章

2009 年 2 月 24 日是一个值得纪念的日子,因为众所周知的原因,我朝在当日完成了对全球最大局域网的政治改造。轰轰烈烈,必载史册,其性质堪比“文字狱”和“焚书坑儒”,有过之而无不及。本人三生有幸,亲历该行动整治杭州萧山通惠北路双线机房的全过程。

我在前一篇文章中概述了服务器的电信线路失效,临时切换到网通的情况。事实上那个时候整个机房的电信线路已被省电信中断(具体原因可参考该机房某客户公司的通知),勉强依靠网通线路坚持。

杭州萧山通惠北路双线机房原先是萧山网通的数据机房,后主要由四川蓝月远景数据杨梅科技几家公司合作承包经营,接入了电信线路做成双线机房。22 日下午,我接到我的服务提供商发来的通知:

最近机房被严打了,省电信在整顿各地的 IDC 机房,我们机房也是重点检查之一,但是每个机房肯定有没有备案的和有时候有些非法信息之类的,直接电信线路给断了,你先用网通的用起来,周一我已经在联系做迁移了。 这位朋友的经历与我有几分相似。无奈之下只能临时修改域名解析,双线变成单线。这个过程有点痛苦,还有一个小插曲,就是发现 apache 突然宕掉了。看了日志,发现:

[alert] (EAI 8)hostname nor servname provided, or not known:
mod_unique_id: unable to find IPv4 address of "xx.xx.xx"
Configuration Failed
折腾了很久才发现是因为电信线路傻掉的原因,服务器不能连接到原先设定的杭州电信 DNS 上了,修改 /etc/resolv.conf 为网通 DNS,然后注释 httpd.conf 中监听网通 IP 的那一行:

# Listen: Allows you to bind Apache to specific IP addresses and/or
# Change this to Listen on specific IP addresses as shown below to 
#Listen xx.xx.xx.xx:80
Listen yy.yy.yy.yy:80
重启 apache,问题解决。

24 日下午又接到我的服务提供商发来的新 IP 地址,说已联系好新机房,准备下午 18 点开始做迁移。于是我要求服务提供商在下架服务器之前打电话过来,以便我预先修改服务器 IP 设置,并操作服务器关机。

24 日下午 18 点 15 分许,服务提供商来电话通知搬迁,服务器第一次执行了关机的操作。我和易先生一直关注服务提供商的最新进展,在长途加漫游的情况下一直保持与服务提供商的电话联系。直到 24 日晚、25 日凌晨 2 点左右,服务器依然没有通网。

25 日整个上午,服务提供商的电话无人接听。中午时分,服务提供商的公司电话终于接通,一个工作人员表示对目前的进展不甚清楚,建议我们继续等待。

25 日下午,服务器终于可以访问了,但这时发生了一件神奇的事情。说实话,当时看到那个情况,我完全不敢相信自己的眼睛——访问服务器上的网站(客户端是网通接入),居然是这样的:

初步分析这是一个很神奇的公司(西安瑞友信息技术资讯有限公司)开发的很神奇的软件(我党指定的托管服务器必装软件),我们可以从下面两段信息中看出这家公司悠久的历史:

Domain Name: realor.com.cn
ROID: 20080227s10011s87509169-cn
Domain Status: ok
Registrant Organization: 西安瑞友信息技术资讯有限公司
Registrant Name: 方浩
Administrative Email: [email protected]
Sponsoring Registrar: 北京新网数码信息技术有限公司
Name Server:ns1.supercdn.com
Name Server:ns2.supercdn.com
Registration Date: 2008-02-27 12:18
Expiration Date: 2010-02-27 12:18
以及:

Domain Name: SUPERCDN.COM
Registrar: XIN NET TECHNOLOGY CORPORATION
Whois Server: whois.paycenter.com.cn
Referral URL: http://www.xinnet.com
Name Server: NS1.SUPERCDN.COM
Name Server: NS2.SUPERCDN.COM
Status: ok
Updated Date: 15-dec-2008
Creation Date: 03-aug-2008
Expiration Date: 03-aug-2012
我当时确实有点着急,因为我在随意点击间发现了这个软件的 web 服务端信息是 apache/win32。难道天朝已经免费地将我的 FreeBSD 换成 Windows 了?然后 telnet 了一下 3389 端口,通了,心里马上凉了半截。马上联系服务提供商,可电话一直处于忙线或者无人接听状态。很快我在 GoogleTalk 上找到了 lucky,狠狠地抱怨了一番。lucky 似乎也比较激动,表示会关注此事。

大约在 25 日晚餐后一段时间,终于和服务提供商取得了联系。对方表示有可能因为服务器上的标签贴错而导致的机器与 IP 地址不对应情况,并承诺晚上会解决这个问题。

25 日晚 23 点,我意外地发现服务器的电信 IP 通了,而且可以正确访问到服务器上的网站。那么下午的情况,的确不是服务器操作系统被重装,而是 IP 分配错误。随后直接与机房取得了联系,不知机房的工作人员是忙不过来还是不乐意帮忙,每次联系,不是使用上级策略推卸责任就是含糊其辞、拖延时间。一会说可能是我们服务器设置错误,一会说这次是上面的“相关部门”统一行动,他们也没有办法,只能配合。典型的拿着鸡毛当令箭,就是不承认网通 IP 的问题是自己机房设置造成的。

26 日凌晨 0 点左右,又与机房取得了联系。这次机房的工作人员干脆表示他本人没有调整交换机设置的权限,要明天(26 日)上午 9 点相关人员上班后解决。这次真把易先生惹火了,在电话中斥责对方的工作态度存在问题、机房的管理相当混乱。

可能昨晚易先生的发飙起了作用,也可能上帝开了眼,也可能机房的人良心发现,也可能其他客户的问题全部解决、终于轮到我们了——不管怎么样,总之——26 日中午 12 点多,电信、网通两个 IP 终于全部正常。整个折腾活动历经整整 42 个小时,当代 IDC 机房工作效率可见一斑。

其实,对于服务提供商或者机房而言,我并没有太多怨言。因为我非常清楚,服务提供商也好、机房本身也好,可能都是无辜的受害者。这次问题本身就因某些存在低俗内容的服务器而起,由于时间短、内容多,就像月经一样突然来了一个很大的量,多多少少让人有点措手不及。除了无奈,基本没有其他选择。“相关部门”又在这次行动中发挥了不可磨灭的作用和强大的领导能力,取得了卓越的成就。党国上下,欢欣鼓舞。

事情已经过去了几天。由于公众视线被成功转移,并没有太多的人继续关注这个问题,我也不知道这个时候那些砖家、叫兽是怎么想的。如果有机会将这个问题上升到社会法学角度,我想问他们,政治化改造真的需要以突破和废除层层社会秩序为代价吗?

大约在两个月前,易先生和我一起搞了一台服务器,托管在杭州萧山双线机房。除了易先生自己的两个网站:blogshang.comneilyi.cn 之外,还陆续为 gracecode.comyiyitoo.combbitt.comebshoe.comtypecho.net 等网站提供了空间支持。

前几天 lucky 突然告诉我,说服务器的上行好像有问题。具体表现为 POST 数据慢,FTP 上传几乎不能进行。但是我看了一下却并未发现这样的情况,随后让运营商检查也没有找到问题所在,因为他们上行到服务器也很正常。紧接着,一一、badbuild、ppeng 三位同学相继反映了与 lucky 类似的情况,讨伐之声一浪高过一浪。

经过与机房技术人员为期将近一周的亲密接触和技术测试,我们重现了问题并初步认定此问题与服务器设置或机房线路带宽无关。经过杭州以外朋友的友情测试,确定省外访问无论上下行都很正常。因此,问题极有可能出在上述几位同学所使用的网络上。他们都有一个共同特征,即杭州市区电信线路。

我们来看一下从 lucky 同学家里、公司,还有我这边的网络所做的路由跟踪结果。

这是我所在公司网络到服务器:

Tracing route to 122.224.147.37 over a maximum of 30 hops:
1     *        *        *     Request timed out.
2     *        *        *     Request timed out.
3     2 ms     2 ms     3 ms  220.191.130.133
4     3 ms     2 ms     3 ms  61.130.125.153
5     3 ms     2 ms     4 ms  61.130.125.157
6     4 ms     4 ms     4 ms  61.130.125.114
7     4 ms     3 ms     4 ms  220.191.132.18
8   102 ms   102 ms   102 ms  202.101.163.238
9     5 ms     6 ms     5 ms  122.224.147.37
Trace complete.
这是从 lucky 家里(杭州电信家庭 ADSL)到服务器:

Tracing route to 122.224.147.37 over a maximum of 30 hops:
1 * * * Request timed out.
2 17 ms 20 ms 18 ms 220.191.157.213
3 19 ms 19 ms 18 ms 220.191.156.93
4 19 ms 19 ms 20 ms 61.130.125.134
5 19 ms 31 ms 19 ms 61.130.125.114
6 19 ms 20 ms 35 ms 220.191.132.18
7 121 ms 122 ms 121 ms 202.101.163.238
8 22 ms 21 ms 21 ms 122.224.147.37
Trace complete.
这是从 lucky 公司(阿里巴巴)到服务器:

Tracing route to 122.224.147.37 over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 10.1.28.2
2 <1 ms <1 ms <1 ms 10.0.99.113
3 1 ms <1 ms <1 ms 10.0.99.170
4 <1 ms <1 ms <1 ms 10.0.3.241
5 1 ms 1 ms 1 ms 121.0.31.124
6 1 ms 1 ms 1 ms 121.0.31.5
7 2 ms 1 ms 1 ms 121.0.31.73
8 1 ms 1 ms 1 ms 61.130.125.114
9 2 ms 2 ms 2 ms 220.191.132.18
10 1 ms 1 ms 2 ms 202.101.163.238
11 3 ms 2 ms 2 ms 122.224.147.37
Trace complete.
然后,我们各自又跟踪了一下到新浪网的路由。

我的:

Tracing route to jupiter.sina.com.cn [61.172.201.194]over a maximum of 30 hops:
1     *        *        *     Request timed out.
2     *        *        *     Request timed out.
3     2 ms     2 ms     3 ms  220.191.130.129
4     2 ms     2 ms     3 ms  61.130.125.145
5     2 ms     2 ms     3 ms  220.191.158.233
6    19 ms     6 ms     5 ms  61.152.80.145
7     7 ms     6 ms     6 ms  61.152.87.154
8     7 ms     7 ms     6 ms  222.72.243.250
9     6 ms     6 ms     6 ms  61.172.201.194
Trace complete.
lucky 的:

Tracing route to jupiter.sina.com.cn [61.172.201.194]over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 10.1.28.2
2 <1 ms <1 ms <1 ms 10.0.99.113
3 1 ms <1 ms <1 ms 10.0.99.170
4 1 ms <1 ms <1 ms 10.0.3.241
5 * 1 ms 1 ms 121.0.31.124
6 1 ms 1 ms 1 ms 121.0.31.5
7 2 ms 1 ms 1 ms 121.0.31.73
8 1 ms 2 ms 1 ms 220.191.129.117
9 4 ms 4 ms 4 ms 61.152.80.145
10 5 ms 5 ms 5 ms 61.152.87.106
11 5 ms 5 ms 5 ms 222.72.243.234
12 4 ms 5 ms 4 ms 61.172.201.194
Trace complete.
与此同时,聪明伶俐的 lucky 同学通过使用代理服务器成功地规避了这个问题。于是,一传十、十传百,变成了全国皆知的秘密。上述几位同学因突然终于可以发文而激动万分、兴奋不已,纷纷发文讨伐我的恶劣行径。这是一一同学的,这是 badbuild 同学的。

中午的时候,请教了一位在当地电信从事数据工作的朋友。他一听到我报 IP 地址给他,他就说:你这个 IP 的网段本身就是有问题的。然后他向我解释了这件事情的原委:电信在杭州地区、七县市范围内的大城域网中部署了多个域,萧山、余杭及周边地区在同一个域内,而杭州市区另属几个其他的域。换言之,从杭州市区走路由到萧山的服务器,是需要经过多个域的路由。这次故障刚好出现在上述几位同学所在网络的上级出口上,因此产生了“东边日出西边雨”的神奇现象。

因此,需要彻底解决这个问题,只能等电信调整好市区线路的出口路由。

因为突然不喜欢服务器 IP 所在的网段,下午的时候要求机房把服务器的电信网通两个 IP 全换了。虽说问题没有得以解决,至少心里舒服多了。我一直在想,这些种种神奇的事情,会不会与运动会有关呢?

今天距离运动会只有不到 30 天时间了。在这举世瞩目、普天同庆的时刻即将到来的时期里,我们的生活也变得越来越和谐。最近发现,小巷子里的路边摊没了、夜市暂停了、停车要咪表了、交警城管巡逻得更勤了,这种种一切都在向世人传递着一个信息:不惜一切,办好运动会。

就在我们的生活被这场即将到来的运动会潜移默化地影响并改变的时候,殊不知,我们的互联网(这里也可以称为中国局域网)也被悄然改变着……

这是在今年四月到五月间发现并得到华数官方确认的消息。

说到华数宽带,它是极具有地方特色的玩意,也是地方保护主义的产物。它的官方称呼是“杭州网通”,民间也叫“小网通”,与北方的“大网通”遥相呼应。当年广电集团还没有分家的时候,它诞生了。后来广电分家,数字电视和有限宽频业务被分了出去,独立成立了杭州华数互动电视,“杭州网通”也逐渐被“华数宽带”这样的称呼所取代。

华数宽带依赖有限电视原有的物理网络铺设,其拓扑结构类似一个大型城域网。由于其直接将网线从楼宇交换机接到桌面,使得终端绕过其用户验证机制而直接联网成为可能。在 2003 年间,我证实了这种假设。那时的杭州网通宽带到期后,接入居室内的网线并不会被回收,理论上你还在这个城域网内。我在另一个杭州网通宽带用户的计算机上为网卡绑定两个 IP 地址,使其中一个 IP 地址与我的计算机处于同一网段,然后通过一些代理软件就可以实现网络共享,甚至可以实现两台或多台计算机共享一个宽带帐号,并轮巡拨号。

多年以来,华数宽带的市场占有率虽然不及中国电信,却在杭州地区(我确实不知道杭州以外是否还有)占有一席之地。由于种种特殊的需要,我们公司的网络出口使用两条线路,一条电信,一条华数。其中华数宽带主要用到了它的上行。

今年四月中下旬的时候,我发现外部用户访问华数上行的时候会被重定向到另一个 IP 上面。具体表现为,ping 被重定向到 60.12.14.2 这个IP,而 web 访问会被重定向到 http://60.12.14.2/poseidonlogin/start 这个 URL,从页面信息来看,可以初步判断是一台由华为公司提供的网络设备的 web 网管界面。通过查询 http://whois.domaintools.com/60.12.14.2 得知 60.12.14.2 这个 IP 属于杭州网通。当时我联系了杭州网通,客服称对此并不知情,答应派工单到营业厅,让我等电话。第二天我接到我们当地华数营业厅自称是技术人员的一个电话,我重复描述了一下问题,他非常神秘的笑了一下,对我说:哦,你是说线路上行啊,我们前几天确实接到市公司的通知,已经封禁了所有家庭宽带用户的上行。我问他原因,他说一般用户并不需要上行,他们此举可以节省很多带宽,为用户更好地服务,如果需要开通上行,可以申请企业专线。我无言以对,谢过之后就挂了电话。

时至今日,那个神秘的 URL 已经无法访问了,普通家用宽带的上行依然处于封禁状态,而华数官方更是没有一则通知。