К контенту
habrforever
ЖИВА #laws 2026 · ~8 мин чтения

О схеме ограничений РКН в июне 2026-го — актуализация 2026

оригинал на Хабре habr.com/…/1044396
снимок Wayback не сохранялся
статус на Хабре (ноябрь 2026) доступна
права © автор, переиздание в архивных целях с указанием источника

О схеме ограничений РКН в июне 2026-го

Архивное переиздание с актуализацией. Оригинал опубликован на Habr (2026), автор — неизвестен. оригинал доступен на Habr по состоянию на ноябрь 2026. Ниже — редакция ноября 2026: что работает сейчас, что изменилось и как правильно повторить рецепт сегодня. Полный текст оригинала — в конце, без купюр.

TL;DR — версия 2026

К ноябрю 2026 цепочка закрылась: запрет рекламы VPN (2017) → обязанность блокировать запрещённый контент (2017+) → массовые блокировки сервисов (258 за 2025) → закон о «поиске материалов» и удаление самих инструкций (2026).

Оригинал ловил момент старта этой цепочки. К 2026 она замкнулась: по данным РКН, за 2025 год в России заблокировано 258 VPN-сервисов; в 2026 году вступили в силу поправки о «поиске экстремистских материалов», по которым поисковики и мессенджеры обязаны скрывать доступ к запрещённому, а раздача инструкций по обходу начинает приравниваться к «пропаганде средств обхода»; российские сайты и сами хабр-авторы начали массово удалять статьи о VPN (статьи отдают HTTP 451 «удалена по юридическим причинам») — именно поэтому появляются проекты-архивы вроде этого. Сами тексты — теперь исторический документ, и мы сохраняем его именно как документ: читайте, как это выглядело тогда, когда ещё можно было спорить о формулировках.

Статус оригинала

Что произошло между публикацией и 2026

  • 2017–2020: обязали VPN-сервисы подключаться к ФСБ-реестру и блокировать запрещённое; отказ = блокировка; “незаконное распространение” запрещено к рекламе;
  • 2021–2023: блокировки протоколов и портов, суды с крупными сервисами, «замедления» Twitter/YouTube;
  • 2024–2025: по данным РКН, за 2025 год в России заблокировано 258 VPN-сервисов; удаление VPN-статей с хабра пачками (451); уход зарубежных провайдеров;
  • 2026: в 2026 году вступили в силу поправки о «поиске экстремистских материалов», по которым поисковики и мессенджеры обязаны скрывать доступ к запрещённому, а раздача инструкций по обходу начинает приравниваться к «пропаганде средств обхода»; практики давления на SEO-агрегаторы «как обойти».

Техническая сторона вопроса (чем ответила сторона обхода)

Каждая волна ограничений рождала волну инструментов: блокировки протоколов → AmneziaWG и REALITY; замедление YouTube → ByeDPI-семейство; блокировки по IP → CDN-фронты и XHTTP-транспорт; за чистку контента в сторе → альтернативные репозитории и Sideloadly. Асимметрия остаётся: закрыть протокол дороже, чем его обфусцировать.

Иллюстрации из оригинала

* Статья предоставляется исключительно в исследовательских и образовательных целях. Схематическое изображение алгоритма ограничений Ограничения НЕ наблюдаются. Ограничения наблюдаются. Google Chrome devtools Пример результатов dpi-ch для российских провайдеров Пример результатов dpi-ch для зарубежных провайдеров

Что изменилось с 2026 года

  • новость о «запрещали/не запрещали» устарела в момент публикации — следите за реестром
  • формулировки законов менялись: ссылка на первоисточник важнее пересказа
  • количество заблокированных сервисов — счётчик, а не константа

Чек-лист 2026

  • проверять статус сервиса в реестре на текущую дату
  • гайды хранить локально (вот этот архив, например)
  • не доверять «VPN-обзорам» на заблокированных доменах-агрегаторах

Вердикт

Мы переиздаём ньюс-статьи как «точки на графике»: каждая фиксирует состояние регуляторной среды в свою дату. Вместе они складываются в полную историю того, как интернет в РФ стал тем, чем он является в 2026 году.

ОРИГИНАЛ СТАТЬИ (без изменений)

В начале июня 2026-го года сообщество в очередной раз проявило беспокойство: у многих “отвалились” их средства обхода блокировок, в т.ч. построенных на классической базе: xray* + VLESS + REALITY*. Был произведен реверс-инжиниринг внутреннего устройства проблемы, и в данной статье будет описан алгоритм искомой волны ограничений.

* Статья предоставляется исключительно в исследовательских и образовательных целях.

*** Статья предоставляется исключительно в исследовательских и образовательных целях.**

Алгоритм ограничений

По своей сути это напоминает “сибирскую блокировку”, но параметры стали более жесткие, а охват более широкий. Применяется как на мобильных, так и домашних провайдерах.

Работы алгоритма не опирается напрямую на конкретные IP адреса промежуточных узлов в сети (напр., ваших серверов). Что, в общем-то, неплохо — ведь это означает, что оные узлы не улетели в некий черный список. Особенно в свете того, что некоторые приложения “стучат”. Однако, плохая новость в том, что затронуты целые подсети и даже AS, в т.ч. и популярных российских дата-центров (напр., Selectel, Яндекс.Облако, Cloud.ru и др.), что заметно отличается от методов, которые затрагивали только зарубежных провайдеров — tcp 16-20 (aka l4-25) и проч.; такие подсети далее будем называть “подозрительными”.

Дело в том, что цензор оценивает ClientHello при TLS handshake для каждого TLS соединения. Среди прочего, он учитывает такие атрибуты:

IP адрес сервера (точнее: его подсеть, AS или ещё более широкий “сетевой” признак);

SNI (Server Name Indication);

Фингерпринт “браузера” (точнее того, кто пытается под него мимикрировать, что и делает в т.ч. Reality через uTLS).

На их основе действует алгоритм (если ответ на любой вопрос ниже “нет” — пропускаем трафик без ограничений, если “да” — анализируем дальше по цепочке):

IP адрес сервера является подозрительным?

Фингерпринт “браузера” является подозрительным? Таковыми, в среднем, являются отпечатки от: Chrome, Safari, и iOS (при этом, Firefox, Android OkHttp, Edge, 360 Browser, QQ Browser — пока что проходят у большинства операторов);

Было ли более 3 параллельных попыток установить TLS соединение к серверу (т.е. с задержкой между ними менее ~350-400 мс) в течение последних 60 секунд? И это в рамках **одного SNI, **т.е. его смена “обнуляет” кол-во/меняет контекст. Здесь также стоит заметить, что десятки подключений одновременно — типично для различных клиентов для обхода ограничений, особенно если не используется mux и проч.

Итак, если ответ на последний вопрос положительный, то все текущие и дальнейшие попытки соединений замораживаются на 120 секунд. Могут успевать проходить некоторые этапы TLS хендшейка (в т.ч. вплоть до получения ServerHello), но не более.

При этом, интересный нюанс: если вы таки добились заморозки на 120 секунд (что, конечно, не очень сложно), и попытаетесь сменить фингерпринт “браузера” (в т.ч. на “неподозрительный”), то вы дополнительно поймаете блокировку на 600 секунд. В течение этого времени замораживаются любые TLS соединения (TCP всегда коннект проходит), вне зависимости от фингерпринта и SNI. Схематично всё это можно представить примерно так:

Схематическое изображение алгоритма ограничений

Схематическое изображение алгоритма ограничений

upd. от 16.06.2026: похоже, “длинную заморозку” на 10 минут убрали.

Что касается того, о каких версиях HTTP и TLS, а также TCP портах идет речь:

HTTP/1.1 или HTTP/2 — без разницы, все ограничивается. Однако, в случае HTTP/2 браузер обычно ограничивается одним соединением в рамках scheme + host + port, поэтому “серфинг” в этом случае должен пострадать заметно меньше.

TLS 1.2 / 1.3 — оба подвержены этому ограничению;

Какой TCP порт — также не имеет значения.

Насколько можно судить, цензор вообще не оценивает ServerHello (а значит не знает, какие версии в итоге были выбраны). А что касается ClientHello — помним, что учитываются браузерные фингерпринты и есть некий их черный список (иначе ограничения не применяются), а все современные браузеры в начале TLS хендшейка “декларируют” поддержку TLS 1.3 и HTTP/2. При попытке изменить это поведение вы поменяете фингерпринт.

При этом, никаких “белых списков” для SNI (как было в tcp 16-20, напр.) не обнаружено. Однако, если указать пустой SNI (либо не указывать его вовсе), то ограничение не применяется.

Воспроизведение в браузере

Создадим примитивный тестовый стенд на основе Google Chrome, используя данный bash-скрипт: 

TARGET_SNI=foo.com
TARGET_IP=37.230.118.233 # AS29182 (FirstVDS)
DELAY_SECONDS=10
COUNT=3

AT=$(date -v+${DELAY_SECONDS}S '+%Y-%m-%dT%H:%M:%S.000')

cat > /tmp/sib.html <<EOF
<script>
const sni = '$TARGET_SNI';
const fire_at = Date.parse('$AT');

while (Date.now() < fire_at) {}

fetch('https://' + sni + '/')
  .then(r => console.log(r))
  .catch(e => console.log(e));
</script>
EOF

for i in $(seq 1 $COUNT); do
  open -n -a "Google Chrome" --args \
    --user-data-dir=/tmp/chrome-sib-$i \
    --host-resolver-rules="MAP $TARGET_SNI $TARGET_IP" \
    file:///tmp/sib.html
done

Его суть:

Открываются COUNT профилей Chrome, дабы гарантировать что будут разные TCP соединения. Собственно, этим регулируется кол-во соединений;

Открываемый скрипт в каждом профиле ждет “на часах” фиксированный таймстамп (задается вычисляемым параметром AT), и только после этого стартует соединение — это нужно для гарантии их “параллельности”. При этом значение параметра равно текущему локальному времени в системе + задержка DELAY_SECONDS* (*чтобы каждый инстанс браузера успел прогрузиться);

Соотв., через TARGET_IP / TARGET_SNI* *задаем параметры цели (благодаря флагу --host-resolver-rules мы резолвим SNI в заданный IP).

Оценим работу цензора на примере хоста от FirstVDS (на одном из российских домашних интернет-провайдеров). Посмотрим, что будет для 3 параллельных соединений, отслеживая трафик через Wireshark: TARGET_SNI=foo.com; TARGET_IP=37.230.118.233; DELAY_SECONDS=10; COUNT=3

Ограничения НЕ наблюдаются.

Ограничения НЕ наблюдаются.

Успешно получили ServerHello для всех соединений (трафик отфильтрован только по ClientHello/ServerHello дабы помешалось на скрин; подробнее вы можете посмотреть самостоятельно).

А теперь посмотрим что будет в случае 4 параллельных соединений (SNI поменяли, чтобы сбросить контекст цензора, но можно было бы просто выждать более 120 секунд): TARGET_SNI=bar.com; TARGET_IP=37.230.118.233; DELAY_SECONDS=10; COUNT=4

Ограничения наблюдаются.

Ограничения наблюдаются.

Всё, ни одного ServerHello мы не дождались и получили заморозку (это не совсем аккуратный критерий для определения ограничения, но в данном случае достаточный; как говорил выше, можете проверить всё самостоятельно, использовав описываемый тестовый стенд). Также в консоли браузера наблюдается таймаут:

Google Chrome devtools

Google Chrome devtools

Таким образом, сценарий не теоретический, а вполне реальный для обычных браузеров.

Субъективная оценка

Использование обсуждаемого метода ограничений, особенно с такими суровыми параметрами, выглядит довольно сомнительно и тревожно, по меньшей мере потому что он работает слишком грубо. Например, могут не открываться многие вполне легитимные веб-сайты (во вполне легитимных браузерах — воспроизведение см. выше), которые хостятся в т.ч. в РФ дата-центрах. А при смене браузера (вместе с ним меняется и фингерпринт) ненароком можно получить “длинную” заморозку запрошенного сервиса. То есть, это деструктивно влияет в т.ч. и на работу “суверенного” сегмента сети — Рунета.

Однако, есть некоторая вероятность, что параметры ограничений будут смягчены в дальнейшем — похожее поведение уже наблюдалось, напр., в конце 2025-го года.

Что делать

В силу известных нюансов, нельзя что-то посоветовать, решать вам. Однако, для информации и сугубо гипотетически: пока что достаточно нарушить любое из условий цепочки алгоритма выше (напр., подобрать лояльный фингерпринт) чтобы обсуждаемый метод ограничений не применялся. Естественно, что в зависимости от региона, провайдера и с течением времени описываемые в статье значения параметров (тайминги, подсети и т.д.) могут немного отличаться.

Кстати, утилита dpi-ch (в рамках проекта dpi-checkers) была адаптирована к этому виду ограничений:

В версии v0.7.0 был добавлен соотв. субчекер в рамках webhost checker для анализа на предмет данного ограничения — результат его работы можно найти в колонке “Siberian” (на это название вдохновил @0ka когда-то) в табах Infrastructure Providers и Popular Web Services;

В версии v0.8.0 в штатной конфигурации была добавлена новая секция “Russian Infrastructure Providers” (в отдельном табе), а старая переименована в “Foreign Infrastructure Providers”. Таким образом можно будет удобно проверять популярных российских провайдеров инфраструктуры, не меняя конфигурацию. Также теперь можно создавать свои собственные секции, группируя результаты субчекера webhost.

Важно отметить, что помимо штатной конфигурации, в .yaml конфиге можно задать любые интересующие вас подсети (вплоть до одного IP адреса; а также по многим другим признакам: ASN, название организации, доменное имя и т.д.).

Пример результатов на одном из домашних интернет-провайдеров для популярных российских инфраструктурных операторов:

Пример результатов dpi-ch для российских провайдеров

Пример результатов dpi-ch для российских провайдеров

Можно заметить, что картина довольно “любопытная”. А для зарубежных операторов не забывают и про tcp 16-20, что практически полностью парализует их работу (по крайней мере, без дополнительных контрмер):

Пример результатов dpi-ch для зарубежных провайдеров

Пример результатов dpi-ch для зарубежных провайдеров

Такие дела, спасибо за внимание! С уважением, Петр.

по теме #laws