В общем, то, о чем долго говорили в регионах, наконец-то полноценно пришло в Москву (в Питере уже давно). Если раньше мобильный интернет в столице был относительным «островком стабильности», то последние события в ЮАО и массовые отчеты из Петербурга показывают — систему белых списков и фильтрацию трафика включили на полную мощь.
Я решил немного пореверсить ситуацию, так как обычные жалобы на «плохую связь» уже не обьясняют того, что происходит на сетевом уровне. Это не технический сбой операторов (они, кстати, сами в шоке и разводят руками), а целенаправленная работа ''Продвинутого DPI''.
Это уже не новость, но теперь это у нас
На самом деле, те же абоненты МТС в Карелии с этой дичью живут чуть ли не с самого начала. Там схема простая: в городе всё более-менее, а за городом скорость на всё, что не входит в «белый список» (Яндекс, ВК и прочие «социально значимые»), режется до 250 кбит/c. При этом аплоад может быть под 40 мбит. Типичный шейпинг по списку разрешенных доменов.
Но в Москве и Питере пошли дальше. Тут мы столкнулись не просто с замедлением, а с фактическим отключением интернета, где доступными остаются только сервисы из «белых списков». О проблемах начали сообщать еще с раннего утра: сначала Москва (Южный округ сидел без связи более 3 часов), потом Питер.
Механика «16 килобайт»
Самое интересное — это то, как именно сейчас блокируют зарубежные платформы и тот же Cloudflare. Я провел серию тестов через curl и увидел довольно системную картину. Это не просто «не открывается», это имитация работы.
Суть в чем: соединение технически устанавливается. TCP-хендшейк проходит, вы даже начинаете получать данные. Но передача обрывается ровно после первых 16–20 килобайт (обычно это 10–14 пакетов).
Этого объема инфнормации достаточно, чтобы браузер начал отрисовывать страницу, но ключевые части сайта (тяжелые JS-бандлы, стили, API-запросы) просто не проходят. В итоге пользователь видит вечную загрузку.
Вот пример типичного замера:
$ curl -k https://cheburcheck.ru/100MB.bin -o/dev/null -r 0-65536 --max-time 5 ... 24 65537 24 16101 0 0 3220 0 0:00:20 0:00:04 0:00:16 0 curl: (28) Operation timed out after 5000 milliseconds with 16101 out of 65537 bytes received
Как DPI решает, кого «казнить», а кого «помиловать»
Как именно система понимает, что вот этот запрос к ok.ru — нормальный, а вот этот к условному packagist.org надо обрубить после 16 килобайт? Всё дело в связке DPI-фильтров, которые анализируют TLS SNI или заголовок Host в случае обычного HTTP.
По сути, сейчас схема рабюотет так: по умолчанию все HTTP(s) запросы на адреса зарубежных подсетей и хостеров блокируются (или «душатся»). Но если в пакете обнаруживается SNI из разрешенного списка, фильтр отключается.
Я проверил это через простой HTTPS-запрос с подменой SNI. Результаты подтверждают теорию:
Берем «вражеский» IP.
Делаем запрос с SNI cheburcheck.ru — получаем таймаут на 16 КБ.
Делаем запрос на тот же IP, но подставляем SNI ok.ru — и данные пролетают мгновенно.
$ curl -k https://ok.ru/100MB.bin --resolve ok.ru:443:[заблокированный_IP] ... 100 65537 100 65537 0 0 55226 0 0:00:01 0:00:01 --:--:-- 55258
Причем, что важно: белые списки работают с масками по поддоменам. То есть, если разрешен основной сайт, то и любой test.ok.ru тоже будет пролетать через фильтры.
Масштабы «загона»
Чтобы понять реальныйй размер этого «белого списка», я прогнал через тесты около 1 000 000 доменов из рейтинга Tranco. Результаты, честно говоря, так себе. Из миллиона популярных сайтов в белом списке содержится всего около 1000 доменов.
То есть нам оставили буквально 0.1% от глобальной сети. При этом выявилась ка кая-то странная аномалия: домены в зоне .co.uk по какой-то причине вообще не трогаются фильтрами и все находятся в белом списке. Почему — вопрос открытый, возможно, просто баг в настройках '' Продвинутого DPI''.
Нюансы с ASN и подсетями
ВО время экспериментов возник вопрос: а должен ли ASN у заблокированного хоста совпадать с ASN домена из белого списка?
Мои тесты и наблюдения других «исследователей» показывают, что это желательно, но не всегда обязательно. У некоторых провайдеров фильтр срабатывает только если ASN совпадают. Но бывает и так, что какой-нибудь avito.ru помогает «пропихнуть» трафик даже на хосты из совершенно других сетей.
Инфрмация постоянно меняется: в какой-то момент стратегия работает, а через час данные в том же «чебурчеке» (сервисе проверки) уже другие. Видимо, настройки фильтров крутят в реальном времени, пытаясь найти баланс. Но общая логика неизменна — если твоего SNI нет в списке доверенных, ты получаешь свои 16 КБ и «разрыв соединения».
Технические маневры: что показывают тесты на VPS
Раз уж мы заговорили про реверс-инжиниринг, нельзя обойти стороной то, как ведут себя самописные решения на базе VPS. Сейчас в сообществе активно обсуждается, что «традиционные» методы начинают буксовать. Например, многие столкнулись с тем, что Роскомнадзор начал блочить подсети популярных хостеров целиком. Был у тебя сервер в Финляндии — и всё, он в бане не по протоколу, а по IP.
Ин��ересен опыт людей, которые пытаются строить сложные цепочки. Одна из рабочих (пока что) схем, которую я заметил — это создание «мостиков». Например, берется VPS у какого-нибудь непопулярного хостера в Норвегии, и через него с помощью GOST (GO Simple Tunnel) пробрасывается туннель к заблокированному серверу в той же Финляндии. Для системы это выглядит как обращение к «чистому» IP в Норвегии.
Но тут нужно разбираться технически в этих нюансах, также постоянно администрировать все это.
Самый простой способ найти готовое решение. На данный момент знаю несколько вариантов которые могут помочь в этом:
hynet.space — этот проект часто мелькает в обсуждениях в профильных чатах как один из самых «живучих» на текущий момент. Используют 6+ протоколов, в том числе неубиваемый VLESS³ - TCP REALITY XTLS VISION.
AmneziaWG — это модифицированный WireGuard, который пытается маскироваться. В связке с Cloudflare WARP у некоторых еще подает признаки жизни, если поиграться с настройками внутри конфига, хотя сам WARP в РФ сейчас знатно лихорадит.
Zapret GUI — по сути, графическая морда для скриптов zapret. Позволяет подбирать стратегии под своего оператора. Штука мощная, но требует настройки «под себя».
По протоколам ситуация следующая (судя по дампам трафика):
VLESS + Reality: Пока держится лучше всего, так как пытается мимикрировать под обычный трафик. Но и тут есть нюансы — использование обы��ного TLS в VLESS-соединениях может вызывать срабатывание фильтров DPI из-за структуры пакетов (так называемый TLS-over-TLS).
Транспорты: Сейчас «живее» остальных выглядят конфиги на XHTTP, GRPC и WS (особенно в связке с Reality). Появились даже фишки типа Reality Seed, но это уже совсем для гиков.
Схема с двумя VPS: Самый «бронебойный», но дорогой вариант — это мост между RU-сервером и зарубежным. Трафик до RU-сервера для провайдера выглядит абсолютно легитимно.
Итоги:
Система «белых списков» — это полная перекройка того, как работает сеть. Когда из миллиона доменов тебе оставляют тысячу, интернет превращается в закрытую экосистему. Причем фильтрация становится всё более «умной»: она анализирует TTL, проверяет DNS-запросы и тупо обрывает сессию на 16-м килобайте, если ей что-то не понравилось.
Поможет ли смена порта? Мои тесты показывают, что на 80-м (http) или даже 7-м (ping) портах ПРОДВИНУТЫЙ DPI иногда ведет себя менее агрессивно, и видео на том же ютубе начинает худо-бедно прогружаться в 1080p. Но это всё временные костыли. Как только какая-то стратегия становится массовой — она тут же попадает под нож.
Похоже, единственный вариант сохранить хоть какую-то связность — это переходить на сложные схемы с раздельным туннелированием и постоянно мониторить актуальные стратегии для того же zapret или nfqws. Инфнормация устаревает буквально за дни.
Такие дела.
