Блог Clearway

SNI и маскировка трафика: как вход выглядит легитимным

Коротко

SNI (Server Name Indication) — поле в TLS-рукопожатии, где клиент открытым текстом указывает домен назначения. Оператор связи и DPI читают его до шифрования, поэтому прямой вход VPN на свою ноду виден как обращение к «чужому» домену и под троттлингом отваливается. Маскировка трафика — это спрятать вход за whitelisted CDN-edge: в SNI и Host клиент указывает поддомен «белого» CDN, оператор видит легитимное обращение к CDN, а edge проксирует трафик на вашу ноду. Per-tenant SNI выдаёт каждому оператору собственный поддомен на CDN-edge, изолируя арендаторов друг от друга.

Что оператор видит в вашем трафике — и при чём тут SNI

TLS шифрует содержимое соединения, но не скрывает, *куда* вы подключаетесь. В самом первом пакете рукопожатия — ClientHello — клиент открытым текстом передаёт поле SNI (Server Name Indication) с именем домена назначения. Оператор связи и DPI читают его ещё до установления шифрования, вместе с IP-адресом и подсетью назначения. Именно эта тройка — SNI, IP и /24-подсеть — формирует «лицо» вашего соединения.

Для VPN-оператора это значит: даже идеально зашифрованный туннель выдаёт себя доменом и адресом входа. Если SNI указывает на незнакомый домен, а IP принадлежит датацентру вне белых списков, под ограничениями такой вход классифицируется как «не-whitelisted» и режется.

Расширение ECH (Encrypted Client Hello) прячет SNI, но под жёстким троттлингом оно ненадёжно проходит и само по себе задачу не решает. Поэтому sni-маскировка строится не на сокрытии поля, а на подмене «лица»: вход должен выглядеть как обращение к легитимному, заведомо разрешённому ресурсу.

Режим белого списка: почему прямой вход умирает

При блокировках и локальных шатдаунах мобильные операторы РФ переводят интернет в режим белого списка: доступны только whitelisted-ресурсы — часть CDN, госсайты, платёжные сервисы. Всё остальное недоступно. VPN, который идёт напрямую к своей ноде, в этот момент отваливается — его домен и подсеть в белый список не входят.

Ключевой нюанс: whitelist привязан к подсетям, обычно на уровне /24. У одного хостера подсеть попадает в белые списки, у соседнего — нет, и статус со временем меняется. Проверять нужно каждую /24 отдельно и регулярно, без опоры на «репутацию бренда» хостера.

ХостерЧастый статус /24Что это значит
SelectelЧасто whitelistedВход может пережить троттлинг — но подтверждать замером
cloud.ru / SberCloudЧасто НЕ whitelistedПрямой вход под ограничениями обычно отваливается

Таблица — ориентир, а не гарантия: статус конкретной /24 подтверждайте актуальными замерами со стороны целевого оператора, потому что списки динамические.

Как whitelisted CDN-edge делает вход легитимным

Идея маскировки vpn трафика на сетевом уровне: спрятать вход за whitelisted CDN-edge. Клиент подключается не к вашей ноде напрямую, а к поддомену «белого» CDN (например, на инфраструктуре Yandex CDN). В полях SNI, Host и Address клиентского конфига стоит домен CDN — оператор видит легитимное обращение к разрешённому ресурсу. Edge принимает соединение и проксирует его на ваш origin — ноду VPN.

С точки зрения DPI и системы белых списков трафик идёт к разрешённому ресурсу: SNI «белый», IP принадлежит CDN, подсеть — в списке. Ваша нода при этом остаётся за edge и напрямую в поле зрения оператора не попадает. Так решается не «шифрование payload» (его и так делает TLS), а именно легитимность точки входа.

Транспорт: почему XHTTP, и один неочевидный нюанс

Не любой транспорт проходит через CDN-edge. Reality и Hysteria2 напрямую под троттлингом обычно не проходят — edge их не пропускает. Рабочий подход — XHTTP в режиме packet-up поверх обычного HTTPS: для CDN это выглядит как штатный веб-трафик.

Критичный и неочевидный момент. При XHTTP через CDN uplink-данные должны идти в теле запросаuplinkDataPlacement: "body". Если положить их в кастомный заголовок (например, X-Payload), туннель порвётся с ошибкой unexpected EOF: CDN-edge не доносит произвольные кастомные заголовки до origin. Служебные поля распределяют иначе:

  • session/seq — в cookie;
  • padding — в query-строку;
  • полезная нагрузка uplink — только в body.

Это одна из самых частых причин, почему «всё вроде настроено, но туннель не поднимается».

Per-tenant SNI и изоляция арендаторов

В модели whitelist-CDN как сервиса каждому оператору выдают собственный поддомен на общем edge-неймспейсе — это и есть per-tenant SNI. Разные арендаторы получают разные имена под одним CDN-edge доменом (например, *.whitechannel-x1-cdn.ru), и в SNI каждого оператора стоит его собственный поддомен.

Что это даёт:

  • изоляция арендаторов — жалоба, ротация или проблема по одному поддомену не роняет остальных;
  • независимая маршрутизация — каждый per-tenant sni ведёт на свой origin (свою ноду или пул);
  • управляемая ротация — поддомен можно сменить по одному тенанту, не трогая общий вход;
  • чистый учёт — трафик и лимиты считаются по каждому арендатору отдельно.

Для оператора это предсказуемость: ваш вход не делит судьбу с чужими и живёт по своим правилам.

Настройка ноды и защита origin

На стороне ноды за CDN держится XHTTP-инбаунд (например, на порту 25454). Панель — Remnawave, 3x-ui, Marzban или Hiddify — конфигурирует инбаунд, а клиентский конфиг указывает CDN-поддомен как Address/SNI/Host. Абсолютное требование: path и extra на клиенте и на ноде должны совпадать точь-в-точь — любое расхождение, и туннель не поднимется.

Origin обязательно закрыть, иначе его найдут в обход CDN:

  • файрвол на вход — принимать только с IP gateway (edge), остальное блокировать;
  • секрет-заголовок X-Cdn-Auth — origin отвечает только на запросы с валидным секретом; прямые обращения мимо CDN отсекаются.

Это защищает ноду от сканеров и от раскрытия реального IP в обход маскировки.

Экономика и границы применимости

Прайс за гигабайт — только половина счёта. Вторая половина у части провайдеров это запросы, а XHTTP в режиме packet-up дробит аплинк на множество мелких обращений. На масштабе плата за запросы становится отдельной статьёй расхода, и считать её надо по своей выгрузке из биллинга, а не по прайсу. Снизить её помогает укрупнение: чем больше данных уходит в теле одного POST, тем меньше запросов и ниже кост — ещё одна причина держать uplink в body.

Учёт на стороне панели: множитель потребления ноды и per-user лимиты — механизмы Remnawave. Множитель 0 на ноде означает, что её трафик не списывается против лимита пользователя, хотя нода работает.

Чего маскировка НЕ решает. Пробить троттлинг и разблокировать стриминг — разные задачи. Сервисы вроде Kinopoisk банят датацентр-IP по репутации; для российского контента нужен резидентный IP, и whitelist-CDN эту задачу не закрывает. Не путайте «сделать вход легитимным для оператора» и «получить чистый IP для контента».

Whitelisted-вход можно строить самому или брать как сервис. Например, Clearway (clear-way.pro) выдаёт операторам per-tenant SNI на CDN-edge *.whitechannel-x1-cdn.ru и проксирует трафик на их ноды, не продавая при этом серверы. Выбор между «своё» и «как сервис» — баланс между контролем над каждой /24 и скоростью запуска.

Частые вопросы

Чем per-tenant SNI лучше общего домена на всех операторов?

Общий домен связывает судьбы арендаторов: жалоба или блокировка по одному имени бьёт по всем. Per-tenant SNI даёт каждому оператору собственный поддомен, который можно ротировать и маршрутизировать на свой origin независимо. Плюс чистый пооператорный учёт трафика и лимитов.

Почему нельзя просто использовать Reality или Hysteria2 под троттлингом?

В режиме белого списка оператор пропускает только whitelisted-ресурсы, и напрямую Reality/Hysteria2 через edge обычно не проходят. Рабочий вариант — XHTTP в режиме packet-up поверх HTTPS через whitelisted CDN: для оператора это выглядит как обычное обращение к разрешённому CDN.

Скрывает ли CDN содержимое трафика от оператора?

Payload и так зашифрован TLS — задача маскировки другая. SNI при обычном соединении показывает домен назначения, и смысл whitelisted CDN в том, чтобы этот видимый домен был «белым», а не вашей ноды. ECH может прятать сам SNI, но под жёстким троттлингом ненадёжен, поэтому опираются на легитимность точки входа.

Whitelist-CDN разблокирует Кинопоиск и другой стриминг?

Нет. Стриминговые сервисы банят датацентр-IP по репутации, и для российского контента нужен резидентный IP — это отдельная задача. Whitelist-CDN решает проходимость входа под ограничениями оператора, но чистого IP для контента не даёт.

Туннель рвётся с ошибкой unexpected EOF на XHTTP через CDN — что делать?

Чаще всего uplink-данные лежат в кастомном заголовке (например, X-Payload), а CDN-edge не доносит его до origin. Переложите uplink в тело запроса (uplinkDataPlacement: "body"), session/seq в cookie, padding в query. Также сверьте, что path и extra на клиенте и ноде совпадают точь-в-точь.

Как защитить origin от прямых обращений мимо CDN?

Закройте файрвол на вход, разрешив только IP gateway (edge). Дополнительно включите секрет-заголовок X-Cdn-Auth, чтобы origin отвечал лишь на запросы с валидным секретом. Так реальный IP ноды не раскрывается сканерам и запросам в обход маскировки.

Whitelisted-вход для вашего VPN-сервиса

Clearway даёт «белый» CDN-вход перед вашей нодой — устойчивый к троттлингу операторов. Первые 10 ГБ бесплатно, без карты.

Попробовать →