# SNI-маршрутизация в xray-core / sing-box + TLS-fronting

## Термины (в контексте этого кейса)

- **TLS-fronting домен** — домен, который фигурирует в TLS ClientHello как **SNI** (например, `petrovich.ru`): он используется как "маска" на L7 и как ключ маршрутизации в прокси-роутере.
- **xray-core / sing-box** — локальный или удалённый L7/TLS-роутер (прокси), который:
  1) принимает входящее TCP/TLS-соединение,
  2) читает TLS ClientHello,
  3) извлекает SNI,
  4) по SNI выбирает outbound/апстрим,
  5) устанавливает новое TCP-соединение к целевому хосту уже **от себя**.
- **SNI (Server Name Indication)** — поле в TLS ClientHello, где клиент Telegram сообщает доменное имя для "маскировки"
- **DNS-resolve на стороне L7-роутера** — если выходной адрес задан доменом (или роутер решил "всё равно идти по SNI"), то DNS резолвится **на стороне xray/sing-box**, а не на стороне Telegram-клиента

---

## Ключевая идея: куда на самом деле идёт соединение решает не то, что вы указали клиенту, а то как L7-роутер трактует SNI

Механика:

1) Telegram-клиенту вы можете указать **IP/домен telemt**,как "сервер".
2) Между клиентом и telemt стоит xray-core/sing-box, который принимает TCP, читает TLS ClientHello и видит **SNI=petrovich.ru**
3) Дальше роутер говорит: "Вижу SNI - направить на апстрим/маршрут N"
4) И устанавливает исходящее соединение не "по тому IP, который пользователь подразумевал", а **по домену из SNI** (или по сопоставлению SNI→outbound), используя для определния его IP собственный DNS-кеш или резолвер
5) `petrovich.ru` по A-записи указывает **не на IP telemt**, а значит при L7-маршрутизации трафик уйдёт на "оригинальный" сайт за этим доменом, а не в telemt: Telegram-клиент, естественно, не сможет получить ожидаемое поведение, потому что ответить с handshake на той стороне некому

---

## Схема №1 "Как это НЕ работает"

```text
Telegram Client
   |
   |  (указан IP/домен telemt)
   v
telemt instance
````

Ожидание: "я указал telemt -> значит трафик попадёт в telemt" - **нет!**

---

## Схема №2. "Как это реально работает с TLS/L7-роутером и SNI"

```text
Telegram Client
   |
   | 1) TCP/TLS connection: 
   |    - ClientHello: 
   |      - SNI=petrovich.ru
   v
xray-core / sing-box / любой L7 router
   |
   | 2) читает ClientHello -> вытаскивает SNI
   | 3) выбирает маршрут по SNI
   | 4) делает DNS для petrovich.ru 
   | 5) подключается к полученному IP по TLS с этим SNI
   v
"Оригинальный" сайт, A-запись которого не на telemt
   |
   X  не telemt -> Telegram-клиент не коннектится как ожидалось
```

---

## Почему указанный в клиенте IP/домен telemt "не спасает"

Потому что в таком режиме xray/sing-box выступает как **точка терминации TCP/TLS**, можно сказать - TLS-инспектор на уровне ClientHello, это означает:

* TCP-сессия от Telegram-клиента заканчивается на xray/sing-box
* Дальше создаётся **новая** TCP-сессия "от имени" xray/sing-box к апстриму
* Выбор апстрима делается правилами роутинга, а в TLS-сценариях самый удобный и распространённый ключ — **SNI**

То есть, "куда идти дальше" определяется логикой L7-роутера:

* либо правилами вида `if SNI == petrovich.ru -> outbound X`,
* либо более "автоматическим" поведением: `подключаться к тому хосту, который указан в SNI`,
* плюс кэш DNS и собственные резолверы роутера

---

## Что именно извлекается из TLS ClientHello и почему этого достаточно

TLS ClientHello отправляется **в начале** TLS-сессии и, в классическом TLS без ECH, содержит SNI в открытом виде.

Упрощённо:

```text
ClientHello:
  - supported_versions
  - cipher_suites
  - extensions:
      - server_name: petrovich.ru   <-- SNI
      - alpn: h2/http1.1/...
      - ...
```

Роутеру не нужно расшифровывать трафик и завершать TLS "как сервер" — часто достаточно просто прочитать первые пакеты и распарсить ClientHello, чтобы получить SNI и принять решение

---

## Типовой алгоритм SNI-роутинга

1. Принять входящий TCP.
2. Подождать первые байты.
3. Определить протокол:

   * если видим TLS ClientHello → парсим SNI/ALPN
4. Применить route rules:

   * match по `server_name` / `domain` / `tls.sni`
5. Выбрать outbound:

   * direct / proxy / specific upstream / detour
6. Установить исходящее соединение:

   * либо на фиксированный IP:порт,
   * либо на домен через DNS-resolve на стороне роутера
7. Начать проксирование данных между входом и выходом

---

## Почему "A-запись фронтинг-домена не на telemt" ломает кейс

### Ситуация

* В ClientHello: `SNI = petrovich.ru`
* DNS: `petrovich.ru -> 203.0.113.77`  - "оригинальный" сайт
* telemt живёт на: `198.51.100.10`

### Что делает роутер

* Видит SNI `petrovich.ru`
* Либо:

  * (а) напрямую коннектится к `petrovich.ru:443`, резолвя A-запись в `203.0.113.77`,
  * либо:
  * (б) выбирает outbound, который указывает на `petrovich.ru` как destination,
  * либо:
  * (в) делает sniffing/override destination по SNI

В итоге исходящий коннект идёт на `203.0.113.77:443`, а не на telemt!
Другой сервер, другой протокол, другая логика, где telemt не участвует

---

## "Где именно происходит подмена destination на SNI"

Это зависит от конфигурации, но типовые варианты:

### Вариант A: outbound задан доменом (и он совпадает с SNI)

Правило по SNI выбирает outbound, у которого destination задан доменом фронтинга, 
тогда DNS резолвится на стороне роутера и вы уходите на "оригинальный" хост

### Вариант B: destination override / sniffing

Роутер "снифает" SNI и **перезаписывает** destination на домен из SNI (даже если вход изначально был на IP telemt),
это особенно коварно: пользователь видит "я подключаюсь к IP telemt", но роутер после sniffing решает иначе

### Вариант C: split DNS / кеш / независимый резолвер

Даже если клиент "где-то" резолвит иначе, это не важно: конечный DNS для исходящего коннекта — на стороне xray/sing-box,
который может иметь:

* свой DoH/DoT,
* свой кеш,
* свои правила fake-ip / system resolver,
* и, как следствие, своя "карта" **домен/SNI -> IP**

---

## Признаки того, что трафик "утёк на оригинал", а не попал в telemt

* На стороне telemt отсутствуют входящие соединения/логи
* На стороне роутера видно, что destination — домен фронтинга, а IP соответствует публичному сайту
* TLS-метрики/сертификат на выходе соответствует "оригинальному" сайту в записах трафика
* Telegram-клиент получает неожиданный тип ответов/ошибку handshaking/timeout в debug-режиме

---

## Best-practice решение для этого кейса: свой домен фронтинга + заглушка на telemt + Let's Encrypt

### Цель

Сделать так, чтобы:

* SNI (фронтинг-домен) **резолвился в IP telemt**,
* на IP telemt реально был TLS-сервис с валидным сертификатом под этот домен,
* даже если кто-то "попробует открыть домен как сайт", он увидит нормальную заглушку, а не "пустоту"

### Что это даёт

* xray/sing-box, маршрутизируя по SNI, будет неизбежно приходить на telemt, потому что DNS(SNI-домен) → IP telemt
* Внешний вид будет правдоподобным: обычный домен с обычным сертификатом
* Устойчивость: меньше сюрпризов от DNS-кеша/перерезолва/"умных" правил роутера

---

## Рекомендуемая схема (целевое состояние)

```text
Telegram Client
   |
   | TLS ClientHello: SNI = hello.example.com
   v
xray-core / sing-box
   |
   | Route by SNI -> outbound -> connect to hello.example.com:443
   | DNS(hello.example.com) = IP telemt
   v
telemt instance (IP telemt)
   |
   | TLS cert for hello.example.com (Let's Encrypt)
   | + сайт-заглушка / health endpoint
   v
OK
```

---

## Практический чеклист (минимальный)

1. Купить/иметь домен: `hello.example.com`
2. В DNS:

   * `A hello.example.com -> <IP telemt>`
   * (опционально) AAAA, если используете IPv6 и он стабилен
3. На telemt-хосте:

   * поднять TLS endpoint на 443 с валидным сертификатом LE под `hello.example.com`
   * отдать "заглушку" (например, статический сайт), чтобы домен выглядел как обычный веб-сервис
4. В xray/sing-box правилах:

   * маршрутизировать нужный трафик по SNI = `hello.example.com` в "правильный" outbound (к telemt)
   * избегать конфигураций, где destination override уводит на чужой домен
5. Важно:

   * если вы используете кеш DNS на роутере — сбросить/обновить его после смены A-записи

---

## Пояснение про сайт-заглушку

Для эмуляции TLS, telemt имеет подсистему TLS-F в `src/tls_front`:
- её модуль - fetcher, собирает TLS-профили, чтоб максимально поведенчески корректно повторять TLS конкретно указанного сайта

Когда вы указываете сайт, который не отвечает по TLS:
- fetcher не может собрать TLS-профиль и происходит fallback на `fake_cert_len` - примитивный алгоритм,
- он забивает служебную информацию TLS рандомными байтами,
- простые системы DPI не распознают это
- однако, продвинутые системы, такие как nEdge или Fraud Control в сетях мобильной связи легко заблокируют или замедлят такой трафик

Создав сайт-заглушку с Let's Encrypt сертификатом, вы даёте TLS-F возможность получить данные сертификата и корректно его "повторять" в дальнейшем

---

## Вариант конфиг-подхода: "SNI строго привязываем к telemt - фиксированный IP"

Чтобы полностью исключить зависимость от DNS если вам это нужно, можно сделать outbound, который ходит на **фиксированный IP telemt**, но при этом выставляет SNI/Host как `hello.example.com`.

Идея:

* destination: `IP:443`
* SNI: `hello.example.com`
* сертификат на telemt именно под `hello.example.com`

Так вы получаете:

* TLS выглядит корректно, ведь SNI совпадает с сертификатом,
* а routing никогда не уйдёт на "оригинал", потому что A-запись указывает на telemt и контроллируется вами!

Но в вашем описании проблема как раз в том, что роутер "сам решает по SNI и резолвит домен", поэтому самый универсальный вариант — сделать так, чтобы DNS всегда приводил в telemt

---

## Пример логики правил на псевдоконфиге L7-роутера

```text
if inbound is TLS and sni == "hello.example.com":
    route -> outbound "telemt"
else:
    route -> outbound "default"
```

Outbound `telemt`:

* destination: `hello.example.com:443`
* TLS enabled
* SNI: `hello.example.com`

---

## Отдельно: что может неожиданно сломать даже "правильный" DNS

* **Кеширование DNS** на xray/sing-box или на системном резолвере, особенно при смене A-записи
* **Split-horizon DNS**: разные ответы внутри/снаружи, попытки подмены/терминирования в других точках
* **IPv6**: если есть AAAA и он указывает не туда, роутер может предпочесть IPv6: помните, что поддержка v6 нестабильна и не рекомендуется в prod
* **DoH/DoT** на роутере: он может резолвить не тем резолвером, которым вы проверяли

Минимальная гигиена:

* контролировать A/AAAA,
* держать TTL разумным,
* проверять, каким резолвером пользуется именно роутер,
* при необходимости отключить/ограничить destination override

---

## Итог

В режиме TLS-fronting с xray-core/sing-box как L7/TLS-роутером **SNI становится приоритетным "source-of-truth" для маршрутизации**

Если фронтинг-домен по DNS указывает не на IP telemt, роутер честно уводит трафик на "оригинальный" сайт, потому что он строит исходящее соединение "по SNI"

Надёжное решение для этого кейса:

* использовать **свой домен** для фронтинга,
* направить его **A/AAAA** на IP telemt,
* поднять на telemt **TLS-сервис с Let’s Encrypt сертификатом** под этот домен,
* (желательно) держать **сайт-заглушку**, чтобы 443 выглядел как обычный HTTPS