В начале июня 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
Спасибо за внимание!
С уважением,
Петр.