Обновить

Что видит DPI, и что мы попробовали у него отобрать

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели81K
Всего голосов 99: ↑93 и ↓6+103
Комментарии68

Комментарии 68

Это всё красиво, но как решать другой ракурс проблемы – что добрая половина всего трафика идёт неизвестным протоколом на один, ну два, ну три одних и тех же сервера?

на один, ну два, ну три одних и тех же сервера?

и так далее, по индукции. ;)

Ни у кого бабца не хватит, столько серверов держать. А через копеечные прокси очень падает качество соединения. А узлы для перенаправления держать - это снова сервера.

Серверов у нас много, но мы направляем основной трафик пользователей P2P, как делал старый Skype. Всех перебить сложно.

Скайп из-за этого нехило трафик выедал, когда ещё платили за мегабайты. Может стать проблемой на телефонах, они тоже в P2P участвуют?

Ты зачем ркн помогаешь?

В качестве пояснения. Я уехал в глубинку нашей необъятной. Тут ркн местный интернет использует как полигон. В рандомный день инет перестает работать, они обкатывают новые способы блокировки. Но учитывая что чаще всего, перестает работать даже то, что должно и через пару часов откатывают назад, они знатные рукожопы. А ты им инструкцию выкатил, как делать правильно.

Драматизируете! Покажите — где тут как им делать правильнее? ;)

Я тоже уехал в глубинку нашей необьятной
И у меня бесплатный тор как работал, так и продолжает работать

Все, что они смогут накопать, они накопают. Устойчивы только технологии, на которые накопать нельзя. Или очень сложно. "Защита незнанием" никогда не была эффективной.

Я предпочту когда они накопают позже, чем я найду способ обойти.

Тоже раньше так думал. Но для себя решил, что лучше помочь нуждающимся ещё хотя бы раз выйти на связь в свободном интернете, чем помешать РКНу его отобрать, скрывая эту информацию. Ну и да. Не забывайте, что распространение информации о способах обхода блокировок РКНу по барабану, иначе бы закон не продвигали, запрещающий такого рода статьи с объяснением способов обхода.

Реализуйте свой протокол/алгоритм и никому о нём не рассказывайте.

Стратегия помогать друг-другу эффективнее, чем стратегия эгоиста. Это можно отследить и по развитию опенсурса, и по миру, который за исключением отдельных стагнирующих стран стремится к сотрудничеству и глобализации. И в даже в биологии у каких-нибудь бактерий есть механизмы горизонтального переноса генов, когда они делятся друг с другом случайными участками ДНК, потому что это увеличивает приспособленность и выживаемость всего их вида. А вот стратегия эгоиста - ни с кем не делиться информацией, спрятаться и не отсвечивать выгодна только РКН. И при такой стратегии даже твой личный маленький секрет они когда-нибудь раскроют и ты останешься у разбитого корыта.

Security through obscurity так или иначе приводит к тупику. Вдобавок, это изначально вредная практика. Она полезна лишь в некоторых узких случаях.

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

Security through obscurity… С такими друзьями, как вы, и врагов не нужно… Самый большой испанский стыд я испытываю, когда коллеги по профессии призывают скрывать от масс технологии, помогающие бороться с несправедливостью. Помните только, что рано или поздно придут и за вами тоже, и некому уже будет помочь вам…

Security through obscurity…

Вообще если затрудниться открытием книги по криптографии то можно узнать что любой реалистичный криптоанализ начинается с предположения что мы УЖЕ знаем схему шифрования.

Ручное шифрование по ИЗВЕСТНОЙ схеме легко ломается компом, но и сейчас осталась уйма нерасшифрованных записок докомпьютерной эры не сломанных по той причине что схема не известна.

Security through obscurity РАБОТАЕТ.

Security through obscurity создает проблемы когда у вас большая бюрократическая организация или того хуже, конгломерат организаций, с тысячами людей с допуском к схеме в течении десятилетий. Тут скрывать алгоритм бесполезно.

Но в наше время ИИ рождать новые схемы можно хоть каждый день... Что как бе намекает. Ну, умным людям...

Вам бы теорию подучить, у вас каша в голове.

Часть проекта открыта: SDK опубликован на GitHub, и код протокола обфускации и decoy‑логики можно посмотреть непосредственно в реализации, а не только в пересказе статьи.

А где опубликован-то? В статье нет ни ссылки, ни названия проекта.

Вот: https://shortnerdcat.navlink.net А SDK на GitHub: https://github.com/kostiakhait/tunnelcat-sdk

А какая роль у вас в этом проекте?

<!-- Copyright (C) Konstantin Khait & Claude Code For IT Partners Solutions and Freedom and Rights 2026 -->

Главный архитектор тут очевидно Клод, а кожаный мешок нужен чисто гит пушить и статьи на Хабр писать :))

да клод и сам умеет пушить и пайплайны запускать/трекать. Я сомневаюсь, что тут и текст человек писал, вон даже в комментах промахивается и пишет в общий тред. На днях был такой же другой "вчера" зареганный выдавший 3 поста за пару часов и отвечающий на комменты лонгридами через минуту. Хабр чет как-то вообще не фильтрует ИИ слоп и ботов

Автор поста - Дмитрий, я работаю аналитиком блокировок в проекте. К нам стекается масса данных из России, их приходится обрабатывать и анализировать (не без нейросетей). А код, чего уж скрывать, действительно во многом пишет Клодик :)

Автор поста - Дмитрий, я работаю аналитиком блокировок в проекте.

а вы о себе пишите в третьем лице или я уже слишком запутался в комментариях :(

Это Клавдий пишет.

ставить задачу. Привыкайте, дальше будет только больше. Начиная с "мы используем utls" было понятно без слов

Это бесплатный сервис?

Да

Сейчас узлов 17, к концу квартала (примерно через три месяца) по плану будет около сотни. И это не статичный набор — состав активных узлов постоянно ротируется, а не сидит годами на одних и тех же адресах.

Судя по описанному, это, скорее всего, не отключение интернета целиком, а включение белых списков — когда доступен только ограниченный набор разрешённых сервисов, а остальное просто не идёт. Для таких случаев есть варианты, в том числе у нас.

забивание гвоздей микроскопом

банальный wg, на наперечёт известные ip протонов\варпов отлично работает с простецкой quic маскировкой

самое сложное выяснить но не спалить при этом кашерные sni

а если wg ip незафаршмачен, то и банальные j 3-1-3 работают

Это все рандом. У кого-то до сих пор даже OVPN работает, а у кого-то со всеми ухищрениями серваки отлетают.

вот именно.но по неясной причине чебуроды сагрились на xray и т.п. активном зондировании. ищут аномалии в tls и т.д. и при этом же wg банальщину лишь по верхам прикрыли. а впновцы отвечают взаимностью и продолжают усложнять вместо того чтоб упростить

Причина ясная. Банальщину успеют прикрыть, а на xray приходится тренироваться.

Кстати да. Лично я покинул ряды "впновцев", перестал участвовать в гонке и хожу через устаревший сто лет назад L2TP. Изумительно.

Позавчера openvpn в первый раз отлетел на дом.ру, при этом wg работает. А до этого пару дней не работал wg на мобильном интернете, а потом заработал)

"У меня такая же нога и она не болит". Мы рады, что у вас работает. Не привыкайте!

Что-то автор открыл Америку через форточку… вроде как необходимость шифровать весь поток и лить пустые данные при необходимости чтобы избежать статистического анализа - это базовые вещи. Оказывается это теперь глубокое экспертное знание?

