8.9 KiB

Raw Blame History

Клиентский демон OSTP

Обзор

Клиент OSTP работает как автономный системный демон (или сервис), отвечающий за высокопроизводительный захват локального трафика приложения, инкапсуляцию в протокол с обфускацией и поддержание отказоустойчивого туннеля к серверу OSTP.

Модули перехвата трафика (Traffic Ingestion)

Для максимальной гибкости и совместимости клиент поддерживает три ключевых механизма перехвата:

1. Двухрежимный локальный прокси (Dual-Protocol Proxy)

Встроенный прокси-сервер слушает один TCP-порт и динамически определяет входящий протокол по первому байту соединения:

SOCKS5 (RFC 1928): Активируется, если первый байт равен 0x05. Передает данные в стандартном режиме туннелирования TCP-потоков.
HTTP Forward Proxy: Если первый байт отличается от 0x05, запрос парсится как стандартный HTTP. Клиент поддерживает:
- Метод CONNECT host:port для установки защищенного сквозного TLS-туннеля.
- Метод GET http://... для прозрачной проксификации стандартных веб-запросов.

2. Системный прокси Windows (Sysproxy Integration)

Для обеспечения работы без дополнительной настройки клиент автоматически модифицирует настройки прокси операционной системы Windows через системный реестр (WinINet):

Строка адреса пишется в строгом формате, ожидаемом современными браузерами (Chrome, Edge, Firefox): http=127.0.0.1:1088;https=127.0.0.1:1088
При остановке демона настройки корректно откатываются в исходное состояние, исключая обрыв интернета у пользователя.

3. Виртуальный сетевой интерфейс (TUN/Wintun)

На системах Windows и Linux клиент умеет запускать виртуальный TUN-адаптер (на базе драйвера Wintun):

Перехватывает весь трафик на уровне Layer 3 (сырые IP-пакеты).
Встроенный легковесный TCP/IP стек восстанавливает сеансовые TCP-потоки и направляет их внутрь мультиплексированного туннеля OSTP, обеспечивая полную глобальную маршрутизацию системы без ручной настройки прокси в приложениях.

Обход NAT (Port-Aligned NAT Discovery)

Для успешной доставки UDP-пакетов через вложенные фаерволы провайдеров (Symmetric/Port-Restricted NAT) используется строгий паттерн «выравнивания портов»:

Единый сокет: Клиент инициализирует ровно один экземпляр UdpSocket.
STUN/TURN Дискавери: Используя этот же сокет, клиент отправляет запросы на STUN или выполняет аутентифицированную аллокацию по протоколу TURN (RFC 5766) с вычислением HMAC-SHA1 и MD5 дайджестов.
Сохранение трансляции: После получения внешних рефлексивных координат, передача данных OSTP к серверу идет через тот же самый сокет. Фаерволы видят это как единую легитимную UDP-сессию, пропуская обратный трафик сервера без блокировок.

Логика отказоустойчивости и переподключения

Клиент спроектирован так, чтобы не требовать вмешательства пользователя при сбоях сети:

Вечное автопереподключение: Событие UiEvent::TunnelStopped в управляющем цикле runner.rs автоматически ставит туннель в очередь на повторный запуск через фиксированный интервал в 5 секунд. Эта цепочка не имеет лимитов на количество попыток (infinite loop) до тех пор, пока пользователь принудительно не остановит службу.
Фильтрация шума в логах: Рутинные ошибки сетевых сокетов, такие как ConnectionReset, BrokenPipe или UnexpectedEof, подавляются логикой репортера и не спамят в консоль, фиксируя состояние только при реальных переходах статуса (Idle -> Connecting -> Connected).

Модульная архитектура маршрутизации (Inbounds / Outbounds)

Начиная с версии 0.3.1, клиент OSTP использует модульную архитектуру конфигурации на базе массивов точек входа и выхода, аналогичную Xray или Sing-box.

inbounds (Входящие точки): Определяет, как локальный трафик попадает в клиент. Поддерживаются типы tun (создание виртуального интерфейса) и local_proxy (SOCKS5/HTTP прокси).
outbounds (Исходящие точки): Определяет, куда клиент отправляет трафик. Основной тип — ostp (инкапсуляция и отправка на сервер), но также поддерживаются direct (прямое подключение к интернету в обход VPN) и block (блокировка трафика).
routing (Правила маршрутизации): Механизм, заменяющий старый блок exclude. Позволяет гибко перенаправлять трафик.

Пример правила маршрутизации в config.json:

"routing": {
  "rules": [
    {
      "domain_suffix": ["trusted-site.com", "local.lan"],
      "outbound": "direct"
    }
  ],
  "default_outbound": "proxy"
}

[!NOTE] Такая архитектура позволяет подключать клиента сразу к нескольким серверам OSTP, разделять трафик по доменам или блокировать телеметрию на уровне роутера VPN.

Мультиплексирование и известные ограничения (Mux Sessions)

Протокол закладывает возможность объединения нескольких физических UDP-сессий в единый логический мультиплексированный туннель через параметр "mux":

"mux": {
  "enabled": false,
  "sessions": 1
}

Текущие аппаратные ограничения:

[!WARNING] На данный момент мультиплексирование более чем 1 сессии (sessions > 1) НЕ РАБОТАЕТ.

Симптомы проблемы: При установке 3 и более сессий клиент успешно проходит этапы рукопожатия (в логах отображается Connected UDP directly to... для каждой сессии), а сервер подтверждает корректное состояние соединения. Однако на этапе демультиплексирования полезной нагрузки на сервере передача данных прерывается, и пользовательский трафик полностью пропадает.

Временное решение: Обязательно выключайте мультиплексирование ("enabled": false) или жестко ограничивайте число сессий до 1 ("sessions": 1).

8.9 KiB Raw Blame History Unescape Escape