Xray-core
Xray-core copied to clipboard
XTLS
MCI is blocking REALITY servers in Iran
Discussed in https://github.com/XTLS/Xray-core/discussions/2450
Originally posted by WatchDogsDev August 16, 2023 Hi, First thanks for your great work. I had servers with clean IP using the recommended latest protocol VLESS+TCP+RPRX-VISION+REALITY for 2 month and everything was fine. Recently (about 4 days ago) the biggest internet operator in Iran known as MCI started blocking reality server IPs under 24 hours. I have used many less known server providers to get clean IP but it got blocked under 24 hours with around 70 users.
Any ideas how we can handle this? Or how is it detected ?
如果是 4 天前开始的广泛封锁，那么早就应该有报告，但目前除了 你们，并无其他人报告这个情况 GFW 当然在不断增强自己的能力，但若只封了你，基本上可以确定是和你自己的配置有关，至少你应当把配置贴上来 我们不喜欢被封后发贴不附上具体配置且标题为“XX 被识别了”的人，更不喜欢被这样的东西到处刷
但我暂时不会点 Close，看有没有更多报告
如果是 4 天前开始的广泛封锁，那么早就应该有报告，但目前除了 你们，并无其他人报告这个情况 GFW 当然在不断增强自己的能力，但若只封了你，基本上可以确定是和你自己的配置有关，至少你应当把配置贴上来 我们不喜欢被封后发贴不附上具体配置且标题为“XX 被识别了”的人，更不喜欢被这样的东西到处刷
但我暂时不会点 Close，看有没有更多报告
I'd say that to some extent he's talking right, not exactly about "REALITY being detected", but about the fact that they're failing to work in the recent days. the way that MCI had been blocking IPs before, was to limiting upstream to suspicious destinations, but now, they're interrupting downstream. so, if you perform an URL test, you see a success result ( as it's only a 204 response and small amount of bytes to transfer ). but when it comes to using the proxy, it fails to work.
The way that I'm testing my REALITY servers is to make an http request with 2 seconds timeout and check if it gets the response completely or not, as limited IPs have a long delay in receiving
curl -v --max-time 2 --resolve www.example.com:443:123.123.123.123 https://www.example.com
@SaintShit So how do isp determine illegal ip?
According to the list of legal IPs obtained from DNS？
https://github.com/XTLS/Xray-core/issues/2407
I've been using reality + Hiddify panel for 2 months without any ip bans!
but last 3-4 days, every day around 4 PM and 11 pm, my reality configs gets blocked but the ip still has ping + i can access it with nmap -p443 IP so i assume its TLS handshake Blocking and it only happens in one provider, MCI !
I use multiple SNI's, speedtest.net , www.theverge.com , cdn.discordapp.com and 2 more, that are whitelisted in MCI isp.
so after getting blocked 2nd day, i disabled speedtest sni and changed reality keys, cuz i thought they are banning ips based on that sni particularly but still i get banned and im so frustrated.
i'm using Linode VPS provider, their ips used to be whitelisted as it would work with any sni.
@SaintShit So how do isp determine illegal ip?
According to the list of legal IPs obtained from DNS？
#2407
maybe by the sudden traffic they get? seems that IPs that had REALITY running and they had been working for a long time, are not about to be limited. but about IPs that have recently become active in the network, there is a high chance that they'll be limited after a few hours. no matter which port or which SNI you're using.
I've been using reality + Hiddify panel for 2 months without any ip bans!
but last 3-4 days, every day around 4 PM and 11 pm, my reality configs gets blocked but the ip still has ping + i can access it with
nmap -p443 IPso i assume its TLS handshake Blocking and it only happens in one provider, MCI !I use multiple SNI's, speedtest.net , www.theverge.com , cdn.discordapp.com and 2 more, that are whitelisted in MCI isp.
so after getting blocked 2nd day, i disabled speedtest sni and changed reality keys, cuz i thought they are banning ips based on that sni particularly but still i get banned and im so frustrated.
i'm using Linode VPS provider, their ips used to be whitelisted as it would work with any sni.
Actually I've tested it and handshakes are all done, there's no problem with it
I am having the same issue. My reality servers are also getting blocked by MCI since 4 or 5 days ago. no matter what SNI i use or what flow to be set. even i tried to use different known ports, ... and no different. at the end of the day they are getting blocked.
I'd say that there are too many possible & available ways to recognize & block your proxy servers. We've discussed many of them here over the past few months (not on my subjective purpose), the problems that we can not solve yet, if you noticed.
maybe by the sudden traffic they get? seems that IPs that had REALITY running and they had been working for a long time, are not about to be limited. but about IPs that have recently become active in the network, there is a high chance that they'll be limited after a few hours. no matter which port or which SNI you're using.
Maybe it's the key.
ISP Unableed to detect Reality, only popular SNI has been blocked recently (www.speedtest.net), and only white SNI now is www.theverge.com and working on MCI. However, the question remains: how can we discover the whitelisted SNI?
@RPRX
seems that IPs that had REALITY running and they had been working for a long time, are not about to be limited. but about IPs that have recently become active in the network, there is a high chance that they'll be limited after a few hours. no matter which port or which SNI you're using.
Is there a possibility that the old IP is on the white list?So it can be used for a long time.
how can we discover the whitelisted SNI?
Use go http client to access sni and point to a random Web IP. If you can receive 403, it means that this sni maybe a whitelist.
If it was a widespread blockade that started 4 days ago, it should have been reported long ago, but no one else has reported this except you GFW is of course constantly increasing its own capabilities, but if it only blocks you, it is basically sure that it is It is related to your own configuration, at least you should post the configuration We don’t like people who post without specific configuration after being banned and the title is “XX is recognized”, and we don’t like being brushed around by such things
But I won't click Close for now to see if there are more reports
Just a quick update to let you know that I can confirm the recent happenings. In the past four days, MCI has been on a spree, closing down servers and throwing up IP blocks. And they're not holding back – we've even had cases where servers got the boot just a couple of hours after firing up, without any serious traffic.
Now, I've got a hunch this isn't your typical random IP-blocking gig from GFW. It seems like they've figured out a way to pinpoint those VPS servers that are actually in action, or maybe they've cracked the code on spotting real activity through SNI.
But here's the kicker – it's not just a wild goose chase. We've been hearing from folks all over the place, from different cities, and it's clear that this MCI onslaught is widespread.
Thank you, @nursery01, In our current scenario, we are utilizing www.theverge.com, which operates behind the Fastly CDN infrastructure. The associated IP address for this site is 151.101.41.91. I undertook a thorough comparison with other domains that share similar attributes, including SSL certificates and CDN IPs. However, it's noteworthy that my findings diverged from those observed with The Verge.
when we use The Verge with dirty IP it's working!
Guys I created this telegram group for Persian people to join and discuss the ways to connect https://t.me/howisuconnected
如果这次的封锁主要是基于流量特征，那么还有解决的余地，我们有一些计划。如果主要是基于 IP，比如说 MCI 已经将更多的 IP 列入了“不可轻信”名单，那么现有的协议解决不了，~~只能用一些魔法，但我不是很想用。~~
如果这次的封锁主要是基于流量特征，那么还有解决的余地，我们有一些计划。如果主要是基于 IP，比如说 MCI 已经将更多的 IP 列入了“不可轻信”名单，那么现有的协议解决不了，只能用一些魔法，但我不是很想用。
中國人做的代理百花齊放，如果站在中國gfw和伊朗isp的角度來看，成本比較低的方式就是升級基於ip的審查系統，並且ip很難造假後還能正常使用，如果是每個協定都識別過去還聽麻煩的
ISP Unableed to detect Reality, only popular SNI has been blocked recently (www.speedtest.net), and only white SNI now is
www.theverge.comand working on MCI. However, the question remains: how can we discover the whitelisted SNI?@RPRX
www.speedtest.net 是一个 Cloudflare 网站，后者的 IP 段似乎是公开的，想封它并不难。 你们那里能直接上 Google，我好像没有见过你们租谷歌云的服务器并使用 www.google.com 作为 dest？
www.speedtest.net 是一个 Cloudflare 网站，后者的 IP 段似乎是公开的，想封它并不难。 你们那里能直接上 Google，我好像没有见过你们租谷歌云的服务器并使用 www.google.com 作为 dest？
Google cloud services are completely blocked in Iran due to sanctions
ISP Unableed to detect Reality, only popular SNI has been blocked recently (www.speedtest.net), and only white SNI now is
www.theverge.comand working on MCI. However, the question remains: how can we discover the whitelisted SNI?@RPRX
That's interesting, so I'm thinking of that they have both IP and SNI whitelist.
I just made a quick test with a server that it's IP had been limited 2 days ago
{
"listen": "0.0.0.0",
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "57fd57d8-2a52-4315-8bc2-ab01dcd06168",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"dest": 9443,
"xver": 1,
"serverNames": [
"www.speedtest.net",
"www.theverge.com"
],
"privateKey": "aLdhim1sD8StYH88yLGGtV7Ew9eTS7G6ayuxrBG_Wmg",
"shortIds": [
""
]
}
}
}
haproxy.cfg:
defaults
mode tcp
timeout client 30s
timeout connect 4s
timeout server 30s
frontend tls_handshake_front
bind *:9443 ssl crt /self-signed.crt accept-proxy
mode http
http-request return status 204
so it accepts both www.speedtest.net and www.theverge.com, and requests with first SNI has no downstream. second one, works great.
If this blockade is mainly based on traffic characteristics, then there is still room for resolution, and we have some plans. If it is mainly based on IP, for example, MCI has included more IPs in the list of "not to be trusted", then the existing agreement cannot solve it.~Can only use some magic, but I don't really want to use it.~
Just wanted to shed some more light on this situation. Fired up a couple of brand-new VPS servers with clean IPs, and just to be extra safe, I threw in a CDN certificate for good measure. And to top it off, I went ahead and blocked all IR domains and IPs directly on the server.
No big traffic spikes here, just a handful of small video files being sent back and forth for a legit speed test. And to keep things interesting, I've got the VPN running on a couple of devices as well.
Rest assured, all the devices are locked down tight. Our client apps and software are up-to-date and set up perfectly. I've only used "Reality" on 443 port and I've got us covered with whitelisted SNI, and I've gone the extra mile to implement every possible security measure to the best of my understanding.
Out of the three VPS instances, one got the Blocked within just 4 hours, while the other two managed to hold on for about a day before they were also blocked.
The second and third VPS instances started acting up with erratic and unusually high ping, causing a significant slowdown in speed. After a few hours of this instability, they eventually ended up completely blocked. It's starting to look like a potential DDoS attack on the servers.
I hope the information above sheds some light on the subject.
Iran's GFW is indeed upgraded. it's now detecting actively blocking reality/tls/xtls/tcp IP addresses.
https://twitter.com/AminAnvary/status/1691575510436909122
In recent days, widespread reports have emerged regarding MCCI's swift blocking of Reality-based VPNs within just hours and with minimal traffic. Additionally, even WS + TLS VPNs utilizing CDNs like Cloudflare are struggling to maintain functionality. This holds true even for domestic CDNs such as Arvan Cloud, which typically enjoy access to a less restricted Internet environment.
Here are a few observations I've made:
According to Netreach, connectivity to previously unrestricted websites remains unchanged. This suggests that the new system is adept at pinpointing specific protocols rather than causing widespread disruption.
The commonly used SNI for Reality connections among Iranian users, specifically speedtest.net, is encountering difficulties. However, some of these issues are resolved by switching to new SNIs.
Irancell, another major provider, still supports the use of WS + TLS via the Arvan Cloud CDN. This implies that the breakdown of WS + TLS connections on MCCI could be linked to the connection between the user's device and the CDN's servers. It's important to note that direct WS + TLS connections have been noticeably unstable over the past six months.
Looking ahead, the question arises: what are our next steps? As this new system expands to encompass all major providers in Iran, our options may become increasingly limited. Relying on a domestic relay, be it a CDN or server, was typically considered a last-resort solution to circumvent censorship.
Stay informed @RPRX
Just an Update
These serverless methods continue to function with MCI.
✔️ Workers + Fragment
✔️ Warp app by changing endpoints IP
Here's an example of what I'm currently using. The ping seems fine, but I've observed occasional stutters and lag during data transfer and while using certain apps.
ServerLess_TLSFrag_Xray_Config.txt
Special thanks to Ali/dxdydz for coming up with the solution.
@RPRX Here is a sample of server configuration with coinmarketcap.com sni. I have also servers using discord.com / github.com / canva.com / brave.com etc.
{
"listen": "0.0.0.0",
"port": 18299, // Random port
"protocol": "vless",
"settings": {
"clients": [
{
"id": "some-uuid",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "coinmarketcap.com:443",
"xver": 0,
"serverNames": [
"coinmarketcap.com"
],
"privateKey": "some-x25519-private-key",
"publicKey": "some-x25519-public-key",
"minClientVer": "",
"maxClientVer": "",
"maxTimeDiff": 0,
"shortIds": [
"da793ad1bf"
]
}
}
}
And here is the sample client config :
vless://[email protected]:18299?type=tcp&security=reality&flow=xtls-rprx-vision&fp=chrome&sni=coinmarketcap.com&pbk=some-public-key&sid=da793ad1bf#Client
The IR regime definitely upgraded their internet restriction system, since a week ago my REALITY servers stopped working one by one!
It seems they have shifted from "blocking" methods to "throttling", leaving the server open to SSH and every connection but significantly throttled and prone to high packet loss and it is exhibited on all ISPs not just MCI.
Here's a bandwidth test to one of my detected servers with iperf3 in TCP mode:
Client:
[ 5] local 192.168.1.100 port 33362 connected to X.X.X.X port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 70.7 KBytes 579 Kbits/sec 2 1.36 KBytes
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.36 KBytes
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 1 1.36 KBytes
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.36 KBytes
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.36 KBytes
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.36 KBytes
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 1 1.36 KBytes
[ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 1.36 KBytes
[ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.36 KBytes
^C[ 5] 10.00-212.77 sec 0.00 Bytes 0.00 bits/sec 0 21.8 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-212.77 sec 70.7 KBytes 2.72 Kbits/sec 5 sender
[ 5] 0.00-212.77 sec 0.00 Bytes 0.00 bits/sec receiver
Server:
Accepted connection from Y.Y.Y.Y, port 33360
[ 5] local X.X.X.X port 5201 connected to Y.Y.Y.Y port 33362
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 8.16 KBytes 66.8 Kbits/sec
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 10.00-10.13 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.13 sec 8.16 KBytes 6.60 Kbits/sec receiver
As shown above, only a few KBytes of data reached the server in 6Kbits/sec! Changing the port does not change the result.
And here's the same test with UDP:
[ 5] local 192.168.1.100 port 60358 connected to X.X.X.X port 5201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 129 KBytes 1.06 Mbits/sec 95
[ 5] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 94
[ 5] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 94
[ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 94
[ 5] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 94
[ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 94
[ 5] 6.00-7.00 sec 129 KBytes 1.06 Mbits/sec 95
[ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 94
[ 5] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 94
[ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 94
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.000 ms 0/942 (0%) sender
[ 5] 0.00-10.77 sec 302 KBytes 229 Kbits/sec 5.572 ms 715/937 (76%) receiver
Only 300Kb of a total of 1Mb data reached the server resulting in a whooping 76% data loss, and sometimes it even reaches 96%!
Detection methods are still a mystery, maybe it's amount total data sent and received over a certain time range (one of my servers was detected after two days with only 16GB of data transfer) or maybe the have implemented a SNI vs. IP verification check, and they purposefully keep a rotating SNI whitelist to minimize further collateral damage to the IT businesses or keep a certain demography connected (government bodies, state actors, trusted entities or others who are kept in the loop with the whitelist changes, not sure just a theory!) and we get lucky to find one.
A few observations so far:
- [.ir] SNIs and SNIs that are hosted on the Iranian INTRANET did not work for me.
- SNIs with certain keywords such
cdndo not work or result in a swift detection of the server. - SNIs that are hosted on the same network subnet as the server did not help in bypassing this throttling.
It's possible that these solutions and suggestions could offer some help!
If you decide to try any of these options, please consider sharing your results and data with us. This way, we can gain a clearer understanding of the situation at hand.
如果这次的封锁主要是基于流量特征，那么还有解决的余地，我们有一些计划。如果主要是基于 IP，比如说 MCI 已经将更多的 IP 列入了“不可轻信”名单，那么现有的协议解决不了，~只能用一些魔法，但我不是很想用。~
I have a strong hunch that it's mainly based on traffic characteristics. Here is some of the evidence:
- According to Netreach, connection to previously unrestricted websites is unchanged. This probably means the new system is good at detecting VPNs, not just sending blind noise to disrupt all connections.
- Users who take advantage of domestic servers as relays for their Reality VPNs are also experiencing this. Since the new system is only deployed on MCCI, I guess they should be using some traffic characteristics.
- IPs that stopped working with
speeedtest.netSNI often work with other new SNIs (such aswww.theverge.com). However, I'm not sure if changing the SNI would reduce the chance of detection or not.
See here: https://github.com/net4people/bbs/issues/277
Update - Thu 17 Aug - 13:50
Multiple reports from various locations across Iran indicate a common issue: encountering notable throttling, severe disruption, and substantial fluctuations on different ISPs. This scenario strongly suggests the possibility of a coordinated attack, potentially orchestrated by MCI.
We speculate that the recent events and peculiar behavior exhibited by ISPs in Iran could be indicative of some form of preparation or demonstration of power, potentially in anticipation of the upcoming commemoration of Mahsa Amini and other brave individuals who tragically killed and murdered during last year's uprising against the dictatorial regime.
As a wise man once said: "We can never forget that no matter how much it hurts, how dark it gets, or how far we fall, we are never out of the fight." ✌🏾
One more observations is that, once a server is detected, changing the SNI, the shortIDs, or uTLS fingerprints is useless! You have to wait out a period of 2~3 days, then limits are partially lifted, meaning you can try a new working SNI.
I observed this experimenting with my servers, server A and B were running with the same SNI, server A was detected and throttled while server B was working flawlessly (server B had far less data transmitted and occasionally used)!
Until we can figure out the detection methods, we're shooting in the dark...
Recent reports have surfaced, indicating that specific individuals have received warning messages from domestic VPS providers. These notifications inform them that their VPS IP addresses have been blocked due to the detection of VPN or proxy services on their servers. Additionally, they are advised not to generate any traffic for the next 72 hours.
Here some an example of warning messages
Has anyone else encountered the same problem?