Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 25
TLDR
откатитесь до TLS 1.2 и HTTP/2
По скриншотам dpi-checkers видно что сервера у вас находятся в России но к ним применяются огранияения и блокировки. Я верно понял не зависимо от расположения сервера, палки в колеcа вставляют всем без разбора? Если да, то схема в тексте взятая из статьи https://habr.com/ru/articles/1044396/ не верная.
У нас прокси-сервера на Beget, а сайты клиентов повсюду.
Вот цитата из той статьи:
На их основе действует алгоритм (если ответ на любой вопрос ниже "нет" — пропускаем трафик без ограничений, если "да" — анализируем дальше по цепочке):
IP адрес сервера является подозрительным?
Фингерпринт "браузера" является подозрительным? Таковыми, в среднем, являются отпечатки от: Chrome, Safari, и iOS (при этом, Firefox, Android OkHttp, Edge, 360 Browser, QQ Browser — пока что проходят у большинства операторов);
Было ли более 3 параллельных попыток установить TLS соединение к серверу (т.е. с задержкой между ними менее ~350-400 мс) в течение последних 60 секунд? И это в рамках одного SNI, т.е. его смена "обнуляет" кол-во/меняет контекст. Здесь также стоит заметить, что десятки подключений одновременно — типично для различных клиентов для обхода ограничений, особенно если не используется mux и проч.
У нас получается что создается 1 соединение и внутри него всё загружается.
То есть на вопрос "Было ли более 3 параллельных попыток установить TLS соединение" - ответ нет, мы проходим.
у вас были жалобы от клиентов которые держат легальные сайты на Beget и которые испытывают проблемы с блокировками? Неужели могут блокировать сайты даже в России если им что-то не нравится в отпечатках браузера или много соединений в секунду к Российским серверам?
Лично у нас нет, объяснил почему в статье. А у клиентов Beget без нас - да. В целом ответ на другой вопрос тоже есть в статье.
У меня сервак у beget, на нем расположено пара сайтов. С домашнего открывается, хотя в моменте тупил денёк где-то, а с мобильного ооооочеень долго грузится, как будто я не килобайты загружаю, а файлик на 20-50 мб по времени. И то, не факт, что загрузится. На домашнем ростелегни..ком, а на мобильном Теле2.
Да, на сервере есть ВПН, но он работает только на словах - подключиться можно, а потом ничего не работает, даже на ру сайты не ходит. Т.е. даже как проксю использовать не выходит. Поэтому просто через амнезию напрямую сижу на другой сервак и все. Правда только с домашнего, но.. времени нет столько настраивать..
У нас с селектелом начались эти проблемы. И клиент и сервер внутри РФ. Так что да, могут. Плюс с сегодняшнего дня у нас хабр заблочен.
С 1 апреля когда сами знаете кто начал усиленно бороться сами знаете с чем, у нас пошел поток жалоб от владельцев не самых новых айфонов что не могут попасть на наши сайты. Начали тестировать и действительно на последних моделях нормально все работало, а на более старых айфонах начинало грузить и потом как отрезало. При этом на андроидах все работало. Откатили TLS до 1.2 и заработало у всех.
У нас SaaS-продукт. Работаем на территории всей России. С начала июня стали поступать нечастые жалобы на работу приложения из западных регионов. Первое время мы списывали это на нестабильное интернет-соединение в этих локациях, но 9 июня проблема распространилась по всей стране. При этом наш сервис находится под защитой @DDoS-GUARD Основная проблема кроется в работе API: с фронтенда действительно поступает большое количество запросов, особенно в случаях, когда несколько пользователей из одной организации обращаются с одного IP-адреса. Отпечатки браузеров похожи, тк это небольшие компании где настройку обычно проводят один раз и устанавливают одинаковое ПО. По браузерам, проблемы есть в Chrome, Safari, Edge, Ya Browser. Спасибо за информацию о способах устранения проблем.
Приделываем "костыли" для обычных сайтов!
Chrome fingerprint теперь "токсичный". Вместо интернета получаем чебурнет 😫
Интересное совпадение - того же числа (5 июня) в конце рабочего дня около 16:00 произошёл массовый сбой в биллинге Яндекса - многим (возможно всем) начислили плату за ресурсы, которые они не заказывали.
У нас это вылилось в два моментальных списания примерно по 3300 р. (за две ВМ на Windows), что привело к моментальному выключению севера из-за ухода баланса в минус (карта не была привязана).
Хуже всего то, что после пополнения баланса сервера по-прежнему нельзя было включить - выскакивала ошибка о недостатке прав доступа. И только через 52 минуты всё восстановили.
Деньги, конечно вернули в тот же день, но осадочек остался (+ потеря репутации). Сначала думал менять хостинг, но теперь, зная, что у других был ещё больший пипец задумался - не специально ли они проводили эксперименты с биллингом в тот же день, зная что жаловаться особо не будут - ведь у других ещё хуже?!
https://status.yandex.cloud/ru/incidents/1824
Хабр, а если есть небольшой проект на зарубежном шаред-хостинге (т.е. не ВПС), можно ли:
Как-то самостоятельно проверить касается ли меня эта проблема?
Убедиться, что в настройках SSL всё так, как нужно? Помню, что был популярный сайт, проверяющий ваши сертификаты, общие настройки, и т.п. и дающий оценки типа А, А+, и т.п. Достаточно ли будет посмотреть, что у меня есть/нет поддержка TLS 1.3?
Жалобы от посетителей вряд ли появятся оперативно, да и по статистике понять сложновато - юзеров не так много.
нужно не с симптомами бороться, а с болезнью.
Где с 5го июня пользователи из РФ начали жаловаться на проблемы с доступом к пет-проекту на РФном таймвебе по https. Ответ таймвеба:
У части пользователей возможны проблемы с доступом к инфраструктуре (SSH/RDP, HTTP/HTTPS, ICMP) при использовании сетей российских операторов связи. Симптомы зависят от оператора, региона и браузера. Предположительная причина — изменения в настройках ТСПУ. Если симптомы совпадают — не нужно создавать тикеты в поддержку. Мы продолжаем заниматься этим вопросом и сообщим о любых изменениях в канале: https://t.me/timewebcloud_alerts
"Вылечилось" следующими настройками на реверсе:
http2 on;
ssl_protocols TLSv1.2;
Внесу свои 5 копееек, может быть будет полезно для анализа. Старался прочитать все статьи и комментарии, частично эти все моменты уже обсуждали ранее.
С 5 числа борюсь с проблемой недоступности сайтов на серверах.
Есть 2 сервера: основной Провайдер1, резервный Провайдер2. Оба сервера одинаковые настройки.
Сайт: 10-20 пользователей в секунду. 85% мобильные пользователи из РФ.
5 июня, как позже оказалось РКН, без объявления… начал новую войну, теперь уже с серверами и сайтами. На основном сервере начались проблемы, переключил трафик на резервный сервер, всё заработало. Видимо резервный сервер находится в тылу и не попал под раздачу.
Разбор полёта с учетом всех знаний, матов и нейросети Клода показал, что проблема не на нашей стороне.
Что известно:
http2 сразу была на сервере - не помогает.
Если нагрузки (именно пользователей) на сервере нет, то я могу делать множество запросов, соединений со своих серверов и компьютера, парсить сайт - ничего не блокируется.
Если есть реальные пользователи, то волнами, чаще раз в 10-15 минут, начинаются проблемы: handshake не завершается, клиент не подтверждает пакеты и прочие потери.
В основном волнами, но иногда волны сливаются вместе. Волны идут по нарастающей, т.е. каждый раз захватывая больше пользователей.
Потеря трафика пользователей достигает 50-70%.
Если в этот момент я начинаю также делать обращения к серверу, то меня блокирует на 10 минут по 443 порту. 22 порт, а также другие служебные продолжают работать.
На сервере, на этом IP, есть также другие служебные сайты без трафика с независимыми доменным именем. При обращении к ним также возникают проблемы, т.е. фильтр включается не только по SNI сайта, но по IP сервера.
Предположение: некоторое время ТСПУ надо изучить трафик, но не подтверждено.
TLS 1.2, помогает, но с задержкой !
Я пришел к выводу, что ТСПУ смотрит не только входящий трафик на сервер от одного клиента, а также в целом по IP сервера. И если превышает какие-то лимиты по IP сервера, то начинаются проблемы у всех сайтов на данном IP (не проверил только то, что проблема возникает у разных клиентов).
Пояснения к картинкам:
Нарастающие волны проблем (Sockstat TCP)
Потери трафика в Яндекс Метрике при тестах достигали 70%.
Тестирование перехода TLS 1.2 -> 1.3 -> 1.2. Можно видеть, что 1.2 помогает, но не сразу. Видимо завершаются созданные 10-ти минутные блокировки в ТСПУ.
Прошу прощения, не умею картинки скрывать.
Спасибо автору за статью.
Столкнулся с абсолютно такой же проблемой 21 июня. Без каких-либо изменений с нашей стороны сайт перестал открываться из России.
В целом проблема не новая. Похожая ситуация уже была в октябре 2025 года. Тогда, поскольку серверы находятся в Европе, помогла связка GeoDNS + Reverse Proxy в России (Aeza).
Сейчас же реверс-прокси перестал работать. Симптомы полностью совпадают с описанными в статье. Какое-то время всё работает, затем минут на 20 банит сайт, после чего снова восстанавливается. Все так же банит 443 порт, 22 и 80 стабильно продолжнают работать.
Что пробовал:
Reverse Proxy на Aeza раньше работал, отвалился, отключать TLS 1.3 не пробовал.
Reverse Proxy на Selectel (ru-2 / ru-7) — работает стабильно c TLS 1.3.
Selectel CDN — работает стабильно.
TimeWeb — работает только с отключённым TLS 1.3.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как починить блокировку Вашего сайта от РКН ТСПУ — реальный кейс