Всем привет! Последние пару лет экосистема обхода блокировок развивалась по принципу «больше фич — жирнее обертка». Большинство популярных десктопных и мобильных клиентов сегодня — это либо тяжелые комбайны на Electron/Flutter, либо графические обертки над ядром Xray или sing‑box через gomobile и C‑FFI, которые тянут за собой рантайм Go, сборщик мусора и жрут от 200 до 400 МБ оперативки просто в фоне.
Когда у тебя слабый ноутбук, офисная машина или телефон, на котором открыта пара тяжелых приложений, лишние 300 МБ под один только VPN начинают ощутимо бить по системе. А если речь идет об iOS, где системный лимит на сетевые расширения (PacketTunnelProvider) составляет жесткие 50 МБ, такие клиенты регулярно падают по OOM (Out Of Memory) при попытке загрузить крупные гео‑базы.
В один прекрасный день мне это надоело. Я решил взять всё в свои руки и написал с нуля собственный кроссплатформенный TUN‑клиент и сетевое ядро на чистом Rust без единой сторонней прослойки. Встречайте — Unbihex (названный в честь гипотетического 126-го элемента унбигексия). Сейчас он потребляет 18 МБ ОЗУ в режиме TUN (и 12 МБ в прокси), поддерживает полный стек современных протоколов и уже готов к продакшену.
Под катом — как это устроено под капотом, какие грабли пришлось собрать при работе с TUN под Windows и как удалось подружить ядро с популярными панелями.
1. Архитектура: почему он ест всего 18 МБ?
Главный пожиратель памяти в классических клиентах — это гео‑базы (geosite.dat и geoip.dat) и правила маршрутизации. Стандартный подход выглядит так: клиент берет многомегабайтный protobuf‑файл, полностью парсит его в памяти и разворачивает в огромное дерево для матчинга.
В Unbihex эта проблема решена на уровне архитектуры ядра:
-
Потоковый парсинг geosite/geoip: Базы читаются с диска (поддерживаются файлы до 256 МБ) потоково. В оперативную память попадают исключительно те категории и префиксы, которые реально задействованы в текущих правилах маршрутизации.
-
Succinct Trie для
.srs(sing‑box rule‑sets): Правила маршрутизации и доменные суффиксы упаковываются в сжатые префиксные деревья, что исключает раздувание кучи (heap). -
Никакого GC и C‑FFI: Чистый Rust со статическим распределением памяти и нулевыми накладными расходами на межъязыковое взаимодействие.
2. Боли разработки: о чем не пишут в документации протоколов
Написание собственного ядра с нуля (unbihex-engine) столкнуло меня с несколькими интересными сетевыми задачами, которые пришлось решать самостоятельно:
Проблема № 1: Петля Broadcast/Multicast UDP в Windows TUN
При поднятии виртуального сетевого адаптера на Windows стандартный сетевой стек хоста начинает отправлять широковещательные запросы и служебный multicast‑трафик прямо в туннель. Из‑за этого без фильтрации пакетовTUN‑интерфейс на Windows мгновенно закольцовывался, забивая процессор под 100% и полностью блокируя полезный трафик.
-
Решение: На уровне сетевого драйвера туннеля в ядро была встроена строгая отсечка широковещательных и мультикаст‑пакетов до того, как они уйдут в обертку Mux/транспорта.
Проблема № 2: Дедлок и лаги в XTLS Vision (splice)
При реализации flow=xtls-rprx-vision с нулевым копированием через splice выяснилось, что стандартная реализация часто ловит дедлоки: чтение блокировалось в ожидании данных, пока параллельный поток был занят отдачей (например, скачивание файла полностью останавливало загрузку других страниц).
-
Решение: Разделение асинхронных каналов чтения/записи на неблокирующие задачи в
tokioс корректным тайм‑аутом простоя TCP‑соединений (по лимиту ядра в 300 с вместо агрессивных 60 с) и мгновенной доставкой сетевогоFINот сервера к приложению.
Проблема № 3: Маскировка отпечатка (TLS ClientHello + HTTP/2)
Чтобы ТСПУ не вычисляли клиент по шаблонным заголовкам, ядро генерирует собственный ClientHello на чистом Rust (с точным порядком расширений, GREASE‑значениями и поддержкой фрагментации TLS‑пакетов прямо из GUI). А для режима XHTTP (SplitHTTP + XMUX) параметры кадров SETTINGS и стартового WINDOW_UPDATE в HTTP/2 выстроены байт‑в‑байта под десктопный Chrome, успешно проходя проверки на tls.peet.ws.
3. Что уже умеет клиент (версия 0.1.0)
На текущий момент Unbihex — это не просто консольная утилита, а полноценный кроссплатформенный клиент с графическим интерфейсом под Windows (инсталлятор и portable), Android (APK) и Linux:
-
Полный стек протоколов: VLESS, XTLS Vision (с честным
splice), REALITY, XHTTP (packet-up,stream-up,stream-one+ XMUX), а также XUDP (Full Cone NAT поверх Mux.Cool сGlobalID— игры, Discord и звонки в мессенджерах летают без потерь пакетов). -
Умный роутинг и обход DPI: Режим «Россия напрямую» с автообновлением баз
runetfreedomраз в неделю, встроенный счетчик трафика «мимо VPN» на главном экране и нарезка TLSClientHelloпрямо из настроек. -
Горячая перезагрузка (Hot Reload): Смена серверов, настроек и правил маршрутизации применяется на лету (
Instance::reload), без пересоздания TUN‑интерфейса и без разрыва активных соединений у пользователя. -
Интеграция с панелями (Remnawave, Marzban, 3 x‑ui):
-
Полная поддержка JSON‑подписок и ссылок.
-
Парсинг лимитов трафика с красивым прогресс‑баром, точной датой окончания подписки и количеством оставшихся дней.
-
Кликабельные ссылки на техподдержку и личный кабинет прямо в интерфейсе клиента.
-
Передача HWID для панелей с лимитом устройств.
-
4. Планы на будущее и что в роадмапе
Останавливаться на достигнутом я не собираюсь. В ближайших планах:
-
Нативная сборка под iOS (благодаря легкому весу в 18 МБ клиент идеально вписывается в лимиты Apple Network Extension без вылетов по памяти).
-
Серверная часть (Inbound): Реализация VLESS / Vision / REALITY инбаундов прямо в ядре.
-
gRPC API как у Xray: Поддержка
HandlerServiceиStatsServiceдля бесшовной замены стандартного бинарника/usr/local/bin/xrayнаunbihexпрямо на VPS‑нодах под управлением Marzban или 3 x‑ui без изменения панелей управления.
Исходный код полностью открыт. Проект живет на GitHub, релизы и готовые билды уже доступны для скачивания. Буду рад конструктивной критике, баг‑репортам, звездам и пулл‑реквестам от сообщества!
https://github.com/crystalmasta/unbihex
ссылка на оригинал статьи https://habr.com/ru/articles/1100854/