У меня актуальны все перечисленные в этой теме блокировки, но не эта.
Похоже user agent (или его фингерпринт) имеет значение - из чистого браузера заблокированный CDN открывается, а через curl блокируется после хендшейка:
Из-за этого пришлось выключить 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 как референс.
На текущий момент проблема сохраняется на:
name | isp | asn | city |
---|---|---|---|
ru-012 | Beeline/Corbina | AS8402 | Tula |
ru-021 | ER-Telecom Holding | AS56981 | Tomsk |
ru-025 | Rostelecom | AS12389 | Kemerovo |
ru-026 | Rostelecom | AS12389 | Kemerovo |
ru-029 | Beeline | AS16345 | Kemerovo |
ru-032 | Sibirskie Seti Ltd. | AS34757 | Novosibirsk |
ru-033 | P.a.k.t LLC | AS39087 | Saint Petersburg |
ru-035 | UBS (ubsnet.ru) | AS50042 | Sevastopol |
ru-036 | Igra-Service | AS33991 | Krasnoyarsk |
ru-038 | Beeline | AS8402 | Krasnodar |
ru-041 | Zeltelecom | AS57652 | Moscow |
Проблема более нигде не наблюдается.
Блокировку 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-прокси.
Предположительно, сценарий следующий:
- Большое количество соединений к одному IP-адресу и передача данных, похожих на HTTPS-прокси, вызывают срабатывание пороговых фильтров
- Данные об IP-адресе отправляются оператору
- Оператор, возможно, проводит ручную валидацию/проверку наличия прокси
- Оператор блокирует 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, остальные протоколы не работают.