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

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

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

Итак, по своей сути это напоминает «сибирскую блокировку«, но параметры стали более жесткие, а охват более широкий. Вот как это устроено:

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

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

• IP адрес сервера (точнее, подсеть);

• SNI (Server Name Indication);

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

На их основе действует алгоритм (если ответ на любой вопрос ниже «нет» — пропускаем трафик без ограничений, если «да» — анализируем дальше по цепочке):
— IP адрес входит в «подозрительную подсеть»?
— Фингерпринт «браузера» является подозрительным? Таковыми являются отпечатки от: Chrome, Safari, и iOS (при этом, Firefox, Android OkHttp, Edge, 360 Browser, QQ Browser — пока что проходят);
— Было ли более 3 параллельных попыток установить TLS соединение к серверу (т.е. с задержкой между ними менее ~100 мс) в течении последних 60 секунд? И это в рамках одного SNI, т.е. его смена «обнуляет» кол-во/меняет контекст. Здесь также стоит заметить, что десятки подключений одновременно — типично для различных клиентов для обхода ограничений, особенно если не используется mux и проч.

Если ответ на последний вопрос положительный, то все текущие и дальнейшие попытки соединений замораживаются на 120 секунд.

Интересный нюанс

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

Что делать

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

Кстати, в dpi-ch (в рамках проекта dpi-checkers) в версии v0.7.0 был добавлен соотв. субчекер в рамках webhost checker для анализа на предмет данного ограничения — его можно найти в колонке «Siberian» (на это название вдохновил @0ka когда-то) в табах Infrastructure Providers и Popular Web Services . Помимо штатной конфигурации, как и раньше, в .yaml конфиге можно задать интересующие вас ipv4 подсети (вплоть до /32)/AS/org и т.д. (логично это делать в разделе checkers => webhost => infra) для проверки. Например:

checkers:  webhost:    infra:      - name: Selectel        filter: org("selectel")        count: 3      - name: Yandex        filter: org("yandex")        count: 3

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