Что происходит с VPN на Билайн под блокировками
Мобильные операторы РФ, включая Билайн, во время локальных блокировок и шатдаунов переводят мобильный интернет в режим белого списка: доступны только whitelisted-ресурсы — часть CDN, платёжные и госсайты. Всё, что идёт напрямую к сторонней ноде по нестандартному порту или протоколу, обрывается на входе. Поэтому VPN, который клиент открывает прямым соединением к вашему серверу, под такими ограничениями отваливается — пакеты до origin просто не доходят.
Важно разделять два разных режима, которые часто путают под общим словом «билайн блокировка»:
- DPI-троттлинг — оператор замедляет или сбрасывает отдельные протоколы (типичный маркер — Reality/QUIC деградируют, а обычный HTTPS живёт).
- Жёсткий белый список — пропускается только явно разрешённая инфраструктура, остальное режется по умолчанию.
Схема, устойчивая ко второму режиму, переживёт и первый. Поэтому проектировать сервис имеет смысл сразу под белый список, а не под мягкий троттлинг.
Билайн и белый список: как это устроено технически
Билайн белый список работает не по доменам, а по подсетям: разрешаются диапазоны /24, принадлежащие whitelisted-инфраструктуре — крупные CDN, платёжные шлюзы, госсервисы. Домен и SNI сами по себе ничего не решают, если IP назначения лежит в «сером» диапазоне.
Отсюда ключевой рычаг для оператора: вход VPN должен вести на IP, чья /24 уже в белом списке. Практически это делается через whitelisted CDN-edge. Клиент обращается к поддомену «белого» CDN, оператор видит обращение к разрешённому ресурсу, а CDN-edge проксирует трафик на вашу ноду (origin). Ваша нода при этом может стоять где угодно — её IP наружу для клиента не светится.
Статусы подсетей нестабильны: диапазоны добавляют и убирают, whitelist одного хостера может отличаться от другого даже в рамках одного дата-центра. Никаких «вечно белых» IP не бывает — любую /24 нужно проверять актуально перед выкаткой на абонентов.
Рабочая схема: вход VPN за whitelisted CDN-edge
Под белым списком выживает транспорт, который для edge и для оператора выглядит как обычный HTTPS-трафик к CDN. На практике это XHTTP в режиме packet-up через CDN. Reality и Hysteria2 напрямую под троттлингом обычно не проходят: Reality — это произвольная TLS-сессия к вашему IP (edge её не проксирует и не пропускает), а Hysteria2 работает по QUIC/UDP, который CDN-edge, как правило, до origin не доносит.
| Транспорт | Прямо на ноду под белым списком | За whitelisted CDN-edge |
|---|---|---|
| Reality | Обычно не проходит | Неприменимо (edge не пропускает произвольный TLS) |
| Hysteria2 (QUIC/UDP) | Обычно не проходит | CDN-edge обычно не проксирует UDP |
| XHTTP (mode packet-up) | Не проходит | Рабочий подход |
Смысл в том, что XHTTP оборачивает туннель в обычные HTTP-запросы к whitelisted-домену. Для сети это трафик к «белому» CDN, а не подозрительное прямое соединение к неизвестному хосту.
Критичный нюанс: uplink XHTTP должен идти в теле запроса
Это неочевидный, но решающий момент при работе XHTTP через CDN. CDN-edge доносит до origin тело запроса, но не кастомные заголовки. Многие дефолтные конфиги кладут uplink-данные в кастомный header (например, X-Payload). Через прямое соединение это работает, а через CDN — нет: edge срезает кастомный заголовок, uplink до ноды не доходит, и туннель поднимается, но тут же разваливается с ошибкой unexpected EOF.
Правильная раскладка полей XHTTP через CDN:
- uplink-данные — в тело POST:
uplinkDataPlacement: "body"(не в заголовок). - session / seq — в cookie: cookie edge пробрасывает до origin стабильнее кастомных заголовков.
- padding — в query-строку.
Если ловите unexpected EOF сразу после установки соединения, а на прямом IP та же конфигурация работает — почти наверняка причина в том, что аплинк уехал в заголовок, который CDN не пропустил.
Подсети, хостеры и себестоимость трафика
Выбор хостера под origin вторичен для клиента (его IP скрыт за CDN), но первичен, если вы хотите завести в белый список сам вход без стороннего CDN. Whitelist привязан к /24, и статус отличается от площадки к площадке.
| Хостер | Практический статус /24 в белом списке |
|---|---|
| Selectel | Часто whitelisted |
| cloud.ru / SberCloud | Часто НЕ whitelisted |
Это ориентир, а не гарантия — проверяйте каждую конкретную /24 на реальной сети Билайн перед раскаткой.
Прайс за гигабайт — только половина счёта. Вторая половина у части провайдеров это запросы, а XHTTP в режиме packet-up дробит аплинк на множество мелких обращений. XHTTP по своей природе плодит много мелких запросов, а тарификация запросов на объёме заметна. Практический вывод для инженера: укрупняйте POST-и (больше данных в теле одного запроса) — это снижает число запросов и итоговую стоимость гигабайта.
Настройка ноды, панели и защита origin
Схема совместима с типовыми панелями: Remnawave, 3x-ui, Marzban, Hiddify. За CDN нода держит XHTTP-инбаунд (например, на порту 25454), а клиентский конфиг указывает поддомен CDN как Address / SNI / Host.
Главное правило совпадения: path и extra на клиенте и на ноде должны совпадать точь-в-точь. Любое расхождение — и туннель не поднимется, даже когда edge и whitelist отработали корректно.
Безопасность origin (иначе вашу ноду найдут прямым сканом мимо CDN):
- Файрвол на входе — только с IP gateway/edge. Всё остальное — drop.
- Секрет-заголовок
X-Cdn-Authна origin: запросы без него отбрасываются, что защищает ноду от прямых обращений в обход CDN.
По учёту: множитель потребления ноды и per-user лимиты — механизмы панели (в Remnawave это штатно). Множитель 0 на ноде означает, что трафик не засчитывается против лимита юзера, при этом сама нода работает — удобно для аварийного whitelist-входа, который не должен «съедать» абонентские квоты.
Если не хотите вручную искать whitelisted-подсети и держать свой CDN-слой, whitelisted-вход можно взять как сервис. Clearway (clear-way.pro) даёт операторам «белый» вход перед их нодами через CDN-edge *.whitechannel-x1-cdn.ru — без продажи серверов, вы остаётесь на своей панели и своих нодах.