作为深入理解系列最后一篇，有好几个平行的话题在这里一并讨论了。
西厢的弱点和局限
首先泼一盆冷水。
西厢远没有你们想象得那样强大，它有很多弱点和局限：
- 对IP封锁无效。比如加载之后也不能访问twitter.com。
- 对无状态的TCP阻断无效。比如有一段时间的docs.google.com:443。
- 不稳定。不少用户反应使用时有时候仍然会连接被重置。
- 受环境影响大。因为要求网络中间节点都遵守RFC，不少NAT内网用户无法使用，装了防火墙也可能造成无法使用，在虚拟机内开启也可能无法使用。
- 安全性没有改善。用户的通信仍然是原样，明文仍然是明文，被动监听设备依然正常截获用户的通信。
- 受制于GFW的变动。GFW指纹逻辑比较复杂，只能通过硬编码来描述。如果GFW更新工作方式细节，那么匹配模块就需要重写更新才能使用。
- 另外，有ipv6线路的用户访问Youtube不需要使用西厢。
而它的优点是，免费，无中转性能开销。因此，到发布为止，只想到Youtube最大地展示了它的优点而较少受到缺点影响。而产生幻觉，只看到优点看不到缺点是多数人会犯的错误。
西厢是什么不是什么
西厢提出的是一种技术而不是一种资源，因此没有西厢客户端一说，也不存在被封。西厢所做的只是指出了墙上本来存在的裂缝，而且这个裂缝是可以利用的。
之前我们说过：其他一些低成本但有一些缺点的方法也暂时作为折中而继续存在研究价值。私有SSH代理和私有VPN才是当前状况下的最优解决方案，但是由于这两种方法有较高的成本。西厢不会也不能替代私有SSH代理和私有VPN在翻墙中起到的作用。西厢不是对GFW的银弹。GFW是一个复杂的系统，不存在对它的银弹。
0.0.1版的发布是面向开发者的，完全没有考虑用户体验。原开发组没有任何继续开发的计划，没有任何移植的计划。任何继续的开发和移植是所有后来人的功劳。
西厢的开发有多难？有人拿毕设来与之相比，这有点不可思议。事实上，西厢的原理部分一年前就完成了，主要依据就是T. Ptacek的那篇论文，实验结果也很好。而最终的netfilter实现者说他花了一周时间看内核代码netfilter那部分，然后就着现成的代码直接改成现在这个样子了。难吗？为什么西厢压了一年没有发出来？在这一年中，
这样一些系列从零到有的文章，是要展示一种对GFW进行全面理解的学习过程和方法，表达一种对GFW进行逆向工程的趣味。读者不应该仅仅作为一个信息的接收者，而是应该有自己积极的思考。如果读者中有百分之一开始自己思考关于GFW的问题，千分之一开始自己动手研究GFW，如果有万分之一开始将原理付诸实践，那就是很好的结果。如果所有人都只是伸手而没有动力去自行了解GFW，那么就只会让GFW越来越强大，而自己被动挨打被GFW追得到处跑。GFW在背后技术力量的推动下变动不居，不断地被更新、不断地发生变化，对GFW永远正确的认知或者一劳永逸的翻墙方法并不存在，只有与之对抗的方法和学习动力能留存下来。……
西厢的提出就是为了说明，GFW也远没有你们想象得那样强大，而是充满了漏洞。只要你敢于动手，就一定有所收获。请记住，西厢是个tech demo，发布出来不是给你用的，而是给你研究的。如果你认为你的能力不比哈工大、北邮那些筑墙的学生差，那么请你体现你的存在。
GFW如何应对西厢的挑战
不说非常困难，解决西厢揭示的漏洞也不是一件简单的事情。
首先，GFW的规模极为庞大，这给打补丁的难度带来了本质的变化。如果是一个一般小型网络出入口上部署一台主机做的IDS，给TCP栈打补丁还相对容易。而在分布式和并行计算的体系结构下，在几千个计算节点的规模上做任何事情都不容易。
其次，GFW的设计思想从一开始就没有重视完备性。以前已经讨论过了，GFW很多模块的设计给人这样的感觉：得过且过，刚好可以工作。而且这些问题实际上很久都不修复。比如这次西厢展示的这个漏洞，其原因来自GFW的多线程TCP栈还原全连接时，将通信分成两个half_stream处理，从而避免数据共享控制造成的锁开销的做法。往好的方向看，这可以在性能上带来提升，以完备性的损失换来计算的简化也是一种实用主义哲学。往坏的方向看，这就打开了漏洞的大门。这也就意味着，GFW面临这种的情况：修补漏洞，性能大幅下降；完善TCP栈，性能急剧下降。
然后，GFW完全修复漏洞的难度很大。按照Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection一文的结论，如果NIDS的TCP栈与两端的TCP栈有不一致，就会存在可以用的漏洞。何况GFW这种简陋的TCP栈，可以说漏洞百出。我们曾经枚举过，有一百多种报文的字段组合可以实现当前这种效果。如果GFW不完全重写其TCP栈以符合RFC，那么像西厢展示的这么简单易用的漏洞还会有不少。即使GFW实现了RFC完备的TCP栈，《入侵防御系统的评测和问题》还论证了基于TTL的注入是理论上不可避免的。
最后，GFW的研发运维实力很成问题。首先已知，有不少学生在参与GFW的研发，而GFW的模块质量参差不齐正反映出其研发能力不足的状况。GFW的质量控制也应该是很有问题的，2007年7月17日GFW造成的全国性邮件事故处理之缓慢，让人对GFW的运维能力产生很大的疑问。
总之，GFW的屁股比微软还大，懒得挪。
对GFW进行DDoS
我们一直不提这件事情。DDoS有很多问题。
首先，DDoS是一个脏活。DDoS首先需要组织botnet，这种事情跟贩卖人口差不多，低级。
其次，DDoS在任何国家都是非法的。2009年5月19日民用DNS攻击案，四个脚本小子荣获“破坏计算机信息系统”奖章。GFW可是号称国家信息海关、国家信息安全基础设施，攻击它，万一被抓了人命事儿小，你的开源项目没有人继续帮你做，多郁闷啊。
再次，DDoS在战略上只会产生负面结果。在这个拔网线司空见惯的时代，推倒GFW，不但不会改善互联网审查的状况，反而可能造成实名制和金盾的崛起——一帮只会整人不懂技术的胡乱拔网线、军管互联网。《总论》就已经说过，双方需要的是一种斗争状况下的动态平衡。大家都得过且过，退避三舍，网民翻墙有方，GFW对上面有交代，就行了。最多偶尔之偶尔，逢年过节，比如国庆或者春节的时候，DDoS开个口子让大家出去遛一遛。
当然，虽说问题多多，DDoS的可行性还是有的，GFW的计算规模总归还是有限的。2010年1月3日前后的“解封”据说就跟GFW北京被DDoS有关系。不过也不会详细讨论其方法，只是小字提一下……组织DDoS，先要对全国的网络拓扑很清楚，这就涉及网络测量的课题；也要对GFW的结构了解得很透彻，弱点在哪里，负载均衡算法是怎样的；怎样做最有效，是点射还是温水煮青蛙；怎样反反DDoS，怎样空对空射击。这些都需要学习。其次，DDoS的效果需要一套精细的评估体系，如果不成功需要快速改变策略。GFW不是常规的服务器，成功与否并不是那么显著。因此需要建立一个监测网，在全国不同的ISP对GFW的多种指标实施实时观测。比如不同协议下的阻断响应延迟，TCP的SYN超时和ACK超时时间，各个DNS服务器污染的情况，窗口值的增速等等。所以说这个事情要做也不简单。顺便一提，这个监测网所用监测工具，我们最初给它命名为Collaborative Network Measurement Toolkit for GFW，简写为CNMTG；当然了，这是一个自命名完成之后就停止开发的雾件。
结论的结论
对于普通用户来说，未来的翻墙方式中，我们最推荐私有SSH代理和私有VPN，在安全性和稳定性上有优势，组队合购VPS或独立主机建VPN更好。
批评家们，请正确对待参与GFW建设的技术人员。技术是中性的，是无罪的，只不过技术为政治所利用。GFW的确在防控蠕虫病毒和垃圾邮件上有重要作用。至于方滨兴院士，他更像是一个营销人员或者政客而不是科学家。
每个国家的老大哥都有一样的爱好，就是以国家安全的名义无限扩张权力。米帝用来做网络深度检测的CNCI，预算300亿刀，是GFW、金盾的多少倍？没有那个局的全球阴魂你感觉到了吗？唯一的区别在于，我朝的老大哥做事情太笨拙没下限让普通人也能看出破绽，而资本主义国家的自由民在恐怖中投靠老大哥的无限权力。赛博朋克的曙光还有很久才能看到，对抗前赛博朋克旧势力需要megacorp更快速地成长，所以Google你需要do evil的时候一定不要犹豫。
工信部你好，我们建议：把网络封锁的过程规范化透明化，细化封锁规格和标准，制约滥用和不懂业务胡乱封锁，开放申诉渠道，允许网站自查自纠，一切依法进行。看在我们没有直接往贵部直属单位门面上喷漆的份上，这个建议还是有诚意的吧？
Greetings fly out to tek4, KLZ毕业, iGFW, nust-, 店长, r007, r008, t00ls, em777, eviloctal, ZWA, Tor project, i2p, 会長.
读者们，看到这里之时，我们已经解散了。祝大家……
62 comments: