The https://assets.gentoo.org/ is not working (stucks) in my network, that prevents assets such as tyrian.min.css from loading. Is there are any troubles with https or geographic restrictions? It reproduced only with https, http works. My network is located at Russian Federation, Bashkortostan Resp, Ufimsky District, rural locality Zubovo. Web provider — Ufanet. Reproducible: Always Steps to Reproduce: curl https://assets.gentoo.org/ It stucks untill timeout nslookup assets.gentoo.org Server: 192.168.88.1 Address: 192.168.88.1#53 Non-authoritative answer: assets.gentoo.org canonical name = 1739712465.rsc.cdn77.org. Name: 1739712465.rsc.cdn77.org Address: 37.19.202.38 Name: 1739712465.rsc.cdn77.org Address: 37.19.202.35 Name: 1739712465.rsc.cdn77.org Address: 2a02:6ea0:dd00::5 Name: 1739712465.rsc.cdn77.org Address: 2a02:6ea0:dd00::4
HTTPS://assets.gentoo.org seems to works with VPN. That's weird. Is there are any additional locks? How to diagnose it?
That site is hosted on a CDN, and we're not aware of any blocking performed by the CDN provider. Here's the complete list of the sites we distribute with that CDN provider (CDN77): https://assets.gentoo.org/ https://api.gentoo.org/ https://distfiles.gentoo.org/ https://devmanual.gentoo.org/ https://planet.gentoo.org/ - Are the others also not working for you? - Can you please provide a traceroute and/or mtr showing connectivity to assets.gentoo.org? - If the address seems to respond, can you please ALSO show the results of ping & "curl -Iv https://assets.gentoo.org"
Reva: also, the fact it resolves to 192.168.88.1 in your initial output tells us that your ISP might be messing with your traffic
Created attachment 784472 [details] 20220612-images-1.jpg user screenshot showing cURL trying to connect to: distfiles.gentoo.org, 195.181.175.49 - works assets.gentoo.org, 37.19.202.38, connection timeout assets.gentoo.org, 37.19.202.36, connection timeout api.gentoo.org, 37.19.202.38, truncated
Created attachment 784475 [details] 20220612-images-2.jpg user-submitted screenshot showing ping results to: devmanual.gentoo.org, 37.19.202.35, rtt 3.83ms, 1 packet, no packet loss api.gentoo.org, 37.19.202.39, rtt 3.104ms avg, 2 packets, no packet loss assets.gentoo.org, 37.19.202.36, rtt 4.66ms avg, 1 packets, no packet loss (assuming 2nd packet was lost by ctrl-c)
Created attachment 784478 [details] 20220612-images-3.jpg User submitted screenshot showing traceroutes. assets.gentoo.org, 37.19.202.38 api.gentoo.org, 37.19.202.39 devmanual.gentoo.org, 37.19.202.35 Seems weird how the latency drops at the end of the traceroute, when I'd expect it to continue to increase. Maybe the netblock 37.19.202.0/24 netblock is hijacked or re-routed at least within that user's ISP.
Created attachment 784481 [details] 20220612-images-4.jpg user submitted screenshot showing traceroute to distfiles.gentoo.org that resolves to 195.181.175.49, and shows higher latency than the other endpoints
For anybody affected here: CDN77, the CDN provider, has diagnosed the issue as specific to some ISPs in Russia. Further response: ==== According to the latest censorship reports, Russia tends to block a large number of websites, sometimes at random. There are a lot of methods being used to block the access and the blocks are done separately by the ISPs (not centralized). The behavior we see from your tests and traceroutes suggests that it’s likely done by timing out the session during TLS handshake. One of the options to get more information about the block would be using the following tool: https://ooni.org/install This way, we will get more information on the specific censorship method used by the specific ISP on the following URL: https://explorer.ooni.org/search?since=2022-05-14&until=2022-06-14&failure=false For the CDN resources assets.gentoo.org we decided to temporarily disable the Moscow POP, which should help with the accessibility in Russia, however this change will result in slightly higher latency. Please let us know, if the user will utilize the ooni tools, so we can get further information regarding the block. === I'm going to ask them to disable the remaining Gentoo sites from the Moscow POP, because having the data available is more important than the latency
I've also disabled the relevant POPs for the remaining CDNs now.
Thank you, Robin Jonhson. I've confirmed gentoo site is working now like charm.
Sorry if I can't anwer on time.
