На части провайдеров наблюдаю недоступность HTTP/HTTPS на портах 80, 443 при подключении к IP-адресам Linode и OVH. Запрос «застывает».

Заблокированы диапазоны, как минимум:

• 51.68.188.0/22
• 51.38.124.0/22
• 50.116.0.0/18
• 151.101.0.0/16
• 206.189.65.0/24
• 51.15.0.0/17

Несколько примеров заблокированых ресурсов:
https://tkgeisel.com - Linode (50.116.10.238)
https://nmap.org - Linode (50.116.1.184)
http://50.116.3.249 - Linode
http://51.68.190.107 - OVH DE2
http://51.38.124.173 - OVH DE2
https://reddit.com - Fastly
https://gitlab.redox-os.org - Digital Ocean (206.189.65.122)

Блокируется на:

ovhlinode-05.07.2024-pakt.pcapng (4.9 KB)

Это похоже на динамические блокировки Psiphon. Фильтр, по который я видел ранее (в прошлом месяце), был без таймаута — отправив TCP или UDP-пакеты на два и более IP-адреса Psiphon, доступ ко многим диапазонам OVH, Fastly, Akamai блокировался навсегда для этого IP-адреса, и восстановить доступ можно было только сменой адреса (переподключением роутера).

Что при этом интересно, рубятся не все .TLD.

Так висим:
curl -Svk https://nmap.org --connect-to ::50.116.1.184
curl -Svk https://nmap.com --connect-to ::50.116.1.184
curl -Svk https://nmap.net --connect-to ::50.116.1.184

А так все ОК:
curl -Svk https://nmap.gov --connect-to ::50.116.1.184
curl -Svk https://nmap.ru --connect-to ::50.116.1.184

И так ОК:
curl -Svk https://nm.com --connect-to ::50.116.1.184

Зачем так сложно заморачиваются?

Да, если здесь заменить https:// на http://, то висим везде.

Дополнительно: если на IP-адресе есть служба SSH (как минимум на 22 порту), то при простом TCP-подключении (например при помощи telnet) не получаю в ответ SSH banner. Само TCP-соединение при этом устанавливается (как и в случае HTTP(S) на 80 и 443 портах).

Блокировка HTTP так же работает только на 80 порту.

@anon60595749, вы как-то активировали блокировку, или она у вас сразу была?

Если и активировал, то сам того не зная. Замечаю, что есть блокировка, когда у меня перестает открываться reddit.com. Так или иначе какой-либо VPN service на IP-адресах провайдеров/CDN из названия темы не использую.

Проблема пришла ко мне на домашний канал, в 2024-07-06T18:31:00Z.

Помимо всего прочего, на IP-адресе одного из прокси-серверов АнтиЗапрета 51.38.124.173 (OVH) заблокировался весь TCP-трафик (не проходит TCP SYN ни до одного порта), при этом другие адреса в диапазоне заблокированы обычным образом (соединение «зависает»).

Блокируется только IPv4.

2024-07-07T22:31:00Z заблокировали 51.68.220.147
2024-07-08T13:32:00Z заблокировали 51.38.124.100

Аналогично на МГТС (AS25513) - недоступны Akamai и OVH, но ни к каким публичным VPN сервисам с этого IP не подключались.

У меня последние пару дней картинки с habr.com стали через раз грузиться, с домена habrastorage.org.
А сейчас вечером вообще не грузятся.
При этом на телнет адреса отвечают, а curl не грузит.
Проводной Ростелеком.
Адреса habrastorage.org как раз на ovh и hetzner расположены.

Да, это оно, у меня тоже не открывается один из адресов (51.89.30.72):

habrastorage.org has address 51.89.30.72
habrastorage.org has address 65.21.120.121
habrastorage.org has address 65.109.153.168

Ещё столкнулся с блокировкой некоторых адресов fastpic.org.
Например:
i114.fastpic.org
i123.fastpic.org
i121.fastpic.org
Блокируются адреса 51.77.200.203, 51.77.211.179 (ovh)
Из других подсетей не блокируются. Прям все домены я конечно не перебирал.
Картина та же, телнет на 80 и 433 порты проходит. curl не грузит страницу, ни по https, ни по http.

Сообщают про https://gentoo.org, тоже за fastly

Ко мне тоже пришла эта проблема.

Самое обидное, что не могу попасть на мой собственный личный сайт, который хостится у OVH, и никакого отношения к обходу блокировок вообще не имеет. При этом, если на тот же сервер повесить домен .ru, то все ок.
Ну и на мой любимый gentoo.org тоже попасть не могу.

Проблема наблюдается у меня на основном провайдере - на Билайн Москва (проводной). На моих запасных провайдерах - Билайне мобильном, МТС мобильном и Ростелекоме проводном - этой проблемы нет. А теперь самое интересное наблюдение - у моих знакомых с Билайн Москва этой проблемы нет.

По всей видимости это расширение динамических блокировок на ТСПУ, и блокировки применяются только при одновременном совпадении ряда условий:

• если запрос идет к определенным доменным зонам (com, net, org, ?)
• если IP-адрес назначения находится у определенных провайдеров (OVH и др.)
• если IP-адрес источника ранее неоднократно замечен в использовании “запрещенных” VPN-протоколов

Целью, вероятно, является блокировка VPN-протоколов, маскирующихся под http(s).

При этом я уже довольно давно не использую OpenVPN с Билайна, но до сих пор одной из первой получаю все новинки блокировок. Похоже, что мой билайновский IP-адрес попал в черный список ТСПУ на очень долгий срок, если не навечно.

del

Ещё неприятные блокировки (Ростелеком):

https://fosstodon.org - Fastly
https://www.openstreetmap.org - Hurricane Electric
https://www.reverso.net - OVH

Видимо решили в борьбе с впнами совсем не считаться с сопутствующим ущербом.

Это же Cloudflare, а не HE.

2024-07-11T13:25:00Z не работает не только в РФ

image714×161 11.4 KB

Подтверждаю, на Билайне не работает 2024-07-11T13:25:00Z.

Помимо вышеперечисленного не работают только на Ростелекоме (работают на других)
195.154.81.43 - download.cpuid.com - Scaleway
104.94.100.72 - www.turkishairlines.com - Akamai

Давно не работает нигде, не могу понять почему
37.19.202.36 - cdn78.foxitsoftware.com

Подтверждаю, не работает. Только у меня наоборот - на Билайне не работает, а на других, включая Ростелеком, работает. Что еще раз подтверждает привязку к конкретному IP источника, а не к провайдеру.

UPD:
Обнаружена еще одна блокировка, это вообще за гранью добра и зла
123.60.238.192 - secsmsminiapp.eastcompeace.com - Huawei Cloud

Профиль esim не скачивался в телефон, пока не сменила провайдера.

У меня актуальны все перечисленные в этой теме блокировки, но не эта.

Похоже user agent (или его фингерпринт) имеет значение - из чистого браузера заблокированный CDN открывается, а через curl блокируется после хендшейка:

image1161×231 22.4 KB

Из-за этого пришлось выключить AdGuard и сломались приложения с контентом в Akamai (RGSC, Ubisoft Connect, Origin). При этом DO заблокирован полностью и через браузер тоже не открывается.

Плюс у меня начали замедлять YouTube, смотреть ролики без VPN невозможно.

Вынесли 51.89.30.72 из списка edge-нод, но это, конечно, свинство, так делать. К нам в саппорт приходили жалобы, все как на подбор пользователи российского Билайна, при этом то работало, то не работало.

Кстати, согласно графикам трафика, нода на OVH сервила примерно столько же трафика в Россию, сколько соседняя на том же Hetzner. Просадки было незаметно, что наводит на мысль о том, что у большинства всё работало плюс-минус нормально.

Мне по звонку «перенастроили ТСПУ на моей площадке», но не подтверждают, что у них что-либо работает нештатно. Отвечают, что необходимо заводить заявки в ДЦОА через техподдержку провайдера, в каждом случае.

Наблюдаю следующую итерацию этой проблемы:

Не работает таким же образом rubydoc.info (за Cloudflare), при этом со всем с чем были раньше проблемы (reddit.com, gitlab.redox-os.org, etc) проблем теперь не наблюдается.

На ресурсы в Akamai влияет версия HTTP, через МГТС работает только HTTP/3 по UDP:

curl -v --http3-only https://www.asus.com/

Если кому-то будет полезно, вот что я писал провайдеру:

Я вот что писал:

Приветствую, со вчерашнего дня перестали открываться сайты на крупнейших хостингах: OVH, Linode, Scaleway, Digital Ocean, Akamai

Примеры недоступных ресурсов:
https://nmap.org - Linode (50.116.1.184)
http://51.68.190.107 - OVH
https://www.reddit.com - Fastly
https://www.gigabyte.com - Akamai

Проблема, вероятнее всего, с ТСПУ. Прошу сообщить о проблеме в ГРЧЦ (по АСБИ), ДЦОА, создав заявку об инциденте.

Меня спросили про трассировку, и т.п. Мой ответ:

Происходит “зависание” соединения после отправки первого пакета. Т.е. TCP-соединение устанавливается (поэтому traceroute/mtr ничего не даст), но затем нет ответа от сервера.

И отправил им curl’ы и pcap

Также можно сослаться на мой тикет ДЦОА INC-19203\24-07-1180 как референс.

На текущий момент проблема сохраняется на:

Проблема более нигде не наблюдается.

Блокировку SSH до моего сервера тоже прекратили - также срабатывала после рукопожатия TCP, но только на Windows и на одном провайдере.
Проверил три разных клиента на нескольких компьютерах и везде получил блокировку, при этом с Android и Linux подключение проходило.

В последние дни опять проблемы с доступом к ресурсам на ovh, а также на hetzner (возможно к кому-то ещё) из мобильной беспроводной сети beeline Москва.

Проявляется тем, что через рандомные N-минут доступ по портам 80/443 (другие не проверял) к web-ресурсам на ovh/hetzner перестаёт работать, а если постучаться через curl, то он зависает.

Т.е. подключения то работает то нет, причем чёткой закономерности по длительности работы/не работы нет (может 40 минут работать, потом 10 минут не работать, потом 15 минут работать, потом 5 минут не работать итд, на первый взгляд временные интервалы случайны, во всяком случае никак не привязаны к моим действиям).

В частности такая проблема наблюдается с официальным сайтом Archlinux https://archlinux.org (95.217.163.246) который хостится на hetzner, а также с redirect.archlinux.org (95.216.195.133) который тоже на hetzner и который в archlinux указан как проверочный адрес для NetworkManager (поэтому когда в очередной раз связь отваливается NetworkManager сообщает, что подключение к интернету ограничено или отсутствует)

Подтверждаю что есть блокировка в сторону hetzner через мобильный Билайн, но она очень странная, я отключаюсь от мобильно интернета потом через несколько секунд подключаюсь и все работает, меняется только IP адрес у Билайна, город и область через сайт My IP Address - BrowserLeaks или https://2ip.ru определяется как один и тот же и не меняется.
Я пробую открывать сайты на hetzner через https в простом браузере, ничего не открывается пока не поменяют ip. Это уже продолжается неделю.

В сторону OVH (не знаю, только ли его, тестирую только на нём) работают некие пороговые фильтры, приводящие к обнаружению и ручной блокировке HTTPS-прокси.

Предположительно, сценарий следующий:

1. Большое количество соединений к одному IP-адресу и передача данных, похожих на HTTPS-прокси, вызывают срабатывание пороговых фильтров
2. Данные об IP-адресе отправляются оператору
3. Оператор, возможно, проводит ручную валидацию/проверку наличия прокси
4. Оператор блокирует IP-адрес

Выполняется это вручную ежедневно, только по будням. Блокировка происходит в 15-16 часов по Москве.

К отдельным диапазонам адресов (например, 178.32.137.0/24) более пристальное внимание, а другие (например, 94.23.69.0/24) пока, похоже, не отслеживают.

И как с этим бороться?

Хороший вопрос, а главное своевременный.
Ведь “что-то делать” надо уже сейчас.
Покупать домен, уходить за CDN (Cloudflare и т.п.). Какие тут ещё варианты, если РКН active probing на ручном приводе запилить решил.

Раунд два

Добрый, как говорится, вечер:

https://api.paradox-interactive.com/ (Fastly), g-service Красноярск

Сбрасывается соединение, без “зависания” как было до этого при таких блокировках

блокируют доступ к серверу у ovhcloud в сети 54.36.0.0/24 по вечерам, днем работает все, https, ssh. вечером наоборот.

https://redmine.org (Hetzner), соединение зависает с таймаутом

Полностью заблокировали подсети 54.37.0.0/16 и 54.38.0.0/16 . Проходит только icmp echo, остальные протоколы не работают.