我们知道，墙封锁一个网站的手段有DNS污染、IP封锁、TCP Reset（TCP连接重置）等手段。而一个网站一旦被墙，一般情况下是无法直接通过301（或302）跳转到其他网站的。如果只是IP被封还好说，换IP通常能解决问题。但如果是根据域名关键字进行的TCP Reset，这时候不管怎么换IP（除非是国内IP）都无法解除封锁，当然也不可能进行301跳转（浏览器在收到HTTP服务器的301跳转Response之前TCP连接就已经被墙Reset而断开了，浏览器根本收不到HTTP服务器的任何Response）。而DNS污染的话自然更不用多说，只能换域名了，301跳转更不可能做到。然而，现在出现了很多号称可以解决域名被墙的服务，可以在网站被墙后通过301跳转到新的网站上。经过测试，还真能做到绕过墙的TCP Reset封锁，而这些服务的IP却都在海外（并非是使用了国内IP避免被墙的原因），而客户端只需要一个正常的浏览器即可（即客户端并不需要开启科学上网）。那么它们是怎么做到的呢？
要解释清楚其中的技术原理，还得回到2010年的西厢计划。很早就经常科学上网的同学们应该都对西厢计划并不陌生，它是一个只需要运行在客户端就能绕过很多封锁访问目标网站的工具，解决TCP Reset的原理是对本地的TCP/IP协议进行修改，在不伤害客户端和服务器之间的TCP连接的前提下让墙误以为TCP连接已经断开或者无法正确跟踪到TCP连接。之后出现的INTANG项目同样是这个想法的延续。
不过，不管是西厢计划还是INTANG，都是运行在客户端上的工具，理论上只在服务器上运行无法起到效果，经过测试也能看到实际和理论相符。那么有没有一种工具可以在只服务器上运行，修改TCP/IP协议从而绕过封锁的工具呢？这方面同样有团队做了研究，研究的成果就是Geneva项目，GFW Report也对其做了详细介绍。在这篇文章中，列举了6种可以绕过TCP Reset的规则，6种规则都可以在只客户端部署生效（这时候服务器并不需要运行Geneva），而前4种可以在只服务器部署生效（这时候客户端并不需要运行Geneva）。不过Geneva的官方Github中只收录了客户端的规则，文章中的服务器规则并没有被收录在Geneva的官方Github中。而且文章中的策略3只给出了客户端的规则，遗漏了服务器端的规则。经过阅读Geneva的规则介绍和策略3的描述，我已经重新还原了策略3的服务器规则，重新收录了4种服务器规则到我自己的Github Fork中。经过本地环境的模拟加上tcpdump抓包观察测试，看到还原的策略3服务器规则和文章中描述的行为一致，可以认为就是策略3本来的服务器规则。但是，在之后的真实环境的测试中发现这4种服务器策略全都失效了，墙依然对TCP进行了Reset。经过抓包看到服务器的行为确实和文章中描述一致，所以可以确认并非是由于Geneva没有正常工作导致的，而是墙已经为了应对这4种策略进行进化了。所以，墙并不是一成不变的，而是会进化的，那我们又该怎么办呢？
讲到这里，就不得不提另一个策略发现工具SymTCP了。虽然现有的4中策略已经失效，但并不代表我们不能发现新的策略。而SymTCP就是新策略发现工具，通过自动学习可以自动发现新的策略绕过墙的TCP Reset。之后我们就能把新的策略转换为Geneva的规则格式进行使用了。不过，这样的话我们就会陷入到和墙的无休止争斗中，不断发现新策略，而墙则不断封锁新策略。而且规则的转换也是一个麻烦事，暂时还没有工具可以自动从SymTCP的规则转换为Geneva的规则，需要人工转换。并且需要修改SymTCP使其不仅可以发现客户端规则同样也能发现服务器端规则。
那么，有没有一种一劳永逸的方法，使墙再怎么进化也无法避免这种策略的影响，而且这种策略只需要运行在服务器上，从而绕过封锁呢？在下结论之前，我们需要来研究一下一个正常的HTTP协议通讯是怎么进行的： 1、浏览器发起TCP连接，经过3步（次）握手建立和服务器的TCP连接。 2、浏览器发送HTTP Request。 3、服务器收到Request，发送HTTP Response。 而墙通常在看到浏览器发送的HTTP Request中包含关键字就会进行TCP Reset。讲到这里，聪明的同学或许已经想到了：如果服务器不等HTTP Request，而在TCP连接建立后立即发送HTTP Response，在墙进行TCP Reset之前就将Response送到浏览器进行抢答，是不是就能绕过TCP Reset了？而且还能无视之后墙的进化（因为浏览器的请求根本还没有经过墙）？说干就干，由于抢答模式不符合HTTP规范，所以常见的HTTP服务器无法实现抢答模式，所以让我们写个Python小程序来测试一下：
import socket
import threading
import time
def main():
serv_sock = socket.socket()
serv_sock.bind(('0.0.0.0', 80))
serv_sock.listen(50)
while True:
cli_sock, _ = serv_sock.accept()
# 关闭Nagle算法，立即发送数据
cli_sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
cli_sock.sendall(b'''HTTP/1.1 302 Moved Temporarily\r\n'''
b'''Content-Type: text/html\r\n'''
b'''Content-Length: 0\r\n'''
b'''Connection: close\r\n'''
b'''Location: https://www.microsoft.com/\r\n\r\n''')
def wait_second():
time.sleep(1) # 等待1秒钟，确保数据发送完毕
cli_sock.close()
threading.Thread(target=wait_second).start()
if __name__ == '__main__':
main()
写完了来测试一下，发现依旧被TCP Reset了。那么，问题出在哪里？让我们重新回到上述HTTP协议通讯的3个步骤中的第1步：TCP的3步握手：
从TCP的3步握手中，我们可以看到第3步中客户端发送了ACK就已经完成了TCP连接的建立，这时候客户端并不需要再等服务器的回复就能立即发送数据。也就是说，浏览器会在发送ACK后立即发送HTTP Request，ACK和HTTP Request几乎是同时发出的。而服务器在收到浏览器的ACK后基本也就代表着已经收到了HTTP Request了，抢答失败！
那么，有没有办法让浏览器在TCP连接建立后延迟发送HTTP Request，而又不改动客户端行为呢？讲到这里，对TCP协议比较熟悉的同学或许已经想到了，那就是TCP window size。而通过调用setsockopt()就能修改TCP window size。让我们来修改一下Python小程序，把window size改为1再进行测试（TCP连接建立完成后，客户端只能发送1个字节，等待服务器的确认后才能继续发送更多的数据）：
import socket
import threading
import time
def main():
serv_sock = socket.socket()
serv_sock.bind(('0.0.0.0', 80))
serv_sock.listen(50)
while True:
cli_sock, _ = serv_sock.accept()
# 设置TCP window size为1
cli_sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 1)
# 关闭Nagle算法，立即发送数据
cli_sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
cli_sock.sendall(b'''HTTP/1.1 302 Moved Temporarily\r\n'''
b'''Content-Type: text/html\r\n'''
b'''Content-Length: 0\r\n'''
b'''Connection: close\r\n'''
b'''Location: https://www.microsoft.com/\r\n\r\n''')
def wait_second():
time.sleep(1) # 等待1秒钟，确保数据发送完毕
cli_sock.close()
threading.Thread(target=wait_second).start()
if __name__ == '__main__':
main()
改完测试，发现仍旧被TCP Reset了。什么原因？通过抓包，我们看到对TCP window size的修改并没有生效，window size依旧很大。在查阅了Linux man page后我们看到关于SO_RCVBUF有这么一段话：
The minimum (doubled) value for this option is 256.
这也就意味着即使我们通过setsockopt()将SO_RCVBUF设置为1，Linux内核也会将其作为256处理。而Linux man page中也对SO_RCVBUFFORCE做了说明：只能突破最大值的限制（but the rmem_max limit can be overridden），但不能突破最小值的限制。而256字节基本就可以容纳整个HTTP Request。看来通过setsockopt()行不通（不管SO_RCVBUF还是SO_RCVBUFFORCE都行不通），我们得找别的方法。
讲到这里，我们很自然地又想到了Geneva：上述Geneva的策略2中服务器规则正是利用了TCP window size做到的四字节分割（设置window size为4）。这样，就绕过了setsockopt()的限制，直接对TCP数据包进行修改了。
在我们把四字节分割法部署到服务器运行Geneva后，再结合上述Python小程序，经过测试我们发现已经成功绕过了TCP Reset，浏览器跳转到了微软网站。我们终于成功了！
然而，在浏览器第二次访问服务器时发现依然被TCP Reset了。不过，这已经影响不到301跳转（上述Python小程序还是302跳转，需要301的同学自行修改）了，301跳转的话浏览器已经被重定向到新的网站了，不会再次访问这个服务器（需要保证新旧网站不能使用相同IP），但这并不妨碍我们继续探究一下为什么第二次访问会被TCP Reset：通过抓包我们看到，第一次访问时浏览器虽然在第一个附带用户数据的数据包中只发送了4个字节，但后续会将剩余的整个HTTP Request通过一个数据包发送到服务器导致TCP Reset。而墙是有审查残留的，一段时间（几分钟）内不管是否出现关键字，对源IP和目标IP之间的TCP连接会进行无差别的Reset。所以在之后的这段审查残留时间内，只要TCP连接建立就会被Reset，抢答模式无法起到作用。
知道了原因我们就能采取对策了，我们知道客户端是因为收到了服务器确认数据包中的TCP window size很大，所以才能一次性把剩余的Request发送完毕，所以需要对后续的TCP window size做同样的修改，保证客户端看到的window size一直处于比较小的水平：通过对TCP协议的了解，我们知道连接建立时的window size是通过SYN+ACK包确定的，而后续的window size是通过ACK包确定的。所以，我们对规则2做少许的修改就能做到对后续window size的修改：
[TCP:flags:A]-tamper{TCP:window:replace:4}-|
在服务器上我们同时运行规则2和上述修改后的规则（需要开2个Geneva进程，注意第2个进程需要在命令行中指定--in-queue-num和--out-queue-num避免和第1个冲突），我们终于能稳定地运行上述抢答模式，再也不会被TCP Reset了。
实际上我们可以将2条规则中的window size都设置得更小一些，甚至设置为0，避免客户端发送任何数据（实际上由于window size探测机制的原因，客户端仍旧会以极慢的速度一个字节一个字节地发送数据，不过不影响我们的抢答模式）：
[TCP:flags:SA]-tamper{TCP:window:replace:0}-|
[TCP:flags:A]-tamper{TCP:window:replace:0}-|
至此，HTTP的抢答模式就基本完成了。不过，由于Geneva和上述小程序都是用Python编写的（甚至都没有使用asyncio），性能会比较差一些。Geneva会自己添加iptables的NFQUEUE规则，不过规则太过于宽松，导致不需要处理的数据包也会经过Geneva。所以大家可以在启动Geneva后手动删除这些规则，自行添加更精确的规则（只处理SYN+ACK和ACK）。不过经过我的测试，即使使用精确的iptables规则也差不多只能利用20Mbps左右的带宽。如果希望有更高的性能，可以使用C/C++（结合libev，或asio，或直接epoll；或者使用golang、rust等）结合libnetfilter_queue，利用iptables的NFQUEUE来完成，可以跑满千兆带宽。其实Geneva的底层用的也是libnetfilter_queue和NFQUEUE。由于本系列只做概念验证，而且因为篇幅的限制（本文已经很长了），在此就不展开C/C++的实现了，感兴趣的同学可以和我联系，如果感兴趣的同学比较多的话我就再新开一个系列讲一下这方面的内容。另外需要注意的是，Geneva的编译环境为Python 3.6，使用Debian 10自带的Python 3.8/3.9会出现各种莫名其妙的问题，建议大家还是从Python官网下载Python 3.6的源码进行编译使用Geneva。
在解决了HTTP的TCP Reset问题后，我们还需要解决HTTPS的TCP Reset。而HTTPS由于需要完成TLS握手才能发送HTTP Response，所以抢答模式似乎无法应用于HTTPS。在下一篇中，我会介绍几个绕过HTTPS的TCP Reset方法。敬请期待。
如果对本系列话题感兴趣的同学也可以联系我。我的联系方式为：
1、Email: lehui99#gmail.com
2、Twitter: @davidsky2012
3、TG: @davidsky2000
4、本系列Github: lehui99/articles
BTW，本来想将此文首发于hostloc的（因为hostloc上站长朋友比较多，而本系列是帮助站长解决TCP Reset问题的），不过由于hostloc需要邀请码，一直没有注册成功，而淘宝购买hostloc邀请码曾经有过不愉快的经历，遂作罢。
最后，本文欢迎转载，不过转载时还请保留原文链接，因为之后我还会对本文进行完善（如错误修正、内容补充等）。
没有评论:
发表评论