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