mirror of https://github.com/ospab/ostp.git
82 lines
8.6 KiB
Markdown
82 lines
8.6 KiB
Markdown
# Клиентский демон 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) используется строгий паттерн «выравнивания портов»:
|
||
1. **Единый сокет**: Клиент инициализирует ровно один экземпляр `UdpSocket`.
|
||
2. **STUN/TURN Дискавери**: Используя этот же сокет, клиент отправляет запросы на STUN или выполняет аутентифицированную аллокацию по протоколу TURN (RFC 5766) с вычислением `HMAC-SHA1` и `MD5` дайджестов.
|
||
3. **Сохранение трансляции**: После получения внешних рефлексивных координат, передача данных 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"`:
|
||
|
||
```json
|
||
"mux": {
|
||
"enabled": false,
|
||
"sessions": 1
|
||
}
|
||
```
|
||
|
||
### Текущие аппаратные ограничения:
|
||
> [!WARNING]
|
||
> **На данный момент мультиплексирование более чем 1 сессии (`sessions > 1`) НЕ РАБОТАЕТ.**
|
||
>
|
||
> **Симптомы проблемы:**
|
||
> При установке 3 и более сессий клиент успешно проходит этапы рукопожатия (в логах отображается `Connected UDP directly to...` для каждой сессии), а сервер подтверждает корректное состояние соединения. Однако на этапе демультиплексирования полезной нагрузки на сервере передача данных прерывается, и пользовательский трафик полностью пропадает.
|
||
>
|
||
> **Временное решение:**
|
||
> Обязательно выключайте мультиплексирование (`"enabled": false`) или жестко ограничивайте число сессий до **1** (`"sessions": 1`).
|