主题：Google准备扯乎了,还要恶心一下中国. -- james

*西厢计划* 提供一组工具，使得用户在一次设置之后，能够以普通程序直连目标网络，而避免GFW的大部分影响。其命

名是为了向中国古典文学史上翻墙的先驱者张某致敬。西厢计划现在已经达到alpha可用状态，在初步的测试中可以让用户以普通浏览器无障碍地直连Youtube。

特性

西厢计划要解决GFW造成的两个 方面的问题：TCP连接重置和DNS劫持（污染）。为此西厢计划提供了两种特性：

- TCP连

接混淆：在每次连接中，通过对GFW的入侵检测系统进行注入，混淆连接，使得GFW无法正确解析连接和检测关键词，从而在有关键词的情况下也避免连接重 置。

- 反DNS劫持：通过匹配GFW伪包的指纹并将其过滤，让用户以普通的客户端也能获得正确的解

析结果。（用户需要设置DNS为没有被污染的DNS，例如8.8.8.8等）

西厢计划不是代理，不是VPN，无需加密，使用时不需要第三方支援，不需要绕道，让用户能够以最优的性能直连目标，使用时不需要运行特别的程序。西厢计划利用现有工具，仅要求用户能够使用iptables进行快速配置，学习难度低。

西厢计划目前能够让用户直连 Youtube和其他Google服务，还有更多潜力可以发掘。

原理简介

西厢计划采取了T. Ptacek等在1998年的论文Insertion, Evasion, and Denial of Service: Eluding

Network Intrusion

Detection中提出规避入侵检测的注入方法。注入法是指发出特制报文，使得这些报文对对方没有效果，但是让IDS错误地分析协议，从而让IDS错误

地认为连接被提前终止了。由于GFW的TCP栈非常简陋，因此我们可以直接利用GFW的TCP栈的特性，对任何遵守RFC的目标主机都采取特定特殊措施，

让GFW无法正确解析TCP连接，从而避免关键词监测。

局限

西厢计划的连接混淆功能对于基于IP地址的封锁和其他无状态的封锁不能生效，因为它需要通过注入攻击改变GFW的连接状态，如果封锁

与连接状态无关便无法进行连接混淆。另外，连接混淆的实现假设连接双方遵守RFC。有一些目标主机或者防火墙不遵守RFC，可能导致正常不含关键词的连接

被对方终止或者忽略。因此我们特别使用ipset，把作用范围限制在需要的地址段（比如Google），以避免不必要的问题。

西厢计划目前依赖linux内核的netfilter功能，因此要求用户平台是linux，暂时没有移植。之前有一个基于

WinPcap的版本<http://code.google.com/p/scholarzhang/source/browse/branches/scholarz...>

可以在MinGW32环境下编译运行，实现了连接混淆的部分，未实现反DNS劫持的部分，用户仍然可以试用<http://scholarzhang.googlecode.com/files/scholarzhang-0.3.2-mingw32-a...>，但不再维护。

西厢计划所用的GFW伪包指纹可能在此项目发布之后被GFW更改，因此用户 可能需要使用最新的版本才能让功能生效。

报告问题

请到本项目的issue list <http://code.google.com/p/scholarzhang/issues/list>报告问题。

更多工作

- 更细致的测试

- 打包（deb、dkms、rpm）以提高可用性

- FreeBSD、Windows等系统的移植

希望感兴趣

的朋友参与帮助此项目的开发，特别是以上三项。可以直接向项目管理员发邮件或者在项目wiki页留言成为committer，也可以直接fork一个新项

目，都欢迎。

另外由于目前广泛应用的CDN系统是以支持GeoIP的DNS为基础的，这要求用户

使用的DNS服务器应当与自身所处网络尽可能近，否则用户上网会很缓慢。如果您愿意为突破GFW出一份力，欢迎在国内架设递归DNS服务器，此项目的反

DNS劫持模块可以使递归DNS服务器的缓存不被GFW投毒，从而国内用户可以在任何操作系统下，只需要将系统DNS设置为您的DNS服务器，不用任何其

它设置（用户不必使用本项目），就能得到即时、正确、最优的DNS返回。

“西厢计划”原理小解

文章分类:互联网

原文出处：http://blog.youxu.info/2010/03/14/west-chamber/，略有改动

待月西厢下，迎风户半开。隔墙花影动，疑是玉人来。

最近推上最流行的一个关键词是”西厢计划”，这个计划名字取得很浪漫，客户端叫做张生，对，就是西厢记里面那个翻_墙去见崔莺莺小姐的张生；显然，服务器端必然叫做崔莺莺。客户端的张生是最重要的部件，可以不依赖于服务端工作。因为西厢计划的作者只是简要的介绍了一下原理，其他报道又语焉不详，我当时就觉得很好奇，花了昨天一个晚上详细读了一下源代码，终于知道怎么回事了，觉得原理非常漂亮，所以写篇文章介绍总结一下。

先说大方向。大家都知道，连接被重置的本质，是因为收到了破坏连接的一个TCP Reset 包。以前剑桥大学有人实验过，客户端和服务器都忽略 Reset，则通信可以不受影响。但是这个方法其实只有理论价值，因为绝大多数服务器都不可能忽略 Reset 的 （比如 Linux，需要 root 权限配置iptables，而且这本身也把正常的 Reset 给忽略了)。只要服务器不忽略 Reset，客户端再怎么弄都没用，因为服务器会停止发送数据，重置这条连接。所以，很多报道说西厢计划是忽略 Reset，我从源代码来看应该不是这样。在我看来，西厢计划是利用了墙的一个可能的弱点–墙只在连接发起的时候把一个 TCP 连接加入监听序列，如果墙认为这个连接终止了，就会从监听序列中去掉这条记录，这样，这条连接上后续的包就不会被监听。西厢计划就是让墙“认为”这个连接终止的一个绝妙的方法。只要墙认为这个连接两端都是死老虎，墙就不会触发关键词检测，其后所有的数据，都不存在连接被重置的问题了。

如何让一个连接置之死地而后生，就是西厢计划那帮黑客神奇的地方了。这也不是一日之功。 首先，这帮牛人发现，墙实际是一个入侵检测系统，把含有关键字的包当成一种“入侵”来对待。采取这种设计有很多好处，但缺点是入侵检测系统可能具有的问题，墙都可能有。西厢计划主页上那篇著名的论文就是讲这些七七八八的漏洞的。可以说处理这些七七八八的漏洞是非常困难的，迫使墙的设计者“拆东墙，补西墙”。这样补来补去，外表看起来好像很牛逼的墙，其实有很多本质上无法简单修补的漏洞，其中有一个致命的，就是 TCP 连接状态的判定问题。 出于入侵检测系统这种设计的局限，墙没有，也没办法准确判定一条 TCP 连接的状态，而只是根据两边收到的数据来“推测”连接的状态。而所有的关键词检测功能，都是基于“连接还活着”的这个推测的结果的。因为墙的规则是在连接发起的时候开始对这条连接的检测，在连接终止的时候停止对这条连接的检测，所以，一旦对连接的状态推测错误，把还活着的连接当成已经关闭的连接，墙就会放弃对这条连接上随后所有的包的检测，他们都会都透明的穿过墙的入侵检测。

上面只是想法，具体到 TCP 协议实现这一层，就要只迷惑墙，还不能触及我要通信的服务器。最理想的情况下，在任何有效通信之前，就能让墙出现错误判断，这些，就需要对 TCP 协议有深刻理解了。西厢计划的那帮黑客，居然真的去读 TCP 几百页的 RFC，还居然就发现了方法（这里我假设读者都知道 TCP 的三次握手过程和序列号每次加一的规则）。 我们都知道，三次握手的时候，在收到服务器的 SYN/ACK 的时候，客户端如果发送 ACK 并且序列号+1 就算建立连接了，但是客户端如果发送一个序列号没 +1 的 FIN （表示连接终止，但是服务器知道，这时候连接还没建立呢， FIN 这个包状态是错的，加上序列号也是错的，服务器自己一判断，就知道这个包是坏包，按照标准协议，服务器随手丢弃了这个包），但这个包，过墙的时候，在墙看来，是表示连接终止的（墙是中国制造的，是比较山寨的，不维护连接状态，并且，墙并没有记下刚才服务器出去的 SYN/ACK 的序列号，所以墙不知道序列号错了）。所以，墙很高兴的理解为连接终止，舒了一口气去重置其他连接了， 而这个连接，就成了僵尸，墙不管你客户端了，而这时候，好戏才刚刚开始。

事实上，墙是双向检测的（或者说对每个包都检测的），因此，对服务器和客户端实现相同的对待方法，所以，墙不管客户端还不行，假如服务端有关键词传给客户端，墙还是有可能要发飙的（这里说有可能，因为我也不知道）。所以，最好的办法就是，让服务端也给墙一个终止连接的标志就好了。可是这个说起来简单，做起来难，怎么能让不受自己控制的服务器发一个自己想要的包呢？ 西厢计划的那帮黑客，再次去读几百页的 RFC，令人惊讶的发现，他们居然在 RFC 上发现了一个可以用的特性。我们上面说了，三次握手的时候，在收到 SYN/ACK 后，客户端要给服务器发送一个序列号+1 的ACK，可是，假如我不+1呢，直接发 ACK 包给服务器。 墙已经认为你客户端是死老虎了，不理你了，不知道你搞什么飞机，让这个 ACK 过了。可是服务器一看，不对啊，你给我的不是我期待的那个序列号， RFC 上说了，TCP 包如果序列号错了的话，就回复一个 Reset. 所以，服务器就回复了一个 Reset。这个 Reset 过墙的时候，墙一看乐了，服务器也终止连接了，好吧，两边都是死老虎了，我就不监听这条连接了。而至于客户端，这个服务器过来的 Reset 非常好识别，忽略就是。随后，客户端开始正确的发送 ACK，至此，三次握手成功，真正的好戏开始，而墙则认为客户端和服务器都是死老虎，直接放过。所以，张生就这样透明的过了墙。 至于过墙以后所有的事情，《西厢记》里面都有记载，各位读者自行买书学习。

现在的西厢计划客户端，即“张生”模块的防连接重置的原理就是这样，服务器端，即莺莺模块的实现也是类似的。防DNS那个，不懂 DNS 协议，所以看不懂。我猜想，因为开发人员都是黑客，所以自然喜欢用最经得起折腾和高度定制的 Linux 开发。 现在看西厢计划的实现，因为依赖于 Linux 内核模块 netfilter，在 Linux 上如鱼得水，但往其他平台的移植可能是个亟待解决的问题。 我觉得，在其他平台上，可以通过 libpcap 和 libnet ，在用户态实现相同的功能，就是有点麻烦而已，有兴趣的懂网络的可以照西厢计划原理，在家自行做出此功能；当然，全中国人民都用 Linux 最好。