mirror of https://github.com/ospab/ostp.git
81 lines
9.9 KiB
Markdown
81 lines
9.9 KiB
Markdown
# Системная архитектура OSTP
|
||
|
||
## Обзор
|
||
Obfuscated Secure Transport Protocol (OSTP) — это высокопроизводительный асинхронный фреймворк сетевого туннелирования, разработанный для обеспечения безопасной, устойчивой и нераспознаваемой передачи данных в недоверенных сетях. Проект написан на Rust, гарантируя безопасность памяти, высокую конкурентность и минимальные накладные расходы.
|
||
|
||
---
|
||
|
||
## Принцип Керкгоффса и устойчивость к DPI (Kerckhoffs's Principle)
|
||
|
||
Архитектура OSTP строго следует **Принципу Керкгоффса**: система должна оставаться безопасной, даже если все о ней, кроме ключа, является общедоступным знанием.
|
||
Весь исходный код алгоритмов шифрования и обфускации полностью открыт. Безопасность и нераспознаваемость трафика базируются исключительно на секретности предварительно согласованного ключа (`access_key` / PSK).
|
||
|
||
Благодаря криптографическим преобразованиям с использованием этого ключа (Noise Protocol + ChaCha20Poly1305 + Blake2s) и адаптивному паддингу, каждый пакет передаваемых данных визуально неотличим от абсолютно случайного белого шума.
|
||
Протокол не имеет статических заголовков или "рукопожатий" в открытом виде. Это делает невозможным для систем глубокого анализа трафика (DPI), таких как ТСПУ Роскомнадзора, создать статический фильтр или сигнатуру для блокировки OSTP за считанные минуты. Блокировка протокола потребовала бы либо полной блокировки всего неизвестного UDP-трафика (что нарушает работу многих легитимных сервисов), либо знания секретного ключа.
|
||
|
||
---
|
||
|
||
## Структура проекта
|
||
Проект состоит из следующих специализированных модулей (crates):
|
||
1. **ostp-core**: Основа протокола. Содержит конечные автоматы состояний, реализацию рукопожатия (Noise Protocol Framework), механизмы сериализации кадров (framing), алгоритмы обфускации и логику надежной доставки пакетов (ARQ).
|
||
2. **ostp-client**: Клиентский демон. Управляет конфигурацией маршрутизации через массивы входящих (`inbounds`, например, SOCKS5, TUN) и исходящих (`outbounds`, например, OSTP, direct) соединений. Выполняет мультиплексирование потоков и взаимодействие с TURN для обхода NAT.
|
||
3. **ostp-server**: Высоконагруженный диспетчер соединений, отвечающий за демультиплексирование данных от множества сессий, прозрачный роуминг адресов и проксирование трафика в интернет.
|
||
4. **ostp-obfuscator**: Утилиты для статического шейпинга трафика и генерации динамических ключей маскировки.
|
||
5. **ostp-jni**: Нативный SDK для интеграции в мобильные платформы Android.
|
||
6. **ostp**: Единый исполняемый файл командной строки (CLI), который запускает систему в режиме сервера или клиента.
|
||
|
||
---
|
||
|
||
## Формат кадра и структура данных (Framing)
|
||
|
||
Весь трафик OSTP разбивается на логические кадры перед отправкой в зашифрованном виде. Спецификация заголовка кадра (`FrameHeader`) имеет фиксированный размер **12 байт**:
|
||
|
||
| Смещение (байт) | Тип данных | Имя поля | Описание |
|
||
| :--- | :--- | :--- | :--- |
|
||
| 0 | `u8` | `version` | Версия протокола (текущая: `1`) |
|
||
| 1 | `u8` | `kind` | Тип кадра (см. таблицу ниже) |
|
||
| 2 | `u8` | `flags` | Служебные флаги управления потоком |
|
||
| 3 | `u8` | *резерв* | Зарезервировано для будущего использования (0) |
|
||
| 4-5 | `u16 BE` | `stream_id` | Логический идентификатор мультиплексированного потока |
|
||
| 6-9 | `u32 BE` | `payload_len` | Длина полезной нагрузки в байтах |
|
||
| 10-11 | `u16 BE` | `pad_len` | Длина адаптивного паддинга в байтах |
|
||
|
||
### Типы кадров (`FrameKind`):
|
||
- `1 - Handshake`: Обмен ключевой информацией (Noise Handshake Payload).
|
||
- `2 - Data`: Передача зашифрованных прикладных данных.
|
||
- `3 - Close`: Сигнализация закрытия сессии или конкретного потока.
|
||
- `4 - KeepAlive`: Пакет поддержания активности соединения.
|
||
- `5 - Nack`: Запрос на немедленную повторную передачу потерянного кадра.
|
||
- `6 - Ack`: Подтверждение успешного получения диапазонов кадров.
|
||
|
||
Полный пакет (`FramedPacket`) кодируется по схеме:
|
||
`[12 байт FrameHeader]` + `[N байт Payload]` + `[M байт Padding]`
|
||
|
||
---
|
||
|
||
## Механизм надежной доставки (Reliable ARQ System)
|
||
|
||
Для обеспечения гарантированной доставки данных поверх ненадежного UDP-туннеля в `ostp-core` реализована селективная система автоматического запроса повторной передачи (Selective Repeat ARQ):
|
||
|
||
1. **Нумерация кадров**: Каждому отправляемому кадру данных присваивается строго возрастающий 64-битный счетчик (`nonce`), используемый также в качестве вектора инициализации для AEAD-шифра.
|
||
2. **Буферизация отправки (`sent_history`)**: Отправленные датаграммы кэшируются до тех пор, пока от удаленной стороны не придет подтверждение (`Ack`). При превышении порога `max_sent_history` старые кадры вытесняются.
|
||
3. **Быстрый путь повторной отправки (Fast-Path Nack)**:
|
||
- При обнаружении "пробела" в номерах входящих пакетов, принимающая сторона немедленно генерирует и отправляет кадр `Nack`, содержащий номер пропущенного пакета (`expected_recv_nonce`).
|
||
- Отправитель, получив `Nack`, немедленно извлекает кадр из истории и выполняет повторную передачу, минуя стандартный цикл тайм-аутов.
|
||
4. **Тайм-аут повторной передачи (RTO / Tick)**:
|
||
- Каждые несколько миллисекунд запускается событие `OstpEvent::Tick`.
|
||
- Любой неподтвержденный пакет, время нахождения в пути которого превышает `rto_ms`, отправляется повторно, увеличивая счетчик `retries`.
|
||
5. **Сборка out-of-order пакетов (`reorder_buffer`)**:
|
||
- Пакеты, пришедшие не по порядку, помещаются в упорядоченное B-дерево.
|
||
- Как только пропущенные пакеты получены, буфер «проливается», передавая непрерывную последовательность данных вышестоящему приложению.
|
||
|
||
---
|
||
|
||
## Бесшовный роуминг (Dynamic Roaming)
|
||
|
||
OSTP спроектирован для мобильных сценариев. Соединение привязано не к паре IP:Порт, а к уникальному криптографическому идентификатору сессии (`session_id`), согласованному во время рукопожатия.
|
||
Когда клиент переключается с мобильного интернета на Wi-Fi:
|
||
1. Новые пакеты отправляются с нового IP/порта, сохраняя текущий `session_id` и криптографический контекст.
|
||
2. Сервер успешно дешифрует пакет, сопоставляет его с сессией в `O(1)`-`O(N)` таблице и моментально перенаправляет обратный трафик на новый адрес источника.
|
||
3. Пользовательские TCP-соединения внутри туннеля не прерываются.
|