Все это несомненно очень интересно и уже разобрано в других статьях, но по факту вы чуть позади. Сейчас вопрос по большей части стоит касаемо устойчивости к белым спискам, да сами по себе белые списки очень грубой метод, который на практике показал результат неотличимый от отключения интернета вообще, но все же тенденции ведут именно к такому методу блокировок. Уже есть готовые решения с обходом через turn-сервера, однако жизнеспособность метода в будущем под большим вопросом (разумеется "паразитный" трафик, создаваемый этими тунелями, компаниям, через которые этот транзит производится, определённо не нравится).

Не согласен с постоянной сменой HeloClient фингерпринта, это сам по себе признак КВН, ибо люди используют один браузер. В тексте не указаны примеры обхода сибирской блокировки. Не описан признак наличия КВН, когда после установления связи куча программ или закладок браузера массово начинают долбиться по одному адресу. Не указано, что это все не работает против БС. Для большей надёжности надо точнее эмулировать работу браузера - создать с десяток каналов к разным sni, трафик распределять между ними, периодически закрывается каналы и открывая новые. Не указано, как обходится блокировка внешнего exit узла , если его определили (мой не блокируется)…

люди используют один браузер

Довольно смелое утверждение.
Некоторые люди используют 3-4 браузера, + видимо еще придется ставить какой-то гадки яндекс-браузер с сертификатом минцифры. А еще - curl, wget. А еще - python/requests и всякие новые модные асинхронные либы.

А еще, люди используют просто какие-то приложения (не браузеры), но эти приложения что-то качают по сети (например, запускаешь приложение на телефоне для оплаты эл.энергии - и оно же тоже общается с сервером). Это не браузер, но HTTP клиент.



DPI в первую очередь смотрит на корреляцию между фингерпринтом ClientHello и последующей формой трафика, поэтому простое количество браузеров на хосте его мало волнует

Я использую три браузера: Яндекс, Firefox и Edge.

Развертывание и постоянная поддержка инфраструктуры для обхода ограничений (будь то кастомные VPS, обфускация трафика или постоянный поиск новых протоколов) — это колоссальный и нерациональный расход девелоперского ресурса.

С точки зрения архитектуры и продуктовой стабильности, мы инвестируем время в заведомо нестабильные “костыли”, которые могут сломаться после очередного обновления ТСПУ. В то же время отечественный стек и локальные платформы за последние годы закрыли практически все базовые B2B и B2C потребности — от облачной инфраструктуры и систем оркестрации до корпоративных мессенджеров и медиасервисов.

Гораздо эффективнее один раз мигрировать на стабильные локальные альтернативы с гарантированным SLA, чем содержать инфраструктурную “черную дыру”, требующую ежедневного тушения пожаров ради доступа к зарубежным аналогам.

Посмотрю я на вашу продуктовую стабильность, когда в отечественном облаке внезапно отвалится блочное хранилище вместе со всеми бекапами

это колоссальный и нерациональный расход девелоперского ресурса.

Это если про работу, и если человек не имеет связей за пределами нашей родины.

А если у человека родственники, бывшие коллеги и друзья в разных странах, в том числе и объявленных недружественными. Всех на отечественные продукты не переведёшь.

У моего дяди внук родился, а дядя даже не может созвониться с дочерью, поздравить и порадоваться.

Иными словами, если вы не видите рационального смысла, это ещё не значит, что его нет. Это как стринги с фонариком на рыбалку брать.

У моего дяди внук родился, а дядя даже не может созвониться с дочерью, поздравить и порадоваться.

Регулярн звоню матери по Yolla. Передайте дяде — оно работает.

мы инвестируем время в заведомо нестабильные “костыли”, которые могут сломаться после очередного обновления ТСПУ

Так не обновляйте.

Такие решения хорошо работают, когда у них пользователей пару сотен. РКН на такие мелкие сервисы просто не обращает внимания, так как заткнуть каждую дырку не получится. Когда вдруг пользователей станет миллионы, они быстро направят свои усилия на конкретно этот сервис и найдут, что с ним сделать. Сервис полежит месяцок и число пользователей снова опустится до пары сотен - никто не захочет ждать, когда решаться проблемы.

Чтоб decoy трафик не сжирал процессор, можно генерить фейковые запросы через легковесные горутины, направляя их в cdn-ноды с минимальной задержкой

Спасибо, отличная идея! Действительно, лёгкие горутины вместо тяжёлых запросов - разумный способ снизить нагрузку decoy-трафика на CPU. Обязательно подниму этот вопрос на ближайшем проектном митинге.

У статьи нет структуры. Возникает вопрос - какую проблему вы решаете? Обход блокировок трафика или скорость работы сервиса при обходе таких блокировок?

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

Если же вы хотите раскрыть потенциал скорости обходов блокировок с помощью вашего подхода, тогда нужно в самом начале иметь референсные значения других сервисов позволяющих обходить блокировки и в итогах сравнить показатели с вашим решением.

Было бы интересно увидеть сравнение описанного подхода с VLESS + XHTTP + REALITY и с AmneziaWG в тех же сетях и при одинаковых условиях. В частности, насколько отличаются устойчивость к DPI и active probing, характерные признаки трафика и накладные расходы по latency и CPU. Интересно, какой подход лучше показывает себя на практике.

Прямых бенчмарков против VLESS + XHTTP + REALITY и AmneziaWG у нас нет, поэтому здесь могу дать только качественную оценку. По устойчивости мы, думаю, выигрываем за счёт самой архитектуры: сеть распределённая, есть несколько типов узлов, активный состав ротируется, а клиент получает подписанный список узлов, поэтому единой точки отказа нет. По задержке, наоборот, скорее проигрываем - у нас больше хопов через control/exit и есть дополнительный decoy-трафик. По CPU всё менее однозначно: нагрузка сильно зависит от конкретного режима и условий, поэтому без нормального сравнительного теста я бы не стал утверждать, что кто-то здесь заведомо лучше. В общем, наш основной размен - дополнительная сложность и latency в обмен на устойчивость к блокировке инфраструктуры.

единая точка отказа - то место, откуда клиенты получают список узлов. Особенно - в начале.

Да, и именно поэтому эта точка защищена лучше всего. Но единого списка узлов как такового тоже не существует - каждая подсеть администрируется отдельно.

Для неаутентифицированного клиента такой запрос заканчивается обычным 404

Может, лучше 401?

Я бы отдал 200 и "Отче Наш".

Пытаемся избегать лишних DPI-сигнатур - 401 сам по себе тоже может стать различимым признаком, а 404 сливается с обычным фоновым шумом интернета.

Надеюсь эти ящики которые портят интернет не сильно специализированы, и их можно будет переиспользовать для чего-нибудь хорошего. Там тонны и тонны оборудования, если просто выбросить получится огромная свалка.

Т.е. суть вашего решения - пользователь с помощью вашего клиента подключается к вашим серверам и получает доступ в freeworld? Основное отличие от других протоколах - в маскировке траффика?

Не совсем. Маскировка трафика - только один слой. Главное отличие в другом: нет единой точки, которую можно найти и заблокировать разом. Узлы и сам список актуальных адресов распределены и меняются независимо, поэтому блокировка одного узла или даже одной подсети не останавливает всю сеть. Централизация - это как раз то, от чего мы старались уйти.

А за чей счет банкет?
Скачал клиент, зарегистрировался, получил ключ и работает.

Но меня смущает бесплатность сыра...

Предполагаю, что как и с нейронками: после того, как клиент подсел, его можно начать доить.

Ну с таким жором батарейки...
Да, я люблю пасьянсы :)
Да, я люблю пасьянсы :)

... клиент не подсядет еще долго.

За счёт приложений, которые работают поверх туннеля - среди них есть и коммерческие. Скоро ждите постов от коллег на эту тему.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации