竹磬网-邵珠庆の日记 生命只有一次，你可以用它来做些更多伟大的事情–Make the world a little better and easier

记一次对 G-F-W 防火墙的探究

突然朋友传了一个数据包给我，说他的openVPN连不上了。

抓包发现刚一握手结束便收到了一个RST包，导致一直连不上。我打开数据包，发现果然如此：

可以看到，三次握手刚完毕，客户端发送第一个控制消息到服务端，便收到了服务端发送的RST数据包，一直如此。

应该是有中间设备搞的鬼，于是我又到服务器端抓取了些数据：

果然的，服务器也收到了RST数据包，于是两者的连接便断开了。

再仔细分析下客户端的RST数据包：

IP包的序号是12345，TTL是120。再看正常的数据包：

IP包的序号是0，TTL是46。很明显RST数据包的TTL比正常的要大，而且每次RST的IP序号都是12345，应该是GFW没错了。

正常情况下初始的TTL是64，正常收到的TTL是46，跳数是15，说明我的电脑到服务器之间经过了15个路由设备。

为了证明这点，查看服务端收到的正常数据包：

服务器收到的TTL是50，因为我的电脑还要经过内部的一个路由器，所以TTL差了1。

同时查看服务端RST数据包的TTL值：

TTL值为117，因此得到的信息如下：

客户端->服务器：15、GWF->服务器：117、GFW->客户端：120。

假设GFW每次发送的TTL值都固定不变且为x，则有：x-117+x-120=15；得x=126。

所以GFW和我的电脑的跳数应该是6：

图示的应该就是GFW的位置。

接下来问题来了，她是怎么识别出openVPN流量的呢？

我猜测是根据数据包的特征来识别的，那么我单独发送单个数据包，应该也会返回RST数据，根据这一理论，我用scapy发送了单个的数据包，内容和三次握手之后客户端发送的第一个数据包一样，但结果是失望的，并没有收到RST数据包。

于是进一步猜测，TCP连接之后再发送相应的数据包，应该能收到RST，于是又根据这一理论，写下了如下代码：

from scapy.all import *
vpn_payload = "\x00\x0e\x38\x24\x5d\x21\xaa\x3a\x11\x2f\xb3\x00\x00\x00\x00\x00"
conf.verb = 0
vpn_s = IP(dst="yovey.me",id=12345)/TCP(sport=58620,dport=1194,flags="S",seq=0)
print "sending syn"
vpn_s.show()
ans0,unans0 = sr(vpn_s)
print "recv packet,seq = ",ans0[0][1].seq
ans0[0][1].show()
vpn_sa = IP(dst="yovey.me",id=12346)/TCP(sport=58620,dport=1194,flags="A",seq=1,ack=ans0[0][1].seq+1)
print "sending ack"
vpn_sa.show()
ans1,unasn1 = sr(vpn_sa,timeout=1)
vpn = IP(dst="yovey.me",id=12347)/TCP(sport=58620,dport=1194,flags="PA",seq=1,ack=ans0[0][1].seq+1)/vpn_payload
print "sending vpn payload"
ans2,unasn2 = sr(vpn)
ans2[0][1].show()

运行程序，还是没有收到RST数据包。

于是我打开tcpdump，抓取了发包过程的数据包，发现了问题：

在服务器返回syn+ack之后，客户端居然发送了RST到服务器，导致连接断开。经过短暂的思考，才明白客户端网卡在收到来自服务器的syn+ack之后，发现并没有进程在监听该数据包的端口，于是发送了RST数据包给服务器。

必须让客户端不发送RST数据包才行，想到可以通过iptable来过滤数据包，于是在iptable中添加如下规则：

iptables -t filter -A OUTPUT -p tcp --tcp-flags RST RST -j DROP

再运行程序，一切都在计划之中：

还是熟悉的IP序号，还是熟悉的TTL，看来GFW已经可以根据连接来识别流量了，真是下了血本啊。

想到建立连接，我立马联想到不用建立连接的UDP，是不是UDP数据只需要根据单个数据包就能识别了？于是将服务器配置成UDP模式，再次打开openVPN，特么的居然连上了！于是问题解决了，将配置改成UDP就能正常连接了。

介绍一下GFW的工作原理和封锁技术

GFW是Great Fire Wall的缩写，即“长城防火墙”。这个工程由若干个部分组成，实现不同功能。长城防火墙主要指TG监控和过滤互联网内容的软硬件系统，由服务器和路由器等设备，加上相关的应用程序所构成。

首先，需要强调的是，由于中国网络审查广泛，中国国内含有“不合适”内容的的网站，会受到政府直接的行政干预，被要求自我审查、自我监管，乃至关闭，所以GFW的主要作用在于分析和过滤中国境内外网络的资讯互相访问。

GFW对网络内容的过滤和分析是双向的，GFW不仅针对国内读者访问中国境外的网站进行干扰，也干扰国外读者访问主机在中国大陆的网站。

一 关键字过滤阻断

关键字过滤系统。此系统能够从出口网关收集分析信息，过滤、嗅探指定的关键字。主要针对HTTP的默认端口：80端口，因为HTTP传播的内容是明文的内容，没有经过加密，而GFW是一个IDS(Intrusion detection system)。普通的关键词如果出现在HTTP请求报文的头部(如“Host: www.youtube.com”)时，则会马上伪装成对方向连接两端的计算机发送RST包(reset)干扰两者正常的TCP连接，进而使请求的内容无法继续查看。如果GFW在数据流中发现了特殊的内文关键词(如轮子，达赖等)时，其也会试图打断当前的连接，从而有时会出现网页开启一部分后突然停止的情况。在任何阻断发生后，一般在随后的90秒内同一IP地址均无法浏览对应IP地址相同端口上的内容。

二 IP地址封锁

IP地址封锁是GFW通过路由器来控制的，在通往国外的最后一个网关上加上一条伪造的路由规则，导致通往某些被屏蔽的网站的所有IP数据包无法到达。路由器的正常工作方式是学习别的路由器广播的路由规则，遇到符合已知的IP转发规则的数据包，则按已经规则发送，遇到未知规则IP的数据，则转发到上一级网关。

而GFW对于境外(中国大陆以外)的XX网站会采取独立IP封锁技术。然而部分XX网站使用的是由虚拟主机服务提供商提供的多域名、单(同)IP的主机托管服务，这就会造成了封禁某个IP地址，就会造成所有使用该服务提供商服务的其它使用相同IP地址服务器的网站用户一同遭殃，就算是正常的网站，也不能幸免。其中的内容可能并无不当之处，但也不能在中国大陆正常访问。现在GFW通常会将包含XX信息的网站或网页的URL加入关键字过滤系统，并可以防止民众透过普通海外HTTP代理服务器进行访问。

三 特定端口封锁

GFW会丢弃特定IP地址上特定端口的所有数据包，使该IP地址上服务器的部分功能(如SSH的22、VPN的1723或SSL的443端口等)无法在中国大陆境内正常使用。

在中国移动、中国联通等部分ISP(手机IP段)，所有的PPTP类型的VPN都被封锁。

2011年3月起，GFW开始对Google部分服务器的IP地址实施自动封锁(按时间段)某些端口，按时段对www.google.com(用户登录所有Google服务时需此域名加密验证)和mail.google.com的几十个IP地址的443端口实施自动封锁，具体是每10或15分钟可以连通，接着断开，10或15分钟后再连通，再断开，如此循环，令中国大陆用户和Google主机之间的连接出现间歇性中断，使其各项服务出现问题。GFW这样的封锁手法很高明，因为Gmail并非被完全阻断，这令问题看上去好像出自Google本身。这就是你们认为Google抽风的原因。

四 SSL连接阻断

GFW会阻断特定网站的SSL加密连接，方法是通过伪装成对方向连接两端的计算机发送RST包(RESET)干扰两者间正常的TCP连接，进而打断与特定IP地址之间的SSL(HTTPS，443端口)握手(如Gmail、Google文件、Google网上论坛等的SSL加密连接)，从而导致SSL连接失败。

当然由于SSL本身的特点，这并不意味着与网站传输的内容可被破译。

五 DNS劫持和污染

GFW主要采用DNS劫持和污染技术，使用Cisco提供的IDS系统来进行域名劫持，防止访问被过滤的网站，2002年Google被封锁期间其域名就被劫持到百度。中国部分ISP也会通过此技术插入广告。

对于含有多个IP地址或经常变更IP地址逃避封锁的域名，GFW通常会使用此方法进行封锁。具体方法是当用户向DNS服务器提交域名请求时，DNS返回虚假(或不解析)的IP地址。

全球一共有13组根域名服务器(Root Server)，目前中国大陆有F、I这2个根域DNS镜像，但现在均已因为多次DNS污染外国网络，而被断开与国际互联网的连接。

DNS劫持和污染是针对某些网站的最严重的干扰。

干扰的方式有两种：

一种是通过网络服务提供商(Internet Service Provider)提供的DNS服务器进行DNS欺骗，当人们访问某个网站时，需要要把域名转换为一个IP地址，DNS服务器负责将域名转换为IP地址，中国大陆的ISP接受通信管理局的屏蔽网站的指令后在DNS服务器里加入某些特定域名的虚假记录，当使用此DNS服务器的网络用户访问此特定网站时，DNS服务便给出虚假的IP地址，导致访问网站失败，甚至返回ISP运营商提供的出错页面和广告页面。

另一种是GFW在DNS查询使用的UDP的53端口上根据blacklist进行过滤，遇到通往国外的使用UDP53端口进行查询的DNS请求，就返回一个虚假的IP地址。