ARCH.md: Протокол и Архитектура Netrunner

Обзор

Netrunner — это комплексная система обхода сетевых ограничений, использующая кастомный протокол инкапсуляции для скрытия факта использования прокси. Трафик выглядит как обычный HTTPS (TLS-хендшейк), внутри которого передаются зашифрованные кадры (frames) с мультиплексированными потоками данных.

Проект состоит из клиентского виртуального сетевого стека, асинхронного ядра мультиплексирования и серверной части.

1. Уровни протокола

ТРАНСПОРТНЫЙ УРОВЕНЬ (TLS Wrapper)

Использует TlsBridge для имитации легитимного TLS Handshake.
Сервер и клиент обмениваются ECDH публичными ключами в сообщениях ClientHello/ServerHello.
После хендшейка инициализируются симметричные ключи сессии для AEAD-шифрования (ChaCha20-Poly1305).
Все последующие данные передаются под видом стандартных записей TLS Application Data.

УРОВЕНЬ МУЛЬТИПЛЕКСИРОВАНИЯ (Frame)

Каждый кадр внутри AppData имеет фиксированный заголовок и следующую структуру:

Auth Tag (16 байт): HMAC-подобный тег для проверки целостности и защиты от повторного воспроизведения.
Stream ID (4 байта): Идентификатор потока. Позволяет пускать множество независимых TCP/UDP соединений в один туннель.
Frame Type (1 байт): - 0x00 (Connect)
- 0x01 (Data)
- 0x02 (Close)
- 0x03 (Heartbeat)
Payload Len (2 байта): Длина полезной нагрузки.
Padding Len (2 байта): Длина случайного мусорного трафика.
Payload (динамическая длина): Сами данные перехваченного пакета.
Padding (от 0 до 255 байт): Рандомные байты для искажения сигнатур длины пакета.

2. Алгоритм работы протокола

ClientHello: Клиент генерирует ключи и отправляет замаскированный запрос.
ServerHello: Сервер отвечает, завершая обмен ключами.
Обновление ключей: Инициализация ключей сессии (ChaChaCipher).
Упаковка данных: Шифрование Frame целиком (включая заголовок, payload и padding).
Транспорт: Отправка зашифрованного буфера в запись ApplicationData поверх TCP.

3. Безопасность и защита от Replay-атак (Time-Based Auth Tag)

Протокол использует динамический механизм аутентификации кадров, похожий на TOTP (Time-Based One-Time Password), что делает его устойчивым к атакам MITM и повторного воспроизведения (Replay Attacks) со стороны DPI.

Генерация тега: Тег вычисляется с использованием HmacSha256 от предварительно согласованного секретного ключа (auth_key). В качестве "соли" (payload) выступает текущее время системы (UNIX_EPOCH в секундах), разделенное на 60. "Шаг" валидности тега составляет 1 минуту.
Валидация (Drift Tolerance): При проверке входящего тега сервер вычисляет собственный current_step. Для компенсации рассинхронизации времени и сетевых задержек проверяется окно в ±2 шага (около 5 минут в обе стороны).
Отсев и разрыв: Если рассчитанный тег не совпадает с полученным (или окно устарело), пакет немедленно отбрасывается, а соединение закрывается. DPI не может "переиграть" захваченный ранее пакет.
Рандомизация длины: Паддинг генерируется рандомно для каждого кадра, что исключает статистический анализ длины сообщений.

4. Виртуальный сетевой стек и перехват (Client-Side)

Клиентская часть реализует прозрачный захват трафика на сетевом уровне (L3), работая не как обычный SOCKS-прокси, а как полноценный VPN-клиент.

TUN-интерфейс & Маршрутизация (nftables): Исходящий трафик заворачивается в виртуальный интерфейс (например, netr0) с помощью правил ОС.
Userspace Network Stack (smoltcp): Для разбора перехваченного L3-трафика используется smoltcp.
- TCP: Берет на себя управление стейт-машиной TCP-соединений, собирая IP-пакеты в непрерывные потоки данных.
- UDP Session Tracking: Для UDP-трафика реализован собственный менеджер сессий (NAT-таблица), привязывающий пару (Source IP, Source Port) к внутреннему обработчику с механизмом таймаута активности.
Event Loop: Главный цикл постоянно опрашивает TUN-интерфейс, скармливает сырые пакеты в smoltcp и извлекает полезную нагрузку L4 для отправки в туннель.

5. Асинхронное ядро и Менеджмент потоков (Tokio)

Связка синхронного сетевого стека (smoltcp) и асинхронного туннеля требует строгой оркестровки через tokio.

MPSC Каналы: Для каждого перехваченного соединения создается уникальный Stream ID. Данные из smoltcp передаются в асинхронные воркеры через очереди сообщений.
Мультиплексор (Muxer): Упаковывает множество потоков данных из каналов в единое TLS-соединение. Формирует кадры (Frame), шифрует их и отправляет на сервер.
Демультиплексор (Demuxer): Принимает данные от сервера, расшифровывает, проверяет Auth Tag и по Stream ID маршрутизирует ответы обратно в нужный канал, чтобы smoltcp сформировал валидный IP-пакет для TUN-интерфейса.

6. Движок маскировки DPI (TLS Fingerprinting)

Для обхода современных систем глубокого анализа трафика (DPI) используется модуль tlseng.

Имитация браузеров: Модуль гарантирует, что структура первого пакета сессии (ClientHello) в точности повторяет отпечатки популярных веб-браузеров (Chrome, Firefox).
Структура ClientHello: Подменяются списки поддерживаемых Cipher Suites, порядок расширений (ALPN, SNI, Supported Groups, Key Share) и их содержимое. Это заставляет системы DPI классифицировать туннель как обычный HTTPS веб-серфинг.

7. Кроссплатформенная интеграция (FFI & Android)

Ядро (Core) на Rust полностью отделено от платформозависимого интерфейса для обеспечения портируемости.

Нативные библиотеки: Код компилируется в динамические библиотеки (.so) для различных архитектур (arm64-v8a, armeabi-v7a, x86_64) через cargo-ndk.
Генерация биндингов: Инструмент bindgen-tool (на базе UniFFI) автоматически генерирует JNI-обертки и Kotlin-код. Это позволяет Android-приложению управлять состоянием туннеля, безопасно вызывая нативные функции Rust без необходимости ручного написания boilerplate-кода.

9.6 KiB Raw Blame History