Files
netrunner-proxy/ARCH.md
T

95 lines
9.6 KiB
Markdown

# 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-кода.