# Middle-End Proxy

## KDF Addressing — FAQ по реализации

### Требует ли C-референсная реализация KDF внешний IP и порт?

**Да**

В C-референсе **в KDF участвуют и IP-адрес, и порт** — с обеих сторон соединения.

В `aes_create_keys()` в строку KDF входят:

- `server_ip + client_port`
- `client_ip + server_port`
- далее secret / nonces

Для IPv6:

- IPv4-поля заполняются нулями
- добавляются IPv6-адреса

Однако **порты client_port и server_port всё равно участвуют в KDF**.

> Если внешний IP или порт (например, из-за NAT, SOCKS или прокси) не совпадает с ожидаемым другой стороной — ключи расходятся и handshake ломается.

---

### Можно ли исключить порт из KDF (например, установив порт = 0)?

**Нет.**

В C-референсе **нет механики отключения порта**.

- `client_port` и `server_port` явно включены в KDF
- Передаются реальные порты сокета:
  - `c->our_port`
  - `c->remote_port`

Если порт равен `0`, он всё равно попадёт в KDF как `0`.

Отдельной логики «игнорировать порт» не предусмотрено.

### Как Telemt выбирает исходный адрес KDF при SOCKS?

Корректные публичные SOCKS `BND.ADDR/BND.PORT` с ненулевым портом задают полный исходный кортеж KDF и имеют приоритет над настроенными или обнаруженными NAT-данными. Семейство должно совпадать с логическим ME-назначением, независимо от семейства TCP-соединения к SOCKS. IPv4-mapped IPv6 назначения считаются IPv4 и требуют обычного IPv4 BND; IPv4-compatible назначения остаются IPv6. `strict` отклоняет отсутствующий или некорректный BND, `compat` сохраняет прежний fallback. Поля и порты KDF, кодирование назначения SOCKS CONNECT, проверка публичного адреса и STUN не меняются.