-
|
大家好。 伊朗防火墙最近在一家主要移动运营商上启用了基于 SNI 的过滤。 在一些流行的 VPS 提供商上，干净的 IP 没有任何限制，几乎所有流行的协议都全速工作。 我在这里谈论的是干净的 IP，重点不在于哪个协议首先被阻止。 但是，如果您的服务器的干净 IP 来自不太知名的提供商，您将遇到上传速度限制问题。 例如，使用干净的Hetzner IP，没有问题，但是使用小型VPS提供商提供的干净IP，就会出现一些问题。 SSH 上传和下载速度非常快。 但是，如果您仅使用 speedtest.net 作为 SNI，则可以绕过上传速度限制。 使用 vmess/vless TCP + HTTP 标头时也是如此。 除非使用 speedtest.net 作为标头，否则上传速度接近于零。 其他协议（例如 Stealth openvpn）都可以。 再次，如果我使用与现实不同的协议，服务器的IP地址将很快被封锁。 所以我的问题是防火墙如何区分其他 SNI 上的合法流量和假 Xray 流量？ 我们该如何解决这个问题呢？ 最后但并非最不重要的一点是，许多伊朗用户在 Twitter 上报告了这个问题，并且不限于我的情况。 Hi everyone. Iran firewall has recently enabled SNI-based filtering on a major mobile operator. On some popular VPS providers clean IPs there is no restriction and almost all popular protocols work at full speed. I'm talking about clean IP here and the point is not which protocol gets blocked first. However if your server's clean IP is from a less known provider you will run into upload speed limit issues. For instance, with a clean Hetzner IP, there is no problem, but with a clean IP provided by a small VPS provider, there are some problems. SSH speed is very fast for upload and download. However, if you use reality only with speedtest.net as your SNI, you can bypass the upload speed limit. The same applies when using the vmess/vless TCP + HTTP headers. Unless speedtest.net is used as a header the upload speed is close to zero. Other protocols such as stealth openvpn are fine. Once again, if I use another protocol than reality, the server's IP address will be blocked quickly. So my question is how the firewall distinguishes between legit traffic on other SNIs and fake Xray ones? And how can we solve this issue? Last but not least this issue has been reported by many Iranian users on Twitter and is not limited to my case. |
Beta Was this translation helpful? Give feedback.
Replies: 9 comments 23 replies
-
|
This is exactly what we are facing for several months. I have server that is been running with reality 3 months and never got blocked, but I'm sure if I was going to use anything other than vless-xtls-reality it would be blocked withing few days. |
Beta Was this translation helpful? Give feedback.
-
|
令我印象深刻的是 @dragonfly20004 的反馈 #2162 (comment) ，它表明伊朗甚至针对流量特征启用了“准白名单”机制：不符合就限速 我不知道你的 REALITY 承载的是 Vision 还是 H2 / gRPC，但目前它们的流量特征都不符合纯粹的 HTTPS，我猜被限速可能与此有关 （当然你提到的“干净 IP 来自不太知名的提供商”会被限速，我觉得即使 GFW 没有能力实时同步所有域名的所有 IP，GFW 至少有能力查出你这个小众 IP 段不可能有某个知名网站，这个事情我也不是第一次说了，但你可选 IP 范围受限，这个问题难以解决，所以还是聊流量特征吧） 我们的应对方案是启用 Seed、加新 Flow：#1295 (comment) 、#1567 (comment) 关于新 Flow，它肯定需要某种编码格式，所以我说的 计划 其实是 把上述混淆功能直接做给 Mux，并给 VLESS 加一个（暂定）名为 所以当我预告 Mux 的编码格式是很有潜力的，比如 4.16 我就写了它本身就能 padding 并预留了兼容，而“把上述混淆功能直接做给 Mux”的好处如下：
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
楼主反映的问题是不是用 naive 能解决？ |
Beta Was this translation helpful? Give feedback.
-
不能。首先伊朗是 SNI 白名单模式，Naive 不好使；其次 Naive 的流量特征同样不符合纯粹的 HTTPS，可以被区分；最后我们并不确定这个是不是流量特征的问题，因为还有可能就是简单的“GFW 至少有能力查出你这个小众 IP 段不可能有某个知名网站”。 |
Beta Was this translation helpful? Give feedback.
-
|
有一个设想。审查者设计一个连接数窗口，超过窗口大小就暂时阻断端口。如果找到了合适的窗口大小与时间，是不是可以精准阻断switch流量？ |
Beta Was this translation helpful? Give feedback.
-
@hiddify1 🤔 |
Beta Was this translation helpful? Give feedback.
-
I can give you AnyDesk and you do the necessary tests for a better conclusion |
Beta Was this translation helpful? Give feedback.
-
那么出现了一种新的可能：你的运营商只是简单粗暴地针对这个 IP 段限速，它与 IP 解析、流量特征均无关，但豁免了 speedtest.net 请直接用浏览器访问目标网站，找到一个有上传功能的，测一下上传速度（ |
Beta Was this translation helpful? Give feedback.
-
|
As I mentioned at the start of this discussion, There is no upload speed issue if I use SSH tuneling or openvpn to connect to my vps, instead of Xray/V2ray. Finding a website on the same ip range that lets me test the upload speed, may be a bit troublesome. May I know about the other method? Can I use a upload html script or something like that? ( please mention the name if you know any good ones). Kind regards |
Beta Was this translation helpful? Give feedback.
-
|
I managed to test the server upload speed with iperf tcp and the result is very slow upload. But After testing with ssh tunnel again there is no upload issue. So Maybe this a limit on tcp http? |
Beta Was this translation helpful? Give feedback.
-
抱歉没表述清楚，我的意思是它可能是针对这个 IP 段的所有 TLS 限速，但豁免了 speedtest.net
可以在一条 H2 内上传很多垃圾数据，然后发一个正常请求，看看多久有回应（可能没有现成工具，需要写代码） 另一个方法是使用自己的域名，虽然它在一段时间后会被封，但被封前的时间已足够测试 DNS 解析与你的 IP 相同时是否会被限速
当然，我知道。我们研究你面临的问题，成果可以帮助到其他人。 |
Beta Was this translation helpful? Give feedback.
-
是的，很显然它区别对待了不同的协议，目前我们需要研究它对于这个 IP 段的 TLS 是无脑限速，还是与 DNS 解析值或流量特征有关 |
Beta Was this translation helpful? Give feedback.
-
谢谢回复。 我很期待新的流程更新。 如果您有任何其他建议，我很乐意测试它们。 亲切的问候 编辑：我刚刚看到你的新回复，我会尝试你的建议。 谢谢 |
Beta Was this translation helpful? Give feedback.
-
|
linehman wrote:
Because you configured the dest in server side config to be on "www.speedtest.net" in your server settings, that is why it is shown in the RealiTLScanner. If you configured any other site, it would show that site in the server IP RealiTLScanner. |
Beta Was this translation helpful? Give feedback.
-
|
I see, But this was on another ip in the same range of my ip address, not my own IP. So maybe another user is on that ip and running xray reality with speedtest.net as destination. |
Beta Was this translation helpful? Give feedback.
-
|
Me and some other people have done some tests about this issue and here is our findings:
TL;DR: There seems to be some sort of IP whitelist that if your server receives traffic from inside of Iran and not get blocked after a while its IP would get whitelisted and you get good upload speeds with it no matter the SNI. All of the above was about the MCI (Hamrahe Aval) network and not other networks. |
Beta Was this translation helpful? Give feedback.
-
|
我觉得你提供的这些信息非常有用 题外话：我在 main 分支重构了 TCP、TLS 分片的代码，使逻辑更清晰，麻烦测试一下它们能否正常工作 |
Beta Was this translation helpful? Give feedback.
-
I have tested it using one of GH actions binaries and it seems to work for bypassing SNI censorship without foreign server👍 |
Beta Was this translation helpful? Give feedback.
-
感谢你的测试，两种分片都没有问题吗 |
Beta Was this translation helpful? Give feedback.
-
If you mean the two modes (tlshello and segmentation) I have found that tlshello works with youtube and you can set it to 1 byte packets whereas segmentation with length 1 byte will not work with youtube it maybe the google's servers rejecting the non tls packets as my initial code couldn't bypass youtube's censorship either. I have also tested the blocked websites behind cloudflare (clubhouse.com) and they both work with tlshello and segmentation with 1 byte lengths. |
Beta Was this translation helpful? Give feedback.
-
|
@hiddify1 |
Beta Was this translation helpful? Give feedback.
-
|
try interval 110
…On Fri, Jul 7, 2023 at 11:42 AM sambali9 ***@***.***> wrote:
If you mean the two modes (tlshello and segmentation) I have found that
tlshello works with youtube and you can set it to 1 byte packets whereas
segmentation with length 1 byte will not work with youtube it maybe the
google's servers rejecting the non tls packets as my initial code couldn't
bypass youtube's censorship either. I have also tested the blocked websites
behind cloudflare (clubhouse.com) and they both work with tlshello and
segmentation with 1 byte lengths.
"fragment": {
"length": "1",
"interval": "20-30",
"packets": "tlshello" // I changed this between 1 and tlshello
}
—
Reply to this email directly, view it on GitHub
<#2281 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMS2NGNY3B74NLB22G27O4DXO7AHXANCNFSM6AAAAAAZ2YLSCM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
令我印象深刻的是 @dragonfly20004 的反馈 #2162 (comment) ，它表明伊朗甚至针对流量特征启用了“准白名单”机制：不符合就限速
我不知道你的 REALITY 承载的是 Vision 还是 H2 / gRPC，但目前它们的流量特征都不符合纯粹的 HTTPS，我猜被限速可能与此有关
（当然你提到的“干净 IP 来自不太知名的提供商”会被限速，我觉得即使 GFW 没有能力实时同步所有域名的所有 IP，GFW 至少有能力查出你这个小众 IP 段不可能有某个知名网站，这个事情我也不是第一次说了，但你可选 IP 范围受限，这个问题难以解决，所以还是聊流量特征吧）
我们的应对方案是启用 Seed、加新 Flow：#1295 (comment) 、#1567 (comment)
关于新 Flow，它肯定需要某种编码格式，所以我说的 计划 其实是 把上述混淆功能直接做给 Mux，并给 VLESS 加一个（暂定）名为
mux-controller的新 Flow，它的具体配置作为 Seed，客户端必须发给服务端以供检查，因为服务端应能决定客户端发流量的特征所以当我预告
xtls-rprx-switch时，我说的是“下一个 XTLS 流控”，而不是“下一个 VLESS 流控”（v1.8.5 暂定是继续改 Vision、启用 Seed）Mux 的编码格式是很有潜力的，比如 4.16 我就写了它本身就能 padding 并预留了兼容，而“把上述混淆功能直接做给 Mux”的好处如下：