netrunner-proxy/client/src/tun/README.MD

Блок client/tun — TUN-интерфейс и системная маршрутизация

«Железо» клиента — граница с ОС, через которую в стек попадают сырые L3-пакеты приложений и куда возвращаются ответы. Платформо-зависимый ввод/вывод.

Детали — в rustdoc крейта netrunner-client, модуль tun.

Файлы

Файл	Роль
tun.rs	Обёртка Tun: создание/открытие устройства, split на reader/writer.
device.rs	Счётчики трафика (GLOBAL_* для FFI) + TrafficCounter со скоростью.
routing.rs	Установка/снятие системных маршрутов и kill-switch.

Как создаётся TUN

• Linux (desktop) — Tun::create(...) с именем netr0, адресом 10.0.0.1/24.
• Android/iOS — Tun::from_fd(fd): дескриптор приходит из нативного VpnService.
• Split разводит устройство на пишущую и читающую половины — их забирают разные задачи движка (net).

Маршрутизация (routing.rs)

setup_platform_routing заворачивает трафик в TUN, сохраняя доступ к прокси; при killswitch режет всё мимо туннеля. Реализация целиком по cfg:

Платформа	Механизм
Linux	nftables (таблица netrunner) + policy-routing ip rule/table 100; split-tunneling по UID; DNAT DNS на стек.
Windows	таблица маршрутов (0.0.0.0/1+128.0.0.0/1 поверх дефолта); kill-switch удалением дефолта; откат через DHCP-renew.
Android/iOS	ничего — маршруты ставит нативная сторона.

reset_platform_routing откатывает всё при остановке.

Связи

Пакеты из Tun читает движок net; счётчики GLOBAL_* отдаются в приложение через FFI (lib.rs). Имя device.rs историческое — сам smoltcp-Device живёт во внешнем форке smoltcp, здесь только метрики.