引言

（本文首发于twitter.com，原作者就是我）

大家在河南的可能已经都知道了最近河南那边的GFW竟然更新了，经过不断摸索，总算是搞清楚是怎么回事以及应对方案了。

首先GFW“黑名单”是什么？

GFWList，我将其称作“黑名单”。是通过一个存储GFW所墙网站列表的庞大项目。这个项目由网友齐心协力完成，涵盖了大多数普通用户需要访问的外网。用户发现了可能被封锁的网站，将会提交至项目，维护者通过审核，再三确认后将其载入名单。[1]

一切的开端，人们是如何绕过GFW的？

其实原因可能是因为大量的翻墙用户使用Trojan等协议进行“翻墙”，而Trojan协议的伪装方式是使用TLS加密流量来让GFW看上去像是在用HTTPS协议正常访问一个境外网站而已。 但这并不能一直都骗过GFW，当你的连接出现“时间长 高并发 大流量 多境内IP连接”的流量特征时，就会引发GFW的“主动探测”[2]，还好Trojan协议允许你进行站点“伪装”（websocket)，让正常访问网站的GFW看到的是一个英文网站之类的，也能骗过GFW认为你是在正常访问一个网站而不是用它翻墙，但就长期而言，这样的方式有风险，一旦GFW认为你是在利用这个站点搭代理“翻墙”，轻则把你连接的端口封掉（通常HTTPS走的是443端口），重则就会把整个IP和域名加入“黑名单”（也就是说所有经过GFW发往这个IP/网站的包，包括TCP/UDP都会被丢掉）。

但这种方法毕竟封锁效率有限，有时还得人工识别，再加上现在有很多协议（v2ray xTLS等）都可以走CDN转发这些TLS流量[3]，而CDN的IP又是一大堆，上面还有一些其它正常的网站走的也是这些IP，简单的封锁这些IP反而会“误伤”到这些正常的通往境外网站的流量（那就真成朝鲜了.jpg）。

反转：GFW的升级

正当大家以为可以长期挂代理高枕无忧时，这个河南GFW来了个升级很好的“解决”了这个“问题”，用方法就是经典的“RST复位攻击”！[4]（没错就是你以前早些年访问谷歌时看到的那个“连接已重置”），原理是当你用基于TCP连接的协议时（TLS就是基于TCP连接的协议），河南GFW就会在长连接建立的几分钟之后向你境内客户端这边伪造一个RST包，这时你的客户端就会毫无疑问的丢弃与服务端的缓冲区上所有数据，强制关掉连接。之后你的每一次都会像图①那样直接被GFW伪造的RST包阻断。

图①-GFW的RST攻击方式

据TG网友 @MiyamotoKonatsu 测试，这个攻击阀值很低，虽然说是黑名单，但是跟那次泉州模式似的连几分钟就给你发RST包阻断就他妈离谱！（虽然还是比泉州模式泉州模式好的是毕竟还是黑名单，陌生的境外网站不会默认给你来个阻断，而是长连接还会给你保持着几分钟后再给你发RST包阻断，它真的，我哭死QWQ）

如此低的阈值让人惊讶

猫鼠游戏：惊讶的发现

所以……难道我们就真的无能为力了吗? 当然不是！俗话说得好，只要思想不滑坡，办法总比困难多！v2ray core项目的开发者以及志愿者进行了讨论和研究[5]，如果是服务端和客户端都支持Timestamps的话那么tcp每个包都会带有额外的10bytes timestamps时间截，那么在GFW重置连接的RST数据包时就会被直接丢掉，这将表现为没有影响。

那么什么是tcp连接中Timestamps呢?

timestamps是作为一个 TCP 选项存在于 TCP 首部。引入 timestamp 最初有两个目的：1.更精确地估算报文往返时间(round-trip-time, RTT) 2. 防止陈旧的报文干扰正常的连接.[6]TCP Timestamp 选项虽然能带来好处, 但并不是所有的 TCP 连接都会使用该选项，比如 Windows 系统就是默认不不启用该选项的，而 Linux 系统则是默认启用了该选项。 据 tcpm 的统计，在全球范围内，使用了 TCP Timestamp 的连接比例大概为 60%~70% 。[7]

不支持 TCP Timestamp 的理由是该选项占用的报文长度太多了，它会占用 TCP 报文首部的 10 个字节，而且是每个报文都会有这种损耗。 好巧不巧，据v2ray core开发者测试，所有由GFW发送的RST包都是没有Timestamp的！那就是说如果代理服务端和客户端都使用带有Timestamp的tcp连接的话那么由GFW发送的不带有Timestamp的RST包就会被忽略！那么连接就会顺利进行下去了！我们就又能够愉快的与代理服务器握手连接了！♪(^∇^*)

（显然人们不知道自己的设备有没有开 TSopt，有的默认开了就没被阻断，这就是人们对河南新上的 SNI 黑名单说法不一的原因之一）

据telegram用户的小道消息传言，明年的四月这阴间阻断将在全国实施！

TG群的小道消息

所以我现在呼吁各位翻墙用户都把自己客户端/服务端的timestamp选项打开！

转折：如何打开tcp连接中的timestamp选项？

在你的服务端和客户端都必须启用你的timestamp选项，tcp连接才会在之后的头部带上timestamp！

如果你是linux作为服务端/客户端，那么恭喜，你的timestamp选项应该是默认开启的，不过我还是建议您在控制台中输入以下指令把这个选项再确认开启一下（ipv6也会生效）：

sysctl -w net.ipv4.tcp_timestamps=1

如果您是windows用户或者使用winsever来做的代理服务器，那请您使用管理员权限打开powershell，然后输入以下指令：

netsh interface tcp set global timestamps=enabled

如果你是安卓用户，那么不是国产流氓魔改系统的话请将您的系统升级为最新版本（安卓10以上）

如果您有root权限，您可以通过以下步骤尝试更改TCP timestamp选项：

1. 使用Root权限的文件管理器：

- 在您的Root设备上安装一个能够访问系统文件的Root文件管理器应用，例如"Root Explorer""ES File Explorer"（请确保下载安全的应用）或"MT管理器"。

- 找到并编辑系统配置文件 `/proc/sys/net/ipv4/tcp_timestamps`。

2. 使用终端模拟器应用：

- 安装终端模拟器应用，例如"Termux"。

- 打开终端模拟器并获取Root权限：`su` - 使用命令来更改TCP timestamp选项：`echo 0 > /proc/sys/net/ipv4/tcp_timestamps`

（0表示禁用，1表示启用）

完成！

这样你的客户端/服务端就支持timestamps了！下次连接时的tcp首部都将带有timestamps时间截！

（目前已知的情报：

墙不给 开了TCP Timestamps的固定宽带网络 发RST， 给没开TCP Timestamps选项的固定宽带网络发RST，。

对于数据流量网络，无论开不开TCP Timestamps，墙都会发伪造的RST。 无论任何一种情况，均未收到过带Timestamps的 RST。

这个离谱的技术其实上是某些公司研发出来的产物，被河南那边的“小天才”发现拿去直接套用在了GFW上。）

总结

重点是在于不要让你的客户端听信GFW伪造出来的“连接重置”的的“谗言”，在第一次客户端与服务端连接时就发现双方都支持timestamps时间截，之后发送的第二次连接中双方都会使用头部多出10字节的时间截，再之后第三次连接由GFW伪造出来的“重置连接”的包不带有timestamps时间截，客户端一眼识破GFW的“阴谋”，肯定不会照着把连接断开而是直接会把这连接重置的“假”包忽略掉，之后就与服务端顺利进行三次握手实现长连接继续上外网了。[斜眼笑][调皮]

展望未来/后记

开启时间戳是利用PAWS机制来丢弃时间戳和seq不同步的TCP报文，如果 GFW 给 RST packet 加上 timestamp，那么该方案即失效。

理论上是伪造的RST包有可能带有正确的timestamps的，但技术上我还不知道GFW那边能不能实现，但那些都是后话了(◔◡◔)

也许将长连接变为（多个）短连接是更好的方案。多路复用（multiplex）就是 method 之一。

如今，sing-box 有多种 mux 方案，Xray 也宣布了新的 switch 流控。多路复用从根本上会消除「长连接」特征。

GFW的工作原理是未知的。而科学上网是已知，都是开源的。这是一个不对等的游戏。对抗封锁方处于劣势中，一群不为金钱冒着被捉的风险。这些人都是英雄。

──来自推特网友

[1]https://medium.com/@hackl0us/%E4%B8%80%E9%BB%91%E4%B8%80%E7%99%BD-2%E5%A5%97%E8%A7%84%E5%88%99%E8%B6%B3%E7%9F%A3-e008cbc87570

[2]https://chinadigitaltimes.net/chinese/342752.html?amp

[3]https://v2xtls.org/v2ray%E4%BD%BF%E7%94%A8cloudflare%E4%B8%AD%E8%BD%AC%E6%B5%81%E9%87%8F%EF%BC%8C%E6%8B%AF%E6%95%91%E8%A2%AB%E5%A2%99ip/

[4]https://www.51cto.com/article/631439.html

[5]https://github.com/XTLS/Xray-core/issues/2426

[6]https://switch-router.gitee.io/blog/tcp-timestamp/

[7]https://mailarchive.ietf.org/arch/msg/tcpm/861z901kDYtHSWxDOsic_Ejpqz8/