河南新上的SNI/HOST黑名单墙

[5e2t]

新开个issue，防止在别人的帖子回复时，打扰到别人.......

[RPRX]

#2229

[5e2t]

IPv4的TTL我尝试了 62 63 64 65 66 127 128 129，在Linux上运行的xray，servername填sslip.io时，均不会触发RST。Linux所处的网络模式为桥接模式。

[5e2t]

我看了半天Windows的IPv4报头，真的跟Linux没有什么不同。

[5e2t]

Windows的IPv4报头的TTL为128，跟Linux里的xray一模一样的配置，会触发RST。

[5e2t]

@5e2t 但其实Linux系统把RST忽略了的这种说法也是说不通的，如果墙给我发了RST，但是被Linux系统忽略了，那么我在Windows上应该是能抓到这个RST的..........或者直接在路由器上抓包，就肯定知道墙有没有发RST了，我倾向于相信墙确实没发RST吧

[5e2t]

感谢@yoohooyoo 提供的修改WindowsTTL的方法，经过测试，Windows的IPv4的TTL为 63 64 65 128时，在servername填sslip.io时，均会触发RST。

[Fangliding]

@5e2t 所以到底是rst包被Linux过滤了还是Linux发出的包由于某些特征免于拦截

[5e2t]

windows的IPv4 TTL为127 和129时 把servername填 sslip.io，均会收到RST

[5e2t]

Windows的IPv4的TTL为255，也会触发RST

[5e2t]

分别在Windows上和Linux上 用openssl测试的结果，跟xray的表现、浏览器的表现一模一样，三种情况都是抓到一样的RST。

[5e2t]

三种情况都是在Windows上抓到RST，在Linux上正常使用，没有RST

[RPRX]

我想说的是在 #2229 继续讨论，你这非要搞两个地方。。。

[5e2t]

@RPRX 我已经不知道该测什么了。

[RPRX]

1. 电脑是“直出”还是经过了路由器
2. 你在 WireShark 内看到 TTL 改了吗
3. 问题不在 IP 栈的话，可能在 TCP 栈，看一下 window、MSS 等有什么区别

[5e2t]

@RPRX 电脑经过了路由器
在wireshark里看到TTL改了

[5e2t]

nft代码 以及openssl命令不变，把Go代码改了一下，在第一次TLS握手完成后，延迟五秒把ClientHello在同一条连接上再发送一遍，不同的是，第二次发送就不带4个NOP的 TCP选项了。 此时这同一条连接上第二次发送的 ClientHello 会收到来自河南SNI墙的 RST。

package main

import (
	"fmt"
	"io"
	"net"
	"time"
)

func main() {
	listen, err := net.Listen("tcp", ":1234")
	if err != nil {
		fmt.Println("err=", err)
		return
	}
	defer listen.Close()
	for {
		client, err := listen.Accept()
		if err != nil {
			fmt.Println("err=", err)
			return
		}
		go process(client)
	}

}

func process(client net.Conn) {
	s1 := make([]byte, 319, 319)
	_, err := io.ReadFull(client, s1)
	if err != nil {
		fmt.Println("err=", err)
		return
	}
	mangleData := append([]byte{0x01, 0x01, 0x01, 0x01}, s1...)
	server, err := net.Dial("tcp", "13.33.100.66:443")
	if err != nil {
		fmt.Println("err=", err)
		return
	}

	_, err = server.Write(mangleData)
	if err != nil {
		fmt.Println("err=", err)
		return
	}

	forward := func(src, dest net.Conn) {
		defer src.Close()
		io.Copy(src, dest)
	}
	go forward(client, server)
	go forward(server, client)
	time.Sleep(time.Second * 5)
	_, err = server.Write(s1)
	if err != nil {
		fmt.Println("err=", err)
		return
	}
	time.Sleep(time.Second * 5)

}

似乎只能说明，河南的SNI墙，没有硬编码 TCP的 Header Length， 但是如果TCP 的Header Length不是5 就会放过这个数据包，但并不代表放过这条连接，因为河南的SNI墙似乎并不维护连接状态，所以也没法针对连接来放过。

[5e2t]

刚刚看了下上面这个抓包的 RST包的 seq number 以及 ack number 的确是该条连接所使用的 seq number 和 ack number，并且也准确的记录了已经发送了多少数据包，确认了多少数据包，所以我说这个墙是无状态的说法，应该是极其不正确的。

👆上面这段话是极其不正确的，RST包的 seq number和 ack number 完全由 我发送的ClientHello包的 seq number 以及 ack number 计算得出。
但河南数据流量网络的SNI墙真的是 无状态+有状态 复合体。 既可以用有状态的方式阻断，也可以用无状态的方式阻断。

[lemon99ee]

刚刚看了下上面这个抓包的 RST包的 seq number 以及 ack number 的确是该条连接所使用的 seq number 和 ack number，并且也准确的记录了已经发送了多少数据包，确认了多少数据包，所以我说这个墙是无状态的说法，应该是极其不正确的。

大佬您的研究拜读完了，小白一知半解的想问问大佬有没有应对方法。
我遇到的状况如下：河南联通
PT下载 5个站 5个tracker域名 A/B/C/D/E （B不是CFIP 其他均是）
1：群晖ssh开启net.ipv4.tcp_timestamps=1 A和C的种子过一会就直接无法连接
curl-v去测A和C没有任何回报信息且 ping也不通 偶尔ping能通一下 curl-v依然无任何回报信息

2：群晖ssh关闭net.ipv4.tcp_timestamps=0 A和C的种子会慢慢恢复
此时B的种子开始速度很快的无法连接 （B不是CFIP）此时ssh再开启net.ipv4.tcp_timestamps=1 重新汇报B的种子很快就全好

3：关闭net.ipv4.tcp_timestamps=0的情况下 B的地址去curl-v 握手2次后提示OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 此时ssh开启timestamps=1 再次curl-v B的地址 瞬间得到完整回报信息

4：期间D/E均是CFIP的tracker无任何问题不受任何影响

实在被这墙搞的头晕目眩了，开了timestamps=1 2个站不行 关了timestamps=0 1个站不行
看看大佬这边有没有小白能浅显易懂的解决方案 在这里真的谢谢了

[5e2t]

刚刚看了下上面这个抓包的 RST包的 seq number 以及 ack number 的确是该条连接所使用的 seq number 和 ack number，并且也准确的记录了已经发送了多少数据包，确认了多少数据包，所以我说这个墙是无状态的说法，应该是极其不正确的。

大佬您的研究拜读完了，小白一知半解的想问问大佬有没有应对方法。 我遇到的状况如下：河南联通 PT下载 5个站 5个tracker域名 A/B/C/D/E （B不是CFIP 其他均是） 1：群晖ssh开启net.ipv4.tcp_timestamps=1 A和C的种子过一会就直接无法连接 curl-v去测A和C没有任何回报信息且 ping也不通 偶尔ping能通一下 curl-v依然无任何回报信息

2：群晖ssh关闭net.ipv4.tcp_timestamps=0 A和C的种子会慢慢恢复 此时B的种子开始速度很快的无法连接 （B不是CFIP）此时ssh再开启net.ipv4.tcp_timestamps=1 重新汇报B的种子很快就全好

3：关闭net.ipv4.tcp_timestamps=0的情况下 B的地址去curl-v 握手2次后提示OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 此时ssh开启timestamps=1 再次curl-v B的地址 瞬间得到完整回报信息

4：期间D/E均是CFIP的tracker无任何问题不受任何影响

实在被这墙搞的头晕目眩了，开了timestamps=1 2个站不行 关了timestamps=0 1个站不行 看看大佬这边有没有小白能浅显易懂的解决方案 在这里真的谢谢了

我觉得问题主要出在联通到CF速度挺慢的这上面。Linux系统默认都是开启TCP Timestamps的，很难想象开启这个选项居然会导致无法访问两个原本可以访问的网站。 你说的那个A和C的奇妙现象 大概率就是因为CF的IP速度很慢而已，而B就非常具有规律性，实际上这五个网站的现象值得参考的也就 B D E。 A和C不应该认为是墙导致的。 要我说也就B被墙了而已，其他四个域名都没被墙。 实际上只要你把域名发出来，我肯定可以告诉你 哪个域名在黑名单里面，哪个域名不在黑名单里。

[lemon99ee]

刚刚看了下上面这个抓包的 RST包的 seq number 以及 ack number 的确是该条连接所使用的 seq number 和 ack number，并且也准确的记录了已经发送了多少数据包，确认了多少数据包，所以我说这个墙是无状态的说法，应该是极其不正确的。

大佬您的研究拜读完了，小白一知半解的想问问大佬有没有应对方法。 我遇到的状况如下：河南联通 PT下载 5个站 5个tracker域名 A/B/C/D/E （B不是CFIP 其他均是） 1：群晖ssh开启net.ipv4.tcp_timestamps=1 A和C的种子过一会就直接无法连接 curl-v去测A和C没有任何回报信息且 ping也不通 偶尔ping能通一下 curl-v依然无任何回报信息
2：群晖ssh关闭net.ipv4.tcp_timestamps=0 A和C的种子会慢慢恢复 此时B的种子开始速度很快的无法连接 （B不是CFIP）此时ssh再开启net.ipv4.tcp_timestamps=1 重新汇报B的种子很快就全好
3：关闭net.ipv4.tcp_timestamps=0的情况下 B的地址去curl-v 握手2次后提示OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 此时ssh开启timestamps=1 再次curl-v B的地址 瞬间得到完整回报信息
4：期间D/E均是CFIP的tracker无任何问题不受任何影响
实在被这墙搞的头晕目眩了，开了timestamps=1 2个站不行 关了timestamps=0 1个站不行 看看大佬这边有没有小白能浅显易懂的解决方案 在这里真的谢谢了

我觉得问题主要出在联通到CF速度挺慢的这上面。Linux系统默认都是开启TCP Timestamps的，很难想象开启这个选项居然会导致无法访问两个原本可以访问的网站。 你说的那个A和C的奇妙现象 大概率就是因为CF的IP速度很慢而已，而B就非常具有规律性，实际上这五个网站的现象值得参考的也就 B D E。 A和C不应该认为是墙导致的。 要我说也就B被墙了而已，其他四个域名都没被墙。 实际上只要你把域名发出来，我肯定可以告诉你 哪个域名在黑名单里面，哪个域名不在黑名单里。

忘记补充了 A和C网站 做任何CF优选IP HOST 都没用 改一条马上就废（没添加host之前 都是通的 HKG LAX都试过，速度很快）
只要写上host 马上ping可以通 只要用一次curl-v不通 之后ping也不通了 已经持续3天了

[5e2t]

刚刚看了下上面这个抓包的 RST包的 seq number 以及 ack number 的确是该条连接所使用的 seq number 和 ack number，并且也准确的记录了已经发送了多少数据包，确认了多少数据包，所以我说这个墙是无状态的说法，应该是极其不正确的。

大佬您的研究拜读完了，小白一知半解的想问问大佬有没有应对方法。 我遇到的状况如下：河南联通 PT下载 5个站 5个tracker域名 A/B/C/D/E （B不是CFIP 其他均是） 1：群晖ssh开启net.ipv4.tcp_timestamps=1 A和C的种子过一会就直接无法连接 curl-v去测A和C没有任何回报信息且 ping也不通 偶尔ping能通一下 curl-v依然无任何回报信息
2：群晖ssh关闭net.ipv4.tcp_timestamps=0 A和C的种子会慢慢恢复 此时B的种子开始速度很快的无法连接 （B不是CFIP）此时ssh再开启net.ipv4.tcp_timestamps=1 重新汇报B的种子很快就全好
3：关闭net.ipv4.tcp_timestamps=0的情况下 B的地址去curl-v 握手2次后提示OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 此时ssh开启timestamps=1 再次curl-v B的地址 瞬间得到完整回报信息
4：期间D/E均是CFIP的tracker无任何问题不受任何影响
实在被这墙搞的头晕目眩了，开了timestamps=1 2个站不行 关了timestamps=0 1个站不行 看看大佬这边有没有小白能浅显易懂的解决方案 在这里真的谢谢了

我觉得问题主要出在联通到CF速度挺慢的这上面。Linux系统默认都是开启TCP Timestamps的，很难想象开启这个选项居然会导致无法访问两个原本可以访问的网站。 你说的那个A和C的奇妙现象 大概率就是因为CF的IP速度很慢而已，而B就非常具有规律性，实际上这五个网站的现象值得参考的也就 B D E。 A和C不应该认为是墙导致的。 要我说也就B被墙了而已，其他四个域名都没被墙。 实际上只要你把域名发出来，我肯定可以告诉你 哪个域名在黑名单里面，哪个域名不在黑名单里。

忘记补充了 A和C网站 做任何CF优选IP HOST 都没用 改一条马上就废（没添加host之前 都是通的 HKG LAX都试过，速度很快） 只要写上host 马上ping可以通 只要用一次curl-v不通 之后ping也不通了 已经持续3天了

你如果不把域名发出来，我是没法做任何进一步的分析的。

[5e2t]

忘记补充了 A和C网站 做任何CF优选IP HOST 都没用 改一条马上就废（没添加host之前 都是通的 HKG LAX都试过，速度很快） 只要写上host 马上ping可以通 只要用一次curl-v不通 之后ping也不通了 已经持续3天了

首先 开启TCP timestamps 导致 网站无法访问，是绝对不可能出现的事情。

[5e2t]

忘记补充了 A和C网站 做任何CF优选IP HOST 都没用 改一条马上就废（没添加host之前 都是通的 HKG LAX都试过，速度很快） 只要写上host 马上ping可以通 只要用一次curl-v不通 之后ping也不通了 已经持续3天了

不能强行的认为所有的行为都跟 出现的现象有关系

[5e2t]

如果你不把域名发出来，就算你说的信息有价值我也不可能去分析的。

[Fangliding]

转成discussion了 issues区会被机器人转发太刷屏了

[5e2t]

河南数据流量网络的 SNI墙 会把 TLS1.3 kyber768Draft00 密钥交换 导致的 ClientHello 分片组合到一起。因此无论servername写在 第一个分片还是写在 第二个分片，都会收到RST。

而河南固定宽带网络的SNI墙 不会把 TLS1.3 kyber768Draft00 密钥交换 导致的 ClientHello 分片组合到一起。 因此河南固定宽带网络的SNI墙只能阻断 没有 TCP option的情况下，servername在第一个ClientHello分片里的流量。

如果开了TCP Fast Open，则河南数据流量网络的SNI墙 可以阻断 servername位于 syn包的 ClientHello 流量。无法阻断 servername位于TCP三次握手成功以后客户端发的第二个ClientHello分片（是三次握手成功以后客户端发的第一个数据包）里的流量。

[ZqinKing]

河南数据流量网络的 SNI墙 会把 TLS1.3 kyber768Draft00 密钥交换 导致的 ClientHello 分片组合到一起。因此无论servername写在 第一个分片还是写在 第二个分片，都会收到RST。

而河南固定宽带网络的SNI墙 不会把 TLS1.3 kyber768Draft00 密钥交换 导致的 ClientHello 分片组合到一起。 因此河南固定宽带网络的SNI墙只能阻断 没有 TCP option的情况下，servername在第一个ClientHello分片里的流量。

如果开了TCP Fast Open，则河南数据流量网络的SNI墙 可以阻断 servername位于 syn包的 ClientHello 流量。无法阻断 servername位于TCP三次握手成功以后客户端发的第二个ClientHello分片（是三次握手成功以后客户端发的第一个数据包）里的流量。

一般都是按包处理的，有状态链路下一般也就处理各自方向的首个负载报文。组包的代价太大了。

[5e2t]

即便ClientHello的扩展字段只有一个servername，且extension length不正确。河南的SNI墙也会给此流量发RST。
而出口GFW并不会给这种流量发RST。 即把代码中的www.eulogysthermas.com域名改成 www.google.com 并不会收到来自出口GFW的RST。

package main

import (
	"fmt"
	"net"
	"time"
)

func main() {
	s1 := append([]byte{00, 00, 00, 0x1b, 00, 0x19, 00, 00, 0x16}, []byte("www.eulogysthermas.com")...) 
	s2 := append([]byte{0x16, 0x03, 0x01, 0x02, 0x39, 0x01, 0x00, 0x02, 0x35, 0x03, 0x03, 0x6a, 0x53, 0x2a, 0x46, 0x47, 0x90, 0x9e, 0x72, 0xec, 0xf1, 0x81, 0xb3, 0xee, 0xd9, 0x5a, 0xee, 0x19, 0xe5, 0x8c, 0x6d, 0x7b, 0x5e, 0xda, 0x62, 0x17, 0xdf, 0x55, 0xe4, 0x25, 0x17, 0xeb, 0x31, 0x20, 0x45, 0x40, 0xb7, 0xcc, 0x0f, 0x7a, 0xf9, 0x92, 0x03, 0x0d, 0x4e, 0xb8, 0x81, 0x55, 0x4b, 0x16, 0x5f, 0x89, 0xe4, 0xbd, 0x8c, 0xe6, 0xcf, 0xc3, 0x04, 0x79, 0xac, 0x01, 0xac, 0xbe, 0x9d, 0xcd, 0, 2, 0x13, 0x01, 01, 00, 01, 0xcc}, s1...)
	server, err := net.Dial("tcp", "104.21.34.5:443")
	if err != nil {
		fmt.Println("err=", err)
		return
	}
	defer server.Close()
	server.Write(s2)
	time.Sleep(time.Second * 5)
}

[5e2t]

#3660
这个把clientHello分片以后在同一个数据包里面发送 的分片功能，能避免被出口GFW发RST，并不能避免被河南SNI墙发RST。

第一张图片的SNI在河南SNI黑名单里，不在出口GFW黑名单里，收到的RST是河南SNI墙发的。
第二张图片的SNI在出口GFW黑名单，不在河南SNI黑名单里，并未收到来自出口GFW的RST

[5e2t]

河南数据流量网络上的省墙会给 对谷歌IP 142.251.42.234 的syn握手包 发RST。 此IP本身已经处于出口GFW的空路由之下了。

[5e2t]

用HTTP连接反诈服务器页面时，省墙会给我发RST。真有意思啊

PS C:\Users\Administrator> curl http://106.74.25.198
curl: (56) Recv failure: Connection was reset