Cloudflare workers has blocked in iran

[Otisist]

Hello friends
Cloudflare workers are blocked in Iran! I enter the dns query of the worker's address, it is redirected to IP 10.10.34.36.
Is there a solution?

[markpash]

Confirmed on the Aria Shatel ISP:

$ drill @1.1.1.1 workers.dev
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25227
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; workers.dev. IN      A

;; ANSWER SECTION:
workers.dev.    418     IN      A       10.10.34.36

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 53 msec
;; SERVER: 1.1.1.1
;; WHEN: Sun Feb 26 22:24:44 2023
;; MSG SIZE  rcvd: 45

$ drill @8.8.8.8 workers.dev
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 12153
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; workers.dev. IN      A

;; ANSWER SECTION:
workers.dev.    418     IN      A       10.10.34.36

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 54 msec
;; SERVER: 8.8.8.8
;; WHEN: Sun Feb 26 22:24:46 2023
;; MSG SIZE  rcvd: 45

[Otisist]

Confirmed on the Aria Shatel ISP:

$ drill @1.1.1.1 workers.dev
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25227
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; workers.dev. IN      A

;; ANSWER SECTION:
workers.dev.    418     IN      A       10.10.34.36

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 53 msec
;; SERVER: 1.1.1.1
;; WHEN: Sun Feb 26 22:24:44 2023
;; MSG SIZE  rcvd: 45

$ drill @8.8.8.8 workers.dev
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 12153
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; workers.dev. IN      A

;; ANSWER SECTION:
workers.dev.    418     IN      A       10.10.34.36

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 54 msec
;; SERVER: 8.8.8.8
;; WHEN: Sun Feb 26 22:24:46 2023
;; MSG SIZE  rcvd: 45

I tested on MCI (TCI) ISP, Irancell ISP, Parsonline (hiweb) ISP and Aria Shatel ISP

[arandomgstring]

This domain https://workers.cloudflare.com/ works fine on TCI at the moment, tested on Chrome last stable version. As for workers.dev itself, well its IP 104.18.13.15 gives me ping response, therefore the censorship has not been done on IP level, that said, we are not dealing with a simple DNS poisoning either. Because after adding this IP address to host file, I can clearly observe that any TLS handshake will receive a RST response immediately, tearing apart the TCP connection.

Curl command curl workers.dev work fine though, it gives 301 response which is expected, and it means that they have especially blocked usual TLS handshake for some reason. I tried to use curl -L workers.dev to get into workers.cloudflare.com but it didn't work either. So it seems to me that SSL handshake on that particular IP is NOT possible, at the moment, and the only way to get around it is using a proxy.

[markpash]

This domain https://workers.cloudflare.com/ works fine on TCI at the moment, tested on Chrome last stable version. As for workers.dev itself, well its IP 104.18.13.15 gives me ping response, therefore the censorship has not been done on IP level, that said, we are not dealing with a simple DNS poisoning either. Because after adding this IP address to host file, I can clearly observe that any TLS handshake will receive a RST response immediately, tearing apart the TCP connection.

Curl command curl workers.dev work fine though, it gives 301 response which is expected, and it means that they have especially blocked usual TLS handshake for some reason. I tried to use curl -L workers.dev to get into workers.cloudflare.com but it didn't work either. So it seems to me that SSL handshake on that particular IP is possible, at the moment, and the only way to get around it is using a proxy.

When using curl and getting 301, are you using https? I have noticed often that a domain may be blocked with SNI on TLS, but plain HTTP working fine. Can you post the exact commands and results so that there's no doubt in your findings?

[Otisist]

Example:
check this domain : "ehehe.heheh.workers.dev"
I tried check with "check-host.net", all locations its ok, but Iran has return Private Network IP (10.10.34.36) also pinging on MCI,Irancell,Shatel,Parsonline,Hiweb ISPs return this IP. On Zitel ISP its ok, but about 75% is lost packet, actually not working or very very slow speed

Normally, the above domain is opened on port 443 of Welcome nginx page And if you have the correct configuration of vmess or vless or trojan, internally nginx will transfer your request to the correct port and the VPN will work.
In this scenario, the above domain is used in terms of not blocking the IP and the main domain of the server and high speed.
If you know other workers along with CDN that supports WebSocket and gRPC, I would be grateful if you could introduce them.

[arandomgstring]

@markpash

I have already written the very exact commands I used: curl workers.dev & curl -L workers.dev
the commands above are obviously a http requests (there is no https:// before workers.dev) which is why the first command works, and the second command tries to do a SSL handshake after http request and doesn't work, as expected. The picture from Wireshark comes from opening this website in Google Chrome (not curl request). Of course, I added the correct IP address of workers.dev in my host file, otherwise the successful TCP connection you see in the picture wouldn't take place. However, even after TCP handshake, TLS handshake fails immediately.

Therefore the findings were "IP of this website is not blocked (just ping it!: ping 104.18.13.15) however SSL handshake with this IP is not possible use a proxy". It seems that because of a typo I didn't type "not" before possible in my sentence, however, no madman will advise using a proxy when the website works fine without it. Moreover, I checked different client hellos in Wireshark to see if the blockage has something to do with TLS fingerprint. But regardless of TLS fingerprint, TCP connection is immediately severed after client hello, as you can see in the picture, so there is no way around it except using a proxy.

@Otisist
You can simply add these lines to host file
104.18.13.15 workers.dev
104.21.4.25 ehehe.heheh.workers.dev
To make your system use correct IP address every time you use that domain. That said, if it was simply DNS poisoning (that is, returning 10.10.34.36 fake IP address instead of true address 104.18.13.15), I could've already fixed it. But as you can see from my picture, they have blocked SSL handshake, so it is not possible to connect to this website (or its subdomains) without a proxy at all.

You can also use any method of encryption (e.g VMESS, Shadowsocket, etc) and use plain HTTP, instead of https, btw. Xray supports this: https://xtls.github.io/config/inbounds/http.html. At first I wanted to prevent you from using this method (because it can be detected), but then again even if you are detected, at most they will block the IP address of CDN. So who cares, right?

Another possible way to circumvent this is probably SSH Over Websocket kind of thing. So you send your requests through Websocket (to make it compatible with CDN) and encrypt it with SSH which doesn't need TLS handshake. NGINX will work as a reverse proxy and send your ssh request to the ssh socket of server. It will work, because the IP itself is not blocked and TCP connection works. But I have no experience when it comes to sending SSH requests through a Websocket.

[wkrp]

When using curl and getting 301, are you using https?

Thanks, I was going to ask the same question. My thinking was the that 301 redirect may not have been a typical HTTP→HTTPS redirect, but a redirect to 10.10.34.X injected by the firewall. The firewall in Iran certainly uses injected HTTP responses in some cases, but I have checked just now and the injected pages do not have status code 301; they have status code 403 and use an iframe, not a redirect. When HTTP injections happen, they look like this:

HTTP/1.1 403 ???

<html><head><meta http-equiv="Content-Type" content="text/html; charset=windows-1256"><title>AT2-9(2)</title></head><body><iframe src="http://10.10.34.35:80" style="width: 100%; height: 100%" scrolling="no" marginwidth="0" marginheight="0" frameborder="0" vspace="0" hspace="0"></iframe></body></html>

(The ??? is a part I'm not sure about.) You can see a similar iframe injection documented in 2014. OONI has a recent HTTP injection. Compare that to a recent DNS injection.

So I agree with @arandomgstring that the 301 response for HTTP indicates no blocking.