# Маскировка MEDIA — принцип работы и параметры

## 1. Что это

MEDIA — режим маскировки, при котором трафик между двумя обфускаторами во внешней сети
выглядит как **непрерывный медиапоток RTP/H.264 поверх UDP** (видеозвонок или просмотр стрима).
Цель — чтобы системы глубокого анализа трафика (DPI) видели «видео», а не WireGuard/VPN.

Важно: это **маскировка, а не шифрование**. Конфиденциальность и целостность данных
обеспечивает сам WireGuard. Задача MEDIA — спрятать факт использования WireGuard.

---

## 2. Принцип работы

### Топология

```
Устройство (WireGuard)
      │  обычный трафик WireGuard
      ▼
Клиентский обфускатор  ──────────────►  Серверный обфускатор
      (маскирует под RTP/видео)   внешняя       (снимает маскировку)
                                    сеть / DPI          │
                                                         ▼
                                              WireGuard-сервер
```

- WireGuard на устройстве отправляет свои пакеты не напрямую в интернет, а локальному
  **клиентскому обфускатору**.
- Клиентский обфускатор маскирует их под медиапоток и шлёт **серверному обфускатору** по сети.
- Серверный обфускатор снимает маскировку и отдаёт обычный WireGuard локальному WireGuard-серверу.
- Ответы идут тем же путём в обратную сторону.

Параметры маскировки заданы заранее с обеих сторон — рукопожатий и «приветствий» уровня
VPN/прокси во внешней сети нет.

### Что происходит с каждым пакетом

1. **Старт сессии — фаза STUN/ICE.** Первые пакеты выглядят как проверка связности STUN
   (как в WebRTC перед видеозвонком). Это делает появление последующего RTP-потока
   правдоподобным. В простое периодически отправляются такие же STUN-сообщения
   (имитация keepalive-проверок WebRTC и поддержание NAT).

2. **Передача данных — RTP-пакеты.** Каждый пакет получает 12-байтовый RTP-заголовок:
   - версия RTP (2),
   - payload type (тип «кодека»),
   - sequence number (монотонно растёт),
   - timestamp (растёт по «частоте кадров»),
   - SSRC (идентификатор потока, постоянный в пределах сессии).
   После заголовка — полезная нагрузка (зашифрованный WireGuard).

3. **Сокрытие сигнатуры WireGuard.** У WireGuard опознаваемы первые байты пакета
   (тип сообщения и нулевые служебные байты). Они скрываются «частичным шифрованием» —
   обратимым преобразованием первых нескольких байт. Остальная часть пакета WireGuard
   и так выглядит как случайные данные, поэтому шифровать её целиком не нужно
   (это экономит ресурсы процессора).

### Что видит DPI

На внешнем участке — поток UDP-пакетов с корректным RTP-заголовком: растущие sequence number
и timestamp, постоянный SSRC, правдоподобный payload type, в начале — STUN/ICE-сигнализация.
Это соответствует картине видеозвонка/стрима, а не VPN.

### Ограничения

Продвинутый DPI со статистическим/энтропийным анализом может заметить, что «содержимое видео»
по статистике похоже на шифрование (полезная нагрузка WireGuard — равномерно случайная).
MEDIA рассчитан на массовый DPI, который классифицирует по заголовкам, портам и поведению,
а не на целевой статистический анализ конкретного потока.

---

## 3. Параметры

Параметры задаются в конфигурации инстанса.

| Параметр | Значения | По умолчанию | Назначение |
|----------|----------|--------------|------------|
| `masking` | `MEDIA` | — | включение режима MEDIA |
| `key` | строка 1–255 символов | — | ключ обфускации (преобразование, скрывающее сигнатуру WireGuard) |
| `obfuscate-bytes` | `0` или число байт | `16` для MEDIA | сколько первых байт пакета преобразовывать. `0` = весь пакет. Минимум для MEDIA — `4` (этого хватает, чтобы скрыть сигнатуру WireGuard); больше — лишняя нагрузка |
| `max-dummy` | `0`…`1024` | — | размер случайной добавки к пакету. **В режиме MEDIA не действует** (частичное преобразование её отключает) |
| `media-pt` | `0` или `96`–`127` | `0` | RTP payload type («тип кодека»). `0` = случайный из набора типовых H.264-комбинаций на каждое подключение |
| `media-ssrc` | `0` или число (hex/dec) | `0` | RTP SSRC (идентификатор потока). `0` = случайный на каждое подключение, свой в каждую сторону |
| `media-clock` | `0` или `1`–`1000` (fps) | `0` | «частота кадров» для шага RTP timestamp. `0` = случайная из набора пресетов |
| `verbose` | `error`/`warn`/`info`/`debug`/`trace` | `info` | уровень логирования |

