Hello *,

I have problems opening several sites

gentoo.org
wiki.gentoo.org
devmanual.gentoo.org
(but not packages.gentoo.org, forums.gentoo.org)

from my gentoo notebook in Novosibirsk, Russia. All these sites have an excellent ping; the problem is only to access them via https. First I wait
for several minutes; then either the browser (chrome) declares timeout, or
the site opend, but without the top menu, the background picture below the menu. Instead I get the menu as a plain vertical list of lines, each line contains a link. These links work. But if I choose, e.g., the link
Support, I again have to wait for many minutes for gentoo.org/support/ to
load.

This is clearly related to me being in Russia. When I go to the same sites
from chrome on my android tablet, and this tablet is connected by vpn to a
vps in Germany, everything works fast and without defects. Unfortunately,
I have no client compatible with this vpn on my gentoo notebook.

Seems to be some effects of Russian internet blocking (though I see no political reasons to block gentoo.org; it is not in the official list of
sites blocked in Russia).

Is it possible to investigate this problem further? Maybe, some css styles
are taken from some places blocked (nobody knows why) in Russia?

It's all very inconvenient.
Andrey

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-14, Robin H. Johnson wrote:

On Wed, May 14, 2025 at 01:48:37PM +0000, Andrey Grozin wrote:

Hello *,

I have problems opening several sites

gentoo.org
wiki.gentoo.org
devmanual.gentoo.org
(but not packages.gentoo.org, forums.gentoo.org)

As an A/B comparision, this is a good starting point.

What the sets have as a common difference is loading JS & CSS from assets.gentoo.org.

From assets.g.o:
- Packages loads a single image.
- forums loads nothing.
- www, wiki, devmanual: loads bootstrap, jquery, CSS, fonts.

from my gentoo notebook in Novosibirsk, Russia. All these sites have an
excellent ping; the problem is only to access them via https. First I wait >> for several minutes; then either the browser (chrome) declares timeout, or >> the site opend, but without the top menu, the background picture below the >> menu. Instead I get the menu as a plain vertical list of lines, each line
contains a link. These links work. But if I choose, e.g., the link Support, >> I again have to wait for many minutes for gentoo.org/support/ to load.

- Use Chrome devtools while loading one of the pages, and identify which
requests are slow
- Copy that request from devtools "copy as curl"
- Repeat it in the shell
- Test if dropping headers etc changes the behavior.

The "excellent ping" comment stands out as odd - from Russia, I would
expect a poor ping to wiki.g.o and forums.go, because they are NOT on
the CDN.

All of the others are on CDN: assets, packages, devmanual, www

We use a mix of CDN77 & Fastly for Gentoo's CDN offering: diversity of providers to avoid single point of failure where possible
[distfiles.g.o only available on CDN77, Fastly said it would be too much traffic for that sponsorship agreement]

This is clearly related to me being in Russia. When I go to the same sites >> from chrome on my android tablet, and this tablet is connected by vpn to a >> vps in Germany, everything works fast and without defects. Unfortunately, I >> have no client compatible with this vpn on my gentoo notebook.

Two theories:
- Russia/ISP is badly blocking a subset of CDN endpoint IPs, and since
CDNs host a wide variety of services, this is collateral damage.

Yes, this is correct.

ping packets pass through because they use the ICMP protocol, which is
not filtered by TSPU "black boxes".

I myself have been affected by this several times, when either the
entire Hetzner address space or the entire Fastly address space was not available for ~1.5 days. Luckily, all Gentoo websites and services can
be used via Tor.

I assume that in Andrey's case CDN77 was blocked.

A common advice is to unplug the WAN cable from your router for at least
15 minutes. It "resets" your session with your ISP, and hosting provider
blocks are cleared.

Some relevant forum topics: https://ntc.party/t/недоступность-hetzner/12845 https://ntc.party/t/блокировка-httphttps-в-сторону-linode-ovh-fastly-digital-ocean-scaleway/8029

- The CDN provider is doing partial blocking of Russia [not to my
knowledge, but I wouldn't rule it out, e.g. being ordered to block
some Russian access]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andrey Grozin posted on Thu, 15 May 2025 11:25:13 +0000 (UTC) as
excerpted:

On Thu, 15 May 2025, Andrey Grozin wrote:

curl 'https://assets.gentoo.org/tyrian/v1/bootstrap.min.js'

It also takes forever.

So Anna confirmed general blocking of the CDN as the likely issue.

As an experiment I just tried gentoo.org with firefox, setting assets.gentoo.org blocked in ublock-origin (ubo, tho in default-deny mode
I originally had it allowed, thus this dance to be sure I had cached
content cleared), saving that, closing firefox, clearing its cache (which
I have on tmpfs anyway so it's always cleared on reboot), then going to gentoo.org once again.

ubo is a "content blocker", with that functionality most popularly used
for ad-blocking in default-allow, block blacklisted, mode, but more useful
to those concerned with browser security because of its ability to block various malware and other irrelevent content (including ads in most cases
as they're generally off-site hosted, tho for the security-aware that's
really more a side effect) in (higher maintenance especially when first configuring for your commonly visited sites) default-deny, allow- configured-whitelisted, mode.

Of course in your case you'd (at least partly) be using it to more
instantly block what's timing out for you anyway, instead of either of the above...

Anyway, with the above, ubo shows a number of assets.gentoo.org resources blocked, but the page appears to load fine, browse fine in my testing,
etc.

So you might try something like that. Tho that's said with the caveat
that I don't normally have those issues here so I can't /properly/ test
your situation, but it /should/ help.

Note that I believe ublock-origin itself is now unavailable for chrome
because it requires functionality that manifest-v3 in chrome blocks, but ublock-origin-lite is I read still available, and it should be fine with specific blocks (the missing chrome-mv3 functionality is apparently more
global blocks as used to efficiently implement wider unwanted content and/
or ad-blocking). And of course there's other content/ad-blockers
available as well that could probably do similar. Meanwhile, a number of
other chromium-based browsers have also said they won't block that functionality in their mv3 implementation, so you might try them too if
the ubo-lite version isn't enough but you prefer to stay chromium-based.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)