# 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. Алгоритм работы протокола 1. **ClientHello:** Клиент генерирует ключи и отправляет замаскированный запрос. 2. **ServerHello:** Сервер отвечает, завершая обмен ключами. 3. **Обновление ключей:** Инициализация ключей сессии (ChaChaCipher). 4. **Упаковка данных:** Шифрование `Frame` целиком (включая заголовок, payload и padding). 5. **Транспорт:** Отправка зашифрованного буфера в запись `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-кода.