### Подробнее о значениях

- **`media-pt = 0`, `media-clock = 0`, `media-ssrc = 0` (значения по умолчанию)** — обфускатор
  на каждое подключение случайно выбирает один из ~50 заранее заготовленных пресетов
  типовых H.264-комбинаций (payload type + частота кадров) и случайные SSRC/sequence
  number/timestamp. Это снижает узнаваемость и мешает построению «слепка» паттерна
  анализом трафика. В этом режиме **согласование с сервером не требуется** — стороны
  выбирают значения независимо.

- **Ненулевые `media-pt` / `media-ssrc`** — фиксированные («статические») значения с проверкой
  на приёме. В этом случае значение **должно быть одинаковым на обеих сторонах**, иначе
  обратное направление будет отклонено.

- **`media-clock`** приёмником не проверяется никогда — задаёт лишь скорость роста timestamp.
  Согласование не требуется ни при каком значении.

- **`verbose`** на боевой работе — `error`. Уровни `debug`/`trace` выводят дамп каждого пакета
  и резко повышают нагрузку на процессор.

### Влияние на ресурсы

- На нагрузку процессора влияют `obfuscate-bytes` (объём преобразования) и `verbose`.
- `media-pt`, `media-ssrc`, `media-clock` на нагрузку и на размер пакета **не влияют** — это
  лишь значения полей фиксированного 12-байтного RTP-заголовка.
- Накладные расходы на маскировку — фиксированные **12 байт на пакет** (RTP-заголовок).

---

## 4. Что должно совпадать на обеих сторонах

Обязательно одинаковые:
- `key`;
- `obfuscate-bytes`;
- `masking = MEDIA`.

Должны совпадать **только если заданы статически** (ненулевыми):
- `media-pt`;
- `media-ssrc`.

Согласование не требуется (можно оставить по умолчанию / случайными): `media-pt`, `media-ssrc`,
`media-clock`, `verbose`, а также сетевые параметры подключения каждой стороны.

Правило: для `media-pt` и `media-ssrc` используйте либо `0` на обеих сторонах (случайно),
либо одно и то же ненулевое значение. Не смешивайте.

---

## 5. Пример

### Клиент (на устройстве/роутере)
```ini
[client]
source-lport = 13800            # сюда указывает Endpoint WireGuard-интерфейса (127.0.0.1:13800)
target = SERVER_IP:13255        # публичный адрес серверного обфускатора
key = <общий ключ>
masking = MEDIA
obfuscate-bytes = 4
max-dummy = 0
verbose = error
# media-pt / media-ssrc / media-clock не заданы = случайные (рекомендуется)
```

### Сервер
```ini
[server]
source-lport = 13255            # публичный порт приёма маскированного трафика
target = 127.0.0.1:51820        # локальный WireGuard-сервер
key = <тот же ключ>
masking = MEDIA
obfuscate-bytes = 4
max-dummy = 0
verbose = error
```

WireGuard-клиент на устройстве должен иметь `Endpoint = 127.0.0.1:13800`,
WireGuard-сервер слушает `127.0.0.1:51820`.

---

## 6. Эксплуатационные замечания

- **Выход в интернет через VPN (полный туннель):** на стороне сервера должны быть включены
  IP-форвардинг и NAT (маскарадинг) для туннельной подсети. Без этого рукопожатие пройдёт,
  но реальных данных в интернет не будет.
- **MTU:** маскировка добавляет 12 байт (RTP) к каждому пакету. Если часть сайтов грузится
  частично — уменьшите MTU WireGuard-интерфейса (ориентир: ~1400 при сетевом MTU 1500).
- **Снижение нагрузки на процессор без потери маскировки:** `verbose = error`,
  `obfuscate-bytes = 4`, `max-dummy = 0`, по возможности повысить MTU (меньше пакетов при
  той же скорости).