# Клиентский демон 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`).