Hey @stefano,
Do you have anything to do with that I can't access https://media.bsd.cafe/ without a VPN?
=> More informations about this toot | More toots from sqrtminusone@bsd.cafe
@sqrtminusone Hi, no, everything's open here. Could you please tell me which IP is resolved with media.bsd.cafe from there? As I have some reverse proxies and would like to identify the one you're reaching
=> More informations about this toot | More toots from stefano@bsd.cafe
@stefano 142.132.143.181, it seems.
=> More informations about this toot | More toots from sqrtminusone@bsd.cafe
@sqrtminusone that host is working - it's the same I'm using from here. Maybe a problem at a backbone level. I've tried to redirect the connections to Poland now, the DNS propagation time is 5 minutes. Could you please try later and tell me if you can get there?
=> More informations about this toot | More toots from stefano@bsd.cafe
@stefano Nope, now it's 54.38.193.29, but still the same result. Very strange.
Maybe you're using the same provider for both servers? There are rumours that the censorship agency tests indiscriminate blocking of all IPs belonging to Hetzner since ~ November 2024, for instance.
Well, thanks for trying, anyway. I'll set up a proxy for myself unless the problem goes away somehow :-) And unless you have any other ideas, I guess.
=> More informations about this toot | More toots from sqrtminusone@bsd.cafe
@sqrtminusone no, it's a different provider (the first was Hetzner in Germany, the current is OVH in Poland). Can you try a traceroute to both the IPs?
Also, can you try with 5.78.104.52? This is in USA (but still Hetzner)
The BSD Cafe reverse proxy is also on Hetzner, I'm glad you can at least reach this - but finding a complete solution to give you full access would be great.
=> More informations about this toot | More toots from stefano@bsd.cafe
@stefano Both 142.132.143.181 and 5.78.104.52 make it only to the second hop:
1 192.168.2.1 1.280ms 0.754ms 0.851ms
2 5.19.0.94 12.032ms 5.19.0.90 6.236ms 5.19.0.94 3.016ms
3 * * *
...
64 * * *
The second IP is something belonging to my ISP.
5.78.104.52 works fine:
1 192.168.2.1 1.322ms 1.079ms 1.061ms
2 5.19.0.94 3.657ms 5.19.0.90 3.301ms 5.19.0.94 3.253ms
3 5.18.6.241 3.619ms 2.373ms 3.181ms
4 213.248.97.53 3.901ms 4.047ms 11.532ms
5 213.248.97.52 3.502ms 4.011ms 3.476ms
6 62.115.139.51 14.224ms 13.925ms 14.570ms
7 * 62.115.139.173 20.704ms 20.898ms
8 80.91.254.91 100.571ms 100.561ms 99.704ms
9 62.115.132.135 179.983ms 178.714ms 179.104ms
10 62.115.136.103 194.156ms * *
11 62.115.137.114 139.283ms 139.481ms 139.785ms
12 * * 62.115.139.112 168.040ms
13 62.115.139.111 162.889ms 162.127ms 166.749ms
14 62.115.115.25 175.966ms 179.202ms 175.247ms
15 62.115.112.45 179.456ms 178.703ms 178.625ms
16 80.239.132.87 176.343ms 175.487ms 176.984ms
17 5.78.0.78 176.112ms 176.550ms 175.543ms
18 * * *
19 5.78.11.164 183.497ms 179.989ms 183.389ms
20 5.78.104.52 193.758ms 192.857ms 192.602ms
=> More informations about this toot | More toots from sqrtminusone@bsd.cafe
@sqrtminusone ok, so the problem seems to be related to the ISP's routing.
Maybe you can force a local hosts file that will force the media.bsd.cafe resolution to the American IP that is working
=> More informations about this toot | More toots from stefano@bsd.cafe
@stefano Yes, it works that way :-) Thanks!
I really should learn more about networking at some point :D
=> More informations about this toot | More toots from sqrtminusone@bsd.cafe
@sqrtminusone I'm glad it works. I'll reset the old CDN for media later today, but this only works at DNS level so won't affect you
=> More informations about this toot | More toots from stefano@bsd.cafe
If I am reading that output correctly it completes the TCP handshake successfully and then times out during TLS handshake.
That makes me think it's possibly a PMTU problem. The traceroute output you shared had indications that ICMP might be blocked somewhere on the path, which is exactly the sort of misconfiguration which can break PMTU discovery.
The most efficient mitigation for such issues is to lower the advertised MSS. Do you know how to change the MSS in both directions? (I can explain how to do that on a Linux based router, but I don't know if that's what you are doing.)
A packet capture of the traffic might provide clues which could confirm or reject the hypothesis about a PMTU problem.
=> More informations about this toot | More toots from kasperd@westergaard.social
@kasperd @sqrtminusone Thanks for the hints!
=> More informations about this toot | More toots from stefano@bsd.cafe This content has been proxied by September (ba2dc).Proxy Information
text/gemini
