8.6 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).

Маршрутизация исключений (Bypass / Exclusions)

Для снижения задержек и оптимизации трафика клиент OSTP поддерживает механизм прямых подключений в обход туннеля. Настройка производится в блоке "exclude" конфигурационного файла config.json:

domains: Список доменных имен (например, ["trusted-site.com", "yandex.ru"]). Любой запрос к этим доменам или их поддоменам направляется напрямую через системный шлюз провайдера.
ips: Список диапазонов IP-адресов в формате CIDR (например, ["192.168.1.0/24", "10.0.0.0/8"]). Полезно для доступа к ресурсам локальной сети.
processes: Список имен исполняемых файлов процессов ОС (например, ["discord.exe", "steam.exe"]), чьи сетевые запросы должны игнорировать VPN.

[!NOTE] Механизм исключений полностью отлажен и готов к промышленной эксплуатации, обеспечивая нулевые задержки для доверенных ресурсов.

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

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

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

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

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

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

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

8.6 KiB Raw Blame History Unescape Escape