Всем привет! Последние пару лет экосистема обхода блокировок развивалась по принципу «больше фич — жирнее обертка». Большинство популярных десктопных и мобильных клиентов сегодня — это либо тяжелые комбайны на 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:

1. Полный стек протоколов: VLESS, XTLS Vision (с честным splice), REALITY, XHTTP (packet-up, stream-up, stream-one + XMUX), а также XUDP (Full Cone NAT поверх Mux.Cool с GlobalID — игры, Discord и звонки в мессенджерах летают без потерь пакетов).

2. Умный роутинг и обход DPI: Режим «Россия напрямую» с автообновлением баз runetfreedom раз в неделю, встроенный счетчик трафика «мимо VPN» на главном экране и нарезка TLS ClientHello прямо из настроек.

3. Горячая перезагрузка (Hot Reload): Смена серверов, настроек и правил маршрутизации применяется на лету (Instance::reload), без пересоздания TUN‑интерфейса и без разрыва активных соединений у пользователя.

4. Интеграция с панелями (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