Open moranno opened 1 year ago
你好 @moranno 感谢你的反馈。但很遗憾,我们无法告诉你准确的答案,只能给出一些猜测以及建议。
我们欢迎你试试Restls的效果: 使用方法 服务端 客户端
Hello @moranno,
Thank you for your feedback. Unfortunately, we cannot give you an accurate answer and can only provide some guesses and suggestions.
We believe that in addition to domain allow/blocklists, the GFW also has IP allow/blocklists. If your VPS (or even your client IP) has been blocked before, your traffic may be subject to higher-level scrutiny. We do not know exactly what happened, but in this situation, the GFW may not hesitate to use methods with high false positive rates. The phenomenon you observed is difficult to draw a definitive conclusion.
Regarding the issue of shadow-tls being blocked, here are our guesses:
We cannot predict whether Restls has the same issue, but all of the above issues have been addressed in the latest version of Restls:
restls-script
mechanism for Restls to disrupt behavioral characteristics such as "TLS in TLS."We invite you to try the effectiveness of Restls:
@3andne 刚刚测试了restls tls12和tls13 两种配置,同样发生了和 https://github.com/ihciah/shadow-tls/issues/78 一模一样的阻断...
服务端使用了最新版shadowsocks rust:
./ss-server -s "127.0.0.1:8888" -k 2659d9f0-8d8a-4313-bffa-67194607a6b5 -m "chacha20-ietf-poly1305"
2023-03-15T05:33:41.683452664+00:00 INFO shadowsocks server 1.15.3 build 2023-03-12T16:41:55.182659561+00:00
2023-03-15T05:33:41.695856850+00:00 INFO shadowsocks tcp server listening on 127.0.0.1:8888, inbound address 127.0.0.1:8888
restls启动参数:
./restls -s "www.cloudflare.com" -l "0.0.0.0:4430" -p 2659d9f0-8d8a-4313-bffa-67194607a6b5 -f "127.0.0.1:8888" --script "200?100,400?100,1200?200<1,1100~300,1000~100<1,2500~500,1300~50,1300~50,100~1200"
2023-03-15T05:53:14.776740Z INFO Restls server started as www.cloudflare.com:443 on 0.0.0.0:4430, forwarding to 127.0.0.1:8888
2023-03-15T05:53:34.402576Z ERROR handshake failed: unexpected eof
clash meta配置:
- { name: testrestls, type: ss, server: 150.230.xx.xx, port: 4430, cipher: chacha20-ietf-poly1305, password: 2659d9f0-8d8a-4313-bffa-67194607a6b5, plugin: restls, plugin-opts: { host: "www.cloudflare.com", password: 2659d9f0-8d8a-4313-bffa-67194607a6b5, version-hint: "tls13", client-id: chrome } }
阻断截图:
请问这是ping吗?你在什么地方ping什么呢?ping是不是不能被代理呢?
请问这是ping吗?你在什么地方ping什么呢?ping是不是不能被代理呢?
是在我本地客户端ping安装有restls的vps 用ping测试是否发生了阻断(阻断的时候目标ip的通信完全被拦截3分钟)
应该是运营商/省墙级别的阻断,不是gfw。
截图是我只要尝试使用restls/shadowtls/reallity链接目标IP,目标ip就会被完全阻断3分钟。 这个情况大多发生电信运营商下
但使用自己域名的trojan/vless或vmess + tls则不会发生这样的阻断情况
我有一个猜测,但需要你帮忙核实一下,请问你可以更改你在墙内的主机的hosts吗?可否在你墙内的机器上将你要伪装的网站(例如cloudflare.com)解析为你的vps ip,然后在你墙内的机器上使用curl或wget或者浏览器去访问你的VPS,即cloudflare.com。多发几次请求,然后看看会不会出现同样的阻断。
我有一个猜测,但需要你帮忙核实一下,请问你可以更改你在墙内的主机的hosts吗?可否在你墙内的机器上将你要伪装的网站(例如cloudflare.com)解析为你的vps ip,然后在你墙内的机器上使用curl或wget或者浏览器去访问你的VPS,即cloudflare.com。多发几次请求,然后看看会不会出现同样的阻断。
今天测试了,使用浏览器同样发生了阻断,下面是测试过程:
下面是console的restls日志输出
./restls -s "www.cloudflare.com" -l "0.0.0.0:4430" -p 2659d9f0-8d8a-4313-bffa-67194607a6b5 -f "127.0.0.1:8888" --script "200?100,400?100,1200?200<1,1100~300,1000~100<1,2500~500,1300~50,1300~50,100~1200"
2023-03-16T02:16:43.631593Z INFO Restls server started as www.cloudflare.com:443 on 0.0.0.0:4430, forwarding to 127.0.0.1:8888
2023-03-16T02:17:13.836116Z ERROR handshake failed: unexpected eof //第一次使用clash meta尝试链接,下面是修改host后用浏览器访问www.cloudflare.com
2023-03-16T02:23:17.498180Z ERROR handshake failed: reject: incorrect session id, expect: [74, 46, 156, 242, 124, 77, 132, 171, 230, 75, 219, 104, 199, 123, 11, 204], actual [97, 206, 231, 29, 41, 192, 77, 213, 159, 176, 25, 189, 230, 70, 117, 39]
2023-03-16T02:23:17.508544Z ERROR handshake failed: reject: incorrect session id, expect: [130, 32, 124, 85, 250, 208, 189, 44, 91, 110, 104, 247, 175, 160, 54, 133], actual [162, 17, 39, 217, 163, 246, 188, 215, 255, 43, 183, 112, 171, 109, 147, 177]
2023-03-16T02:26:23.965291Z ERROR handshake failed: reject: incorrect session id, expect: [39, 252, 245, 101, 231, 173, 156, 82, 34, 229, 83, 252, 117, 188, 193, 239], actual [222, 253, 79, 239, 50, 46, 5, 87, 253, 26, 181, 138, 6, 226, 189, 181]
从你的log看得出来
3. 结合你所说的trojan可用,我们推测你遇到的墙会检查IP是否属于域名,如果不属于则进行阻断。
有点不解的是,墙如何检查IP是否属于域名呢?通过域名(反向)解析还是通过 TLS Client Hello 中是否包括 SNI 来进行判断?
如果是前者,那我把这个某个域名解析到这个IP;如果是后者,那是否能在TLS Client Hello指定发送SNI?
墙可以通过DNS确定IP和域名的关系。你不拥有一个域名的话是不可能将其解析到你的IP上的。
墙可以通过DNS确定IP和域名的关系。你不拥有一个域名的话是不可能将其解析到你的IP上的。
如果是通过dns来确定,那我应该可以在vps建一个正常的网站服务,然后配置目标域名为自己的域名来偷自己的tls链接...这就去试试这个方案。
@3andne @RPRX 基本上确定是墙针对某些IP段的新阻断手段,参考这些例子:https://note.lazzman.com:18084/doc/277/
墙可以通过DNS确定IP和域名的关系。你不拥有一个域名的话是不可能将其解析到你的IP上的。
https://github.com/XTLS/Xray-core/discussions/1772
类似现象也观察到了,推测当地ISP对一些黑IP的阻断
这是我在那边的情况描述:https://github.com/ihciah/shadow-tls/issues/78
restls暂时没有测试。
请 @3andne 也来看看?