mirror of https://github.com/ospab/ostp.git
95 lines
8.9 KiB
Markdown
95 lines
8.9 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`).
|
||
|
||
---
|
||
|
||
## Модульная архитектура маршрутизации (Inbounds / Outbounds)
|
||
|
||
Начиная с версии `0.3.1`, клиент OSTP использует модульную архитектуру конфигурации на базе массивов точек входа и выхода, аналогичную Xray или Sing-box.
|
||
|
||
- **`inbounds` (Входящие точки)**: Определяет, как локальный трафик попадает в клиент. Поддерживаются типы `tun` (создание виртуального интерфейса) и `local_proxy` (SOCKS5/HTTP прокси).
|
||
- **`outbounds` (Исходящие точки)**: Определяет, куда клиент отправляет трафик. Основной тип — `ostp` (инкапсуляция и отправка на сервер), но также поддерживаются `direct` (прямое подключение к интернету в обход VPN) и `block` (блокировка трафика).
|
||
- **`routing` (Правила маршрутизации)**: Механизм, заменяющий старый блок `exclude`. Позволяет гибко перенаправлять трафик.
|
||
|
||
Пример правила маршрутизации в `config.json`:
|
||
```json
|
||
"routing": {
|
||
"rules": [
|
||
{
|
||
"domain_suffix": ["trusted-site.com", "local.lan"],
|
||
"outbound": "direct"
|
||
}
|
||
],
|
||
"default_outbound": "proxy"
|
||
}
|
||
```
|
||
|
||
> [!NOTE]
|
||
> Такая архитектура позволяет подключать клиента сразу к нескольким серверам OSTP, разделять трафик по доменам или блокировать телеметрию на уровне роутера VPN.
|
||
|
||
---
|
||
|
||
## Мультиплексирование и известные ограничения (Mux Sessions)
|
||
|
||
Протокол закладывает возможность объединения нескольких физических UDP-сессий в единый логический мультиплексированный туннель через параметр `"mux"`:
|
||
|
||
```json
|
||
"mux": {
|
||
"enabled": false,
|
||
"sessions": 1
|
||
}
|
||
```
|
||
|
||
### Текущие аппаратные ограничения:
|
||
> [!WARNING]
|
||
> **На данный момент мультиплексирование более чем 1 сессии (`sessions > 1`) НЕ РАБОТАЕТ.**
|
||
>
|
||
> **Симптомы проблемы:**
|
||
> При установке 3 и более сессий клиент успешно проходит этапы рукопожатия (в логах отображается `Connected UDP directly to...` для каждой сессии), а сервер подтверждает корректное состояние соединения. Однако на этапе демультиплексирования полезной нагрузки на сервере передача данных прерывается, и пользовательский трафик полностью пропадает.
|
||
>
|
||
> **Временное решение:**
|
||
> Обязательно выключайте мультиплексирование (`"enabled": false`) или жестко ограничивайте число сессий до **1** (`"sessions": 1`).
|