ZDT-D: Android как гибкий сетевой шлюз с root-доступом
ZDT-D: зачем Android root-модулю собственный сетевой daemon
На Android есть привычная модель работы с VPN: приложение поднимает VpnService, создаёт виртуальный интерфейс, получает системную VPN-иконку и начинает пропускать через себя весь трафик устройства или выбранные приложения.
Для большинства пользователей этого достаточно. Но если хочется более гибкой схемы — например, чтобы одно приложение шло через один инструмент, второе через другой, третье напрямую, а четвёртое через отдельный proxy pipeline, — стандартная VPN-модель быстро начинает мешать.
ZDT-D — это Android root-модуль для маршрутизации трафика, DPI-инструментов, локальных proxy/tun-пайплайнов, DNS-контроля и управления сетевыми правилами по приложениям.
Это не попытка сделать “ещё один VPN-клиент”. Скорее, это попытка превратить Android-устройство в небольшой настраиваемый сетевой узел, где разные приложения могут ходить через разные маршруты.
Откуда появился ZDT-D
Изначально идея выросла из экспериментов с DPITunnel и другими похожими инструментами.
DPITunnel сам по себе не создавал VPN-интерфейс, и это важно уточнить. Речь не о том, что он был обычным VPN-приложением. В моём случае интерес был в другом: хотелось использовать подобные DPI-инструменты не как отдельное Android-приложение, а как часть более контролируемой системной схемы.
Первая идея была простой: перенести подход в root-модуль, чтобы всё работало на системном уровне, в фоне, с нормальной процедурой запуска и остановки. Не вручную собирать правила, не держать всё на shell-скриптах и не зависеть от поведения обычного приложения.
Ранние версии ZDT-D были очень простыми. Это был почти не настраиваемый модуль: установил, запустил — работает. Потом постепенно появилась база iptables, раздельное туннелирование, поддержка новых программ, webroot/webui-интерфейс, автоматизация и, в итоге, daemon на Rust вместе с Android-приложением для управления.
Название ZDT-D осталось историческим. Изначально оно было собрано из названий инструментов вроде DPITunnel, Zapret и DPI. Но проект давно перерос начальную идею, поэтому сейчас название скорее стало собственным именем, чем строгой расшифровкой.
Что такое ZDT-D сейчас
Если описывать коротко, ZDT-D — это root-level система управления сетевыми маршрутами и сетевыми движками на Android.
Он состоит из нескольких частей:
root-модуль для Magisk, KernelSU, APatch и их форков;
daemon
zdtd, написанный на Rust;Android-приложение для управления;
набор поддерживаемых сетевых движков;
система профилей;
UID-based маршрутизация приложений;
optional Zygisk-компонент для дополнительной изоляции от приложений-анализаторов.
Упрощённо архитектуру можно представить так:
Android-приложение
↓
локальный API
↓
Rust daemon zdtd
↓
iptables / netd / NFQUEUE / local proxy / TUN / engines
↓
трафик выбранных приложений
Android-приложение здесь не является основным сетевым движком. Оно скорее панель управления: выбрать приложения, настроить профили, посмотреть статус, открыть логи, установить или обновить модуль.
Основная работа выполняется daemon-ом zdtd.
Почему не обычный VpnService
Обычный Android VPN через VpnService удобен, но у него есть ограничения.
Во-первых, Android обычно работает с одним активным VPN-соединением. Если системный VPN-слот уже занят, второй VPN-клиент поверх него нормально использовать сложно.
Во-вторых, не все VPN-инструменты дают удобное раздельное туннелирование. Например, в некоторых сценариях с OpenVPN хочется отправить через туннель только выбранные приложения, а остальные оставить напрямую.
В-третьих, обычный VPN виден системе и приложениям. В некоторых случаях это мешает: приложения могут менять поведение, ругаться на VPN, проверять сетевые интерфейсы или анализировать окружение.
ZDT-D решает задачу иначе. Он работает с root-доступом и управляет маршрутизацией на уровне системы. Это позволяет собирать схемы, которые обычному Android VPN-клиенту собрать сложно или невозможно.
Например:
YouTube → DPI-инструмент
Telegram → proxy pipeline
браузер → отдельный proxy-профиль
рабочее приложение → OpenVPN / TUN binding
банковское приложение → напрямую
Это не значит, что ZDT-D всегда лучше обычного VPN. Это другой подход. Если нужен простой VPN “на всё устройство”, обычный клиент будет проще. Но если нужна гибкая маршрутизация по приложениям, ZDT-D даёт больше свободы.
Раздельное туннелирование по UID
Одна из главных идей проекта — работать не со всем устройством сразу, а с конкретными приложениями.
В Android каждое приложение имеет Linux UID. ZDT-D использует это как основу для маршрутизации. Пользователь выбирает приложения, daemon получает их UID, а дальше строит правила для выбранных программ.
Это позволяет назначать разные сетевые пути разным приложениям.
Например:
приложение A → один профиль
приложение B → другой профиль
приложение C → напрямую
приложение D → локальный DPI/proxy pipeline
Такой подход отличается от классической модели “весь трафик устройства через один туннель”.
ZDT-D как сетевой комбайн
Слово “комбайн” здесь подходит, но важно правильно его понимать.
ZDT-D не пытается просто “запихнуть всё подряд”. Он скорее выступает оркестратором: запускает разные сетевые программы, связывает их с профилями, назначает приложения, проверяет конфликты и управляет состоянием сервиса.
Проект поддерживает разные направления:
Zapret / NFQWS;
ByeDPI;
DPITunnel;
OpenVPN;
AmneziaWG;
sing-box;
Opera-proxy pipeline;
DNSCrypt;
tun2socks / t2s;
пользовательские программы.
Некоторые части уже достаточно зрелые, некоторые ещё развиваются. Например, sing-box пока можно считать направлением, которое требует дальнейшей доработки и тестирования.
Одна из важных особенностей ZDT-D — расширяемость. Проект не ограничен только встроенными программами. Идея в том, чтобы можно было добавлять свои инструменты, свои бинарники, свои сценарии запуска и связывать их с общей системой маршрутизации.
Что значит “встроенная защита”
В контексте ZDT-D защита — это не обещание полной невидимости или магии.
Речь о более конкретной задаче: приложения не должны видеть то, что запустил ZDT-D, если им это знать не нужно.
Например, если ZDT-D поднял интерфейс tun1 или awg1, некоторые приложения могут попытаться обнаружить такие интерфейсы через системные API, /proc, /sys/class/net, netlink или другие способы.
Для таких сценариев в проекте есть optional Zygisk-компонент. Его задача — не скрывать всё подряд, а точечно скрывать именно те интерфейсы, которые сейчас активны у ZDT-D.
Это важный принцип.
Не нужно скрывать все tun*, wg* или awg*. Такой подход может ломать приложения и давать слишком много побочных эффектов.
Правильнее скрывать только то, что реально относится к текущему состоянию ZDT-D.
Например:
активен tun1 → скрываем tun1
активен awg1 → скрываем awg1
активен tun20 → скрываем tun20
Если интерфейса нет в активном состоянии, его не нужно скрывать.
Zygisk-компонент является необязательным. Его можно включить при установке, если пользователю нужна дополнительная изоляция от приложений-анализаторов.
Что внутри под капотом
Внутри ZDT-D есть несколько уровней.
Daemon
zdtd отвечает за запуск, остановку, проверку конфликтов, запуск дочерних процессов, применение правил и логику состояния.
Это удобнее, чем держать всю сетевую логику в Android-приложении. Приложение может быть выгружено системой или перезапущено, а daemon продолжит работать отдельно.
Правила маршрутизации
В зависимости от профиля и выбранной программы используются разные механизмы:
iptables / ip6tables
NFQUEUE
локальные порты 127.0.0.1
Android netd
TUN-интерфейсы
UID-based правила
Профили
Разные программы имеют свои настройки, списки приложений, порты, конфиги и runtime-поведение.
Daemon собирает включённые профили, проверяет конфликты и запускает нужные компоненты.
Состояние сервиса
Важный практический момент: нельзя полностью доверять простому поиску процессов по имени.
На Android могут существовать чужие процессы с такими же именами: sing-box, t2s, nfqws и так далее. Они могут не иметь отношения к ZDT-D, но при простом pidof выглядеть как “что-то запущено”.
Поэтому состояние сервиса лучше отделять от диагностики процессов. Процессы полезны для статистики и логов, но не должны быть единственным источником истины для кнопки “запущено / остановлено”.
Производительность
Одна из целей проекта — работа в фоне с минимальным потреблением ресурсов.
В простом состоянии, без больших пользовательских списков и множества профилей, потребление памяти обычно небольшое. На первом запуске без сложных настроек оно может быть в районе десятков мегабайт, ориентировочно до 80 МБ.
Но это зависит от конфигурации. Например, у автора проект может занимать значительно больше — вплоть до сотен мегабайт — просто потому, что используется много конфигов, списков, профилей и тестовых настроек.
То же самое с CPU. В режиме ожидания многие компоненты почти не потребляют процессорное время. Но итоговая нагрузка зависит от выбранных движков, количества трафика, DNS, DPI-обработки, числа профилей и маршрутов.
Поэтому честная формулировка такая: ZDT-D может быть очень лёгким в простых сценариях, но итоговое потребление зависит от того, что именно пользователь собрал внутри.
Чем ZDT-D отличается от обычных инструментов
Если сравнивать с обычным VPN-клиентом, различия примерно такие:
Обычный VPN:
один главный туннель
один VpnService
системная VPN-иконка
ограниченная комбинация движков
часто всё завязано на один TUN
ZDT-D:
root-level daemon
UID-based маршрутизация
несколько движков
несколько профилей
работа через iptables/netd/NFQUEUE/local proxy
поддержка пользовательских программ
optional Zygisk-защита
Если сравнивать с отдельными DPI-инструментами, отличие тоже заметно. ZDT-D не просто запускает один бинарник. Он пытается обернуть разные инструменты в общую систему: профили, списки приложений, маршруты, проверка конфликтов, статус, Android UI.
В этом смысле проект ближе к платформе для Android-сетевых экспериментов, чем к одному конкретному приложению.
Плюсы
Главные плюсы проекта:
гибкая раздельная маршрутизация;
работа по UID приложений;
возможность использовать несколько сетевых движков;
не опирается только на стандартный
VpnService;поддержка Magisk, KernelSU, APatch и их форков;
daemon на Rust;
Android-приложение для управления;
возможность добавлять свои программы;
работа в фоне;
optional защита от анализа интерфейсов ZDT-D;
низкое потребление ресурсов в простых сценариях.
Для пользователя, которому нужен один простой VPN на всё устройство, это может быть избыточно.
Но для тех, кто хочет управлять трафиком отдельных приложений, комбинировать разные движки и строить собственные схемы маршрутизации, это как раз основная идея проекта.
Минусы и ограничения
Минусы тоже есть.
Нужен root
Без root-доступа такой проект невозможен. Нужен Magisk, KernelSU, APatch или совместимая среда.
Не для совсем старых устройств
Очень старые версии Android и старые архитектуры могут не поддерживаться. Совместимость зависит от Android, root-менеджера, ядра, SELinux, iptables, netd и поведения конкретной прошивки.
Порог входа
Базовые сценарии можно сделать относительно простыми, но чтобы использовать проект на полную, нужно понимать, что такое proxy, TUN, UID, DNS, DPI, маршруты и профили.
Возможны ошибки
Проект активно развивается. В разных root-средах и прошивках могут появляться ошибки.
Но это не “чёрный ящик”: если пользователь предоставляет логи, описание сценария, версию Android, root-менеджер и информацию о конфигурации, такие проблемы можно разбирать и исправлять.
Это не магическая кнопка
Если конфиг сам по себе нерабочий, ZDT-D не сделает его рабочим автоматически. Например, если sing-box-профиль не работает в исходном инструменте, его сначала нужно привести в рабочее состояние.
Для кого этот проект
ZDT-D не пытается быть приложением для всех.
Он для тех, кто:
использует root на Android;
хочет раздельную маршрутизацию;
работает с VPN/proxy/DPI-инструментами;
хочет управлять трафиком конкретных приложений;
экспериментирует с Android networking;
готов читать логи и понимать базовую сетевую логику.
При этом проект постепенно двигается в сторону снижения порога входа: появляется Android UI, готовые заготовки, базовые настройки, автоматизация и более понятные статусы.
То есть новичок может начать с простого сценария, а более опытный пользователь — собрать сложную сетевую схему.
Чего ZDT-D не обещает
Важно проговорить отдельно.
ZDT-D не гарантирует одинаковую работу на всех прошивках.
Не гарантирует абсолютную невидимость для всех приложений.
Не заменяет понимание сетевой маршрутизации.
Не отменяет риски root-доступа.
Не делает любой конфиг рабочим автоматически.
Это инженерный инструмент, а не магическая кнопка.
Почему проект интересен
ZDT-D интересен тем, что занимает нишу, которую обычные Android VPN-приложения закрывают плохо.
Он не пытается быть ещё одним клиентом одного протокола. Он строит слой управления, где разные инструменты можно связать с конкретными приложениями и сценариями.
И в этом его главная ценность: гибкость.
Проект начинался как простой root-модуль вокруг нескольких DPI-инструментов. Потом появились shell-скрипты, расширение iptables-базы, раздельное туннелирование, webui-идеи, новые программы, daemon на Rust, Android-приложение, optional Zygisk-защита и всё больше автоматизации.
Сейчас это уже не маленький скрипт, а развивающаяся система для Android root networking.
Заключение
ZDT-D — это проект для тех, кому стало тесно в рамках обычной Android VPN-модели.
Если нужен один простой VPN-клиент, скорее всего, ZDT-D будет избыточен. Но если хочется управлять трафиком приложений отдельно, комбинировать разные движки, использовать root-возможности Android и собирать собственные сетевые схемы — проект становится интересным.
Он не идеален, требует root и всё ещё активно развивается. Но именно этим он и любопытен: это живой технический проект, который вырос из личной задачи и постепенно превращается в гибкую платформу для Android-сетевых экспериментов.
Если тема интересна, проект можно посмотреть на GitHub, протестировать на своём устройстве, предложить идею или помочь с разработкой. Особенно полезны тесты на разных прошивках, версиях Android, Magisk, KernelSU, APatch и их форках.