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

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

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

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

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

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

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

• SNI ^[6] (Server Name Indication);

• Фингерпринт "браузера" ^[7] (точнее того, кто пытается под него мимикрировать, что и делает в т.ч. Reality через uTLS ^[8]).

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

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

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

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

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

Что делать

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

Кстати, в dpi-ch ^[10] (в рамках проекта dpi-checkers) в версии v0.7.0 ^[11] был добавлен соотв. субчекер в рамках webhost checker для анализа на предмет данного ограничения — его можно найти в колонке "Siberian" (на это название вдохновил @0ka ^[12] когда-то) в табах 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

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