8.0 KiB
Системная архитектура OSTP
Обзор
Obfuscated Secure Transport Protocol (OSTP) — это высокопроизводительный асинхронный фреймворк сетевого туннелирования, разработанный для обеспечения безопасной, устойчивой и нераспознаваемой передачи данных в недоверенных сетях. Проект написан на Rust, гарантируя безопасность памяти, высокую конкурентность и минимальные накладные расходы.
Структура проекта
Проект состоит из следующих специализированных модулей (crates):
- ostp-core: Основа протокола. Содержит конечные автоматы состояний, реализацию рукопожатия (Noise Protocol Framework), механизмы сериализации кадров (framing), алгоритмы обфускации и логику надежной доставки пакетов (ARQ).
- ostp-client: Клиентский демон, управляющий перехватом трафика хоста через двухрежимный SOCKS5/HTTP-прокси или виртуальные адаптеры (TUN/Wintun), мультиплексированием потоков в единый UDP-туннель и взаимодействием с TURN для обхода NAT.
- ostp-server: Высоконагруженный диспетчер соединений, отвечающий за демультиплексирование данных от множества сессий, прозрачный роуминг адресов и проксирование трафика в интернет.
- ostp-obfuscator: Утилиты для статического шейпинга трафика и генерации динамических ключей маскировки.
- ostp-jni: Нативный SDK для интеграции в мобильные платформы Android.
- 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):
- Нумерация кадров: Каждому отправляемому кадру данных присваивается строго возрастающий 64-битный счетчик (
nonce), используемый также в качестве вектора инициализации для AEAD-шифра. - Буферизация отправки (
sent_history): Отправленные датаграммы кэшируются до тех пор, пока от удаленной стороны не придет подтверждение (Ack). При превышении порогаmax_sent_historyстарые кадры вытесняются. - Быстрый путь повторной отправки (Fast-Path Nack):
- При обнаружении "пробела" в номерах входящих пакетов, принимающая сторона немедленно генерирует и отправляет кадр
Nack, содержащий номер пропущенного пакета (expected_recv_nonce). - Отправитель, получив
Nack, немедленно извлекает кадр из истории и выполняет повторную передачу, минуя стандартный цикл тайм-аутов.
- При обнаружении "пробела" в номерах входящих пакетов, принимающая сторона немедленно генерирует и отправляет кадр
- Тайм-аут повторной передачи (RTO / Tick):
- Каждые несколько миллисекунд запускается событие
OstpEvent::Tick. - Любой неподтвержденный пакет, время нахождения в пути которого превышает
rto_ms, отправляется повторно, увеличивая счетчикretries.
- Каждые несколько миллисекунд запускается событие
- Сборка out-of-order пакетов (
reorder_buffer):- Пакеты, пришедшие не по порядку, помещаются в упорядоченное B-дерево.
- Как только пропущенные пакеты получены, буфер «проливается», передавая непрерывную последовательность данных вышестоящему приложению.
Бесшовный роуминг (Dynamic Roaming)
OSTP спроектирован для мобильных сценариев. Соединение привязано не к паре IP:Порт, а к уникальному криптографическому идентификатору сессии (session_id), согласованному во время рукопожатия.
Когда клиент переключается с мобильного интернета на Wi-Fi:
- Новые пакеты отправляются с нового IP/порта, сохраняя текущий
session_idи криптографический контекст. - Сервер успешно дешифрует пакет, сопоставляет его с сессией в
O(1)-O(N)таблице и моментально перенаправляет обратный трафик на новый адрес источника. - Пользовательские TCP-соединения внутри туннеля не прерываются.