Replies: 20 comments
-
Another experiment with the URL that my tester tried:
|
Beta Was this translation helpful? Give feedback.
-
I'll look into it. can you please also share the |
Beta Was this translation helpful? Give feedback.
-
sniproxy.log I got this with How do I get more verbose logs? |
Beta Was this translation helpful? Give feedback.
-
so there are a few interesting bits here..
|
Beta Was this translation helpful? Give feedback.
-
if you're keen to test the experimental
|
Beta Was this translation helpful? Give feedback.
-
I created another Vultr instance (
Forcing ipv4:
This actually seems to be a A more interesting problem is perhaps the google career website which loads from sniproxy in Paris, but 403's from Tehran: Experiment A1) Vultr instance in Paris:
Experiment A2) IR machine in a data center with its DNS set to the Vultr instance:
Note the IP address that google.com resolves: Experiment A3) From a NY machine, I am actually able to set my DNS to the sniproxy and wget the google career page with the correct IP:
So the problem seems to be that in my IR machine, somehow wget is not resolving via sniproxy. I suspect that Iran Telecom is intercepting the DNS request and replacing it with their own IP ( |
Beta Was this translation helpful? Give feedback.
-
looks like your DNS is not working properly. how are you setting your DNS? use |
Beta Was this translation helpful? Give feedback.
-
I'm setting the DNS by changing
Starting with
dig on my Tehran machine:
That corroborates the logs: However:
And I think it's because wget is not using the system DNS, as it's resolving into Now, when I dig google.com, I get that IP:
On sniproxy:
I think
WDYT? |
Beta Was this translation helpful? Give feedback.
-
Ah!! It's Iran enforcing safesearch: https://support.opendns.com/hc/en-us/articles/227986807-How-to-Enforcing-Google-SafeSearch-YouTube-and-Bing
|
Beta Was this translation helpful? Give feedback.
-
two things:
this disables the stub listener, and changes your DNS to 217.69.9.127. replace it with the current public IP of
this will bypass DNS altogether so you can test where the issue is. If editing there is a neat way to avoid having DNS query and response altogether using another pet project of mine here. This sets up a "fake" DNS server in your own machine, so you can hard-code your
if fakedns is not in your PATH, you'll get a hopefully this helps. |
Beta Was this translation helpful? Give feedback.
-
Thank you @mosajjal for the instructions on changing DNS and bypassing the safesearch DNS rewrite. Some progress but not quite there: I added
On the sniproxy machine itself, And when on my Tehran machine, I just go to .../apply, I get stuck again:
Server logs are as follows for
And for
So it looks sniproxy is not handling 301 moves (redirects)? |
Beta Was this translation helpful? Give feedback.
-
so this confirms that but obviously this won't be a long-term solution since you have to literally add every single FQDN to my suggestion for you is to use if that doesn't work or it's too hard to implement or the performance is too slow (possible since I haven't actually tested |
Beta Was this translation helpful? Give feedback.
-
Actually,
Logs from IR machine failing to
sniproxy logs indicate that the accounts.google.com call does reach the proxy:
Logs from a machine in the same provider as the sniproxy (Vultr) with its DNS set to the sniproxy succeeds:
Thanks for the hints on |
Beta Was this translation helpful? Give feedback.
-
yeah you might be onto something. looks like something new in the midboxes that block a legitimate TLS connection. have you tried setting |
Beta Was this translation helpful? Give feedback.
-
as my experience on vultr services, we need to start cloudflare warp on vultr vps, then route the traffics from specific sites into cloudflare warp connection. for example i had a problem while usuing chat.openai.com, installed warp-go created by chinese developer, then route traffics from openai.com site to cloudflare warp app instead of default main network on vultr vps. i wish we had a speech as persian language 👯 |
Beta Was this translation helpful? Give feedback.
-
I tried the same experiment on a Chrome browser running on a Windows server machine in IR and got pretty much the same results. ERR_TIMED_OUT on the browser, and windows wget both times out. Do you have benchmark experiments or probers running in Iran or plans to have them in the future? That would show whether this problem is local to my setup or not. Would be happy to help test out the proxy in the future using my IR nodes. Thank you for helping with this issue so far. ✌️ |
Beta Was this translation helpful? Give feedback.
-
assuming WARP overrides the fake IP that the reason that Farsi is not used here is the fact that other countries also use the proxy for different purposes and it'd be good to include everyone into these conversations. Farsi limits the amount of people that can read the comments and discussions. |
Beta Was this translation helpful? Give feedback.
-
I think we identified the root cause didn't we? the DNS looks to be the culprit. you can potentially run a |
Beta Was this translation helpful? Give feedback.
-
I had exact same issue with my DNS server which provided by sniproxy. |
Beta Was this translation helpful? Give feedback.
-
since this doesn't look like a bug in |
Beta Was this translation helpful? Give feedback.
-
Hi @mosajjal,
I was helping someone from Iran access a google domain website and they reported to me that they are getting 403, even after setting their DNS to the sni proxy I have in Vultr.
My experiment confirms that: I setup a fresh instance of sniproxy in Vultr. Now from my machine outside Iran, websties like udemy.com do load after setting DNS to my sniproxy, but when I experiment with a datacenter in Iran, I get the 403 back:
209.250.255.214
from Iran:The original website that my tester was trying to access was a google domain, but I figured if we solve it for udemy.com it will be solved for other websites too.
Is this expected behavior?
Beta Was this translation helpful? Give feedback.
All reactions