Что такое режим белого списка у мобильного оператора
«Белый список интернета оператора» — это не постоянная настройка тарифа, а аварийный/ограничительный режим фильтрации, который операторская сеть включает по команде регулятора: во время региональных отключений мобильного интернета, массовых блокировок или локальных шатдаунов. В обычном состоянии сеть работает по принципу «разрешено всё, кроме заблокированного» (чёрные списки на DPI/ТСПУ). В режиме whitelist логика инвертируется: разрешено только то, что явно внесено в белый список, остальное отбрасывается или жёстко троттлится.
Для инженера, который строит VPN-сервис, важны три следствия этого режима:
- Фильтрация идёт на уровне транспортного/сетевого стыка (IP-адрес назначения, SNI, паттерн трафика), а не на уровне приложения.
- Прямое обращение к вашей ноде по IP датацентра почти всегда попадает в «неразрешённое» и рвётся.
- Whitelist динамичен: его состав и охват меняются в разных регионах и в разное время, единой публичной таблицы не существует.
Поэтому задача оператора VPN формулируется как задача устойчивости инфраструктуры: сделать так, чтобы вход сервиса технически совпадал с тем, что операторская сеть уже считает «белым», а не пытаться «пробить» фильтр в лоб.
Что попадает в whitelist: подсети /24, CDN и госресурсы
В белые списки операторов обычно попадают ресурсы, отключение которых ломает базовую доступность: государственные порталы, часть инфраструктуры крупных экосистем и, что важнее всего для нашей задачи, подсети магистральных CDN. Именно CDN даёт «серую зону»: через один и тот же whitelisted edge раздаётся легитимный контент множества сервисов, поэтому оператор не может просто вырезать его целиком.
Ключевой технический факт: whitelist привязан к подсетям /24, а не к целым ASN или /16-блокам. Нельзя сказать «весь такой-то провайдер в белом списке». Внутри одного /16 соседние /24 могут иметь разных фактических владельцев и разный статус: одна попала в whitelist, соседняя — нет. Это принципиально меняет методику размещения нод.
| Что часто внутри whitelist | Что обычно снаружи |
|---|---|
| Подсети /24 крупных CDN | Прямые IP «обычных» датацентров |
| Госпорталы | Произвольные VPS по IP |
| Часть инфраструктуры экосистем | Транспорты с характерным «не-HTTP» отпечатком |
Отсюда практический вывод: белый список мобильных операторов нельзя рассматривать как список доменов, который можно «подставить». Это набор сетевых признаков (в первую очередь — подсети), и работать нужно именно с ними.
Почему прямой VPN отваливается, а вход за CDN — нет
Когда клиент VPN идёт напрямую к вашей ноде, операторская сеть в режиме белого списка видит соединение к IP-адресу, которого нет в whitelist, — и обрывает его. Маскировка протокола на уровне приложения тут не помогает, потому что решение принимается раньше, по адресу назначения и паттерну трафика.
Рабочий подход — поставить перед нодой whitelisted CDN-edge. Схема движения трафика:
- Клиент обращается не к IP ноды, а к поддомену CDN (он же прописан как Address/SNI/Host в конфиге).
- Для операторской сети это обращение к «белой» подсети CDN — трафик проходит фильтр.
- CDN-edge принимает соединение и проксирует его на ваш origin (ноду).
- Нода терминирует VPN-туннель и выпускает пользователя в интернет.
Важный нюанс: сам origin не обязан находиться в whitelisted-подсети — «белизну» на стыке с оператором обеспечивает edge. Origin может стоять на любом хостинге, лишь бы был доступен со стороны CDN. Это развязывает две задачи, которые раньше приходилось решать одним сервером: «попасть в белый список» и «держать производительную ноду».
Именно на этом принципе строится whitelist-CDN как инфраструктурный слой: оператор арендует не сервер, а whitelisted-вход перед своей нодой.
Транспорт под троттлингом: XHTTP через CDN vs Reality/Hysteria2
Не любой транспорт переживёт проход через CDN-edge и режим белого списка. Здесь есть жёсткое ограничение: edge — это HTTP-обратный прокси, он пропускает то, что выглядит как валидный HTTP(S)-запрос, и не пропускает всё остальное.
- XHTTP (mode packet-up) через CDN — рабочий подход. Трафик туннеля упаковывается в обычные HTTP-запросы, которые edge спокойно проксирует на origin. Для операторской сети это HTTPS к whitelisted CDN, для CDN — легитимный HTTP к origin.
- Reality, Hysteria2 напрямую под троттлингом обычно не проходят. Reality рассчитан на прямое TLS-соединение и не переживает промежуточный HTTP-прокси; Hysteria2 работает поверх QUIC/UDP, который edge через себя как HTTP не пропускает. В режиме белого списка попытка идти этими транспортами напрямую упирается в тот же фильтр по адресу назначения.
Поэтому под задачу «устойчивость под ограничениями оператора» практически безальтернативно берут XHTTP за CDN. Reality/Hysteria2 остаются полезными как транспорты для регионов и операторов без whitelist-режима, но как «белый» вход они не годятся.
Критичная деталь XHTTP через CDN: uplink в теле запроса, а не в заголовке
Это самый неочевидный и самый частый источник поломок при заводе XHTTP за CDN. XHTTP умеет размещать uplink-данные (то, что клиент шлёт на сервер) в разных местах HTTP-запроса. И вот здесь CDN расставляет ловушку.
CDN-edge не гарантирует доставку произвольных кастомных заголовков до origin. Если в конфиге uplink кладётся в кастомный заголовок (например, uplinkDataPlacement: "header" с ключом вроде X-Payload), edge этот заголовок до ноды не доносит — или переписывает служебные заголовки вроде идентификатора запроса. Нода не может собрать uplink, и туннель рвётся. В логах gateway это выглядит как unexpected EOF при чтении тела, а на клиенте — как «не пингуется / не поднимается».
Правильная раскладка данных для XHTTP через CDN:
| Данные | Куда класть | Почему |
|---|---|---|
| Uplink-payload | тело запроса (uplinkDataPlacement: "body") | тело CDN проксирует всегда |
| Session / seq | cookie | cookie доходят до origin стабильно |
| Padding | query-параметр | query сохраняется на edge |
Практический признак диагностики: если тот же клиент поднимается через один CDN-слой и не поднимается через другой при живом транспорте (curl через edge доходит до origin) — почти наверняка дело в размещении uplink в заголовке. Перевод на body-based/cookie-based раскладку снимает проблему. Полезно также помнить про размер части: крупные POST в тело не только совместимы с CDN, но и снижают число запросов.
Как проверять whitelist по /24 и где размещать ноды
Поскольку белый список операторов работает по /24 и меняется, единственный надёжный метод — проверять конкретную подсеть, а не доверять репутации хостера целиком. Порядок работы:
- Определить владельца /24. Один и тот же /16 может быть физически разделён между разными компаниями; ASN и владельца конкретной подсети смотрят через RDAP / ip-api.
- Свериться с актуальным списком. Открытые агрегированные списки whitelisted-префиксов мобильного интернета РФ помогают предварительно отсеять заведомо «серые» подсети, но их нужно перепроверять — состав меняется.
- Сделать реальный тест из мобильной сети. Никакая офлайн-проверка не даёт 100%: единственная достоверная проверка — поднять ресурс в подсети и подключиться к нему из мобильной сети оператора в зоне ограничений.
По статусу хостеров (ориентир, не гарантия — проверяйте актуально по каждой /24):
| Хостер | Практика по whitelist |
|---|---|
| Selectel | часть /24 регулярно оказывается в whitelist |
| cloud.ru / SberCloud | подсети часто НЕ в whitelist |
| Крупные публичные облака | статус нестабилен: диапазоны то попадают, то выпадают — обязательна проверка каждой /24 |
Важная деталь: близость к whitelisted-подсети ничего не значит. Внутри выделенного пула может быть whitelisted только одна конкретная /24, а соседняя — нет. Поэтому при заказе IP через API облака нужно отбирать адреса по факту попадания в нужные префиксы, а не по «соседству». И держать в голове, что статус динамичен — то, что работало вчера, может выпасть из whitelist оператора завтра.
Настройка входа за CDN: панели, порты и безопасность origin
На стороне ноды нужен XHTTP-инбаунд, а на стороне клиента — конфиг, указывающий на CDN-поддомен. Подход одинаково ложится на популярные панели: Remnawave, 3x-ui, Marzban, Hiddify.
Опорные правила:
- Нода держит XHTTP-инбаунд на выделенном порту (например, 25454), origin принимает трафик от CDN-edge.
- Клиентский конфиг указывает CDN-поддомен как Address / SNI / Host, а не IP ноды.
pathиextraна клиенте и на ноде должны совпадать точь-в-точь. Любое расхождение (лишний слэш, другой сегмент пути, иная раскладка uplink) — и туннель не поднимется. При живом edge большинство ситуаций «не поднимается» сводится именно к расхождению пути или раскладки данных, поэтому сверяйтеpathиextraпобайтово.- Учитывайте, что не все панели подменяют домен в клиентской ссылке: если панель отдаёт ссылку с IP или исходным доменом ноды, CDN-поддомен нужно подставить в шаблон
vless://вручную.
Безопасность origin — обязательная часть, а не опция:
- Файрвол на вход: origin принимает соединения только с IP gateway/edge, всё остальное закрыто. Это отсекает прямое сканирование ноды по IP.
- Секрет-заголовок (например,
X-Cdn-Auth): edge добавляет его к запросам на origin, origin отклоняет всё без корректного секрета. Так нода защищена от обращений мимо CDN, даже если её IP кто-то узнал.
Отдельно про учёт трафика в панели (на примере Remnawave): у ноды есть множитель потребления и per-user лимиты. Множитель 0 на ноде означает, что её трафик не засчитывается против лимита пользователя, при этом нода продолжает работать — удобно для сервисных/тестовых нод. Для боевого CDN-входа множитель обычно ставят по реальной экономике трафика.
Экономика CDN-трафика и учёт потребления
Whitelisted-вход через CDN — это метрируемый трафик, и его стоимость нужно закладывать в юнит-экономику сервиса.
- Ставку за сырой трафик смотрите в прайсе выбранного провайдера — разброс между площадками кратный.
- На масштабе плата за запросы становится отдельной статьёй расхода, и считать её надо по своей выгрузке из биллинга, а не по прайсу. Причина — XHTTP плодит множество мелких HTTP-запросов, а тарификация CDN учитывает не только объём, но и число запросов.
Отсюда практический рычаг оптимизации: укрупнение POST-запросов (складывать uplink в тело крупными частями) снижает число запросов и стоимость гигабайта. Это тот же самый механизм (uplink в body), который нужен для совместимости с CDN, — он же работает и на экономику. Даунлинк-нагрузка (видео, загрузки) сама по себе request-лёгкая: там один долгоживущий поток, поэтому средневзвешенная стоимость на реальном VPN-трафике ближе к нижней границе диапазона.
Для учёта на стороне сервиса удобно опираться на механизмы панели: множитель потребления ноды и per-user лимиты (Remnawave), а на инфраструктурном слое — на инкрементальный учёт байт на gateway. Важный технический момент для тех, кто строит собственный биллинг поверх стриминговых транспортов: учёт трафика должен быть инкрементальным, а не по завершению запроса. XHTTP-даунлинк — это один длинный streaming-GET на всю сессию; если считать байты только по закрытию соединения, большая часть трафика не учитывается в реальном времени и теряется при рестарте счётчика.
Чего whitelist-CDN не решает: стриминг и резидентные IP
Важно не смешивать две разные инженерные задачи, потому что их часто путают в поддержке.
- «Пройти режим белого списка оператора» — это задача доступности: сделать вход сервиса whitelisted, чтобы туннель вообще поднимался. Её решает CDN-edge перед нодой.
- «Разблокировать российский стриминг» — это отдельная задача про репутацию исходящего IP. Сервисы вроде Kinopoisk банят датацентр-IP по репутации: с адреса дата-центра контент не отдаётся независимо от того, как построен вход. Для такого контента нужен резидентный (residential) IP на выходе.
Whitelist-CDN это НЕ решает. Он обеспечивает «белый» вход и устойчивость под ограничениями оператора, но не меняет репутацию выходного IP ноды. Если пользователи оператора ждут доступ к контенту, чувствительному к типу IP, это отдельный слой инфраструктуры (резидентные выходы), который строится и оплачивается отдельно.
В сумме картина для оператора такая: whitelisted CDN-edge закрывает вопрос «дойти до ноды под белым списком», транспорт XHTTP с uplink в теле — вопрос «пройти через edge», а резидентные выходы — отдельный вопрос стриминга. Именно первый слой — whitelisted-вход перед вашей нодой — Clearway (clear-way.pro) даёт как сервис для VPN-операторов: оператор арендует «белый» вход через нейтральный CDN-домен (*.whitechannel-x1-cdn.ru), не покупая серверы и оставляя ноды у себя.