Как построить VPN-сервис, устойчивый к блокировкам оператора

Почему прямой VPN отваливается под блокировками оператора

Симптом знаком любому оператору: клиент жалуется, что vpn не работает под блокировкой — на домашнем Wi-Fi туннель поднимается, а на мобильном интернете в зоне ограничений молчит. Причина при этом не в протоколе шифрования и не в клиентском приложении.

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

Для VPN это значит, что первый хоп трафика — от клиента к ноде — физически не доходит. Reality-инбаунд на прямом IP не отвечает, TLS-handshake не завершается; Hysteria2 по UDP не находит адресата. Никакая маскировка протокола тут не спасает: пакет не доходит до сервера в принципе.

Отсюда следует главный архитектурный вывод для устойчивого VPN под блокировками: чинить нужно не шифрование, а транспорт первого хопа. Точка входа сервиса должна физически находиться на ресурсе, который уже в белом списке оператора. Всё остальное в статье — про то, как это сделать инженерно.

Whitelist привязан к подсетям /24, а не к вашему сервису

Белый список оператора — это не «домены вообще» и не «CDN как класс», а конкретные IP-диапазоны, как правило на уровне подсетей /24. Практический вывод неприятный: у одного хостера часть /24 может быть whitelisted, а соседняя /24 того же хостера — нет. Нельзя рассуждать категориями «этот провайдер белый».

По наблюдениям на реальных SIM в зоне ограничений: подсети Selectel часто оказываются whitelisted, а cloud.ru / SberCloud — часто нет. Но это не гарантия и не константа — статус подсетей меняется, диапазоны добавляют и убирают. Известны случаи, когда ранее рабочая подсеть (в том числе у Yandex) переставала проходить. Поэтому единственно верный подход — проверять каждую /24 отдельно и актуально, без ставки на «этот IP белый навсегда».

Методика проверки простая: держите тестовые endpoint'ы в разных /24 и регулярно гоняйте доступность с реальных мобильных SIM в зоне ограничений. Автоматизируйте это — статус подсети сегодня и через месяц может отличаться. Строить инфраструктуру VPN-сервиса на предположении о «вечно белом» IP — прямой путь к аварии в самый неподходящий момент.

Архитектура: вход за whitelisted CDN-edge

Раз попытка сделать белой собственную ноду ненадёжна (см. выше про изменчивость /24), устойчивая схема иная: не тащить ноду в белый список, а поставить перед ней слой, который уже там находится, — CDN-edge (например, Yandex CDN). Оператор видит обращение к «белому» CDN-домену, CDN принимает трафик на своём whitelisted edge и проксирует его на ваш origin — ноду.

Логическая цепочка выглядит так:

клиент → CDN edge (whitelisted /24) → origin-нода (XHTTP inbound)

Что требуется от CDN-слоя, чтобы схема работала:

• edge-подсети реально находятся в белых списках операторов (это опять же вопрос конкретных /24, а не бренда CDN);
• поддержка проксирования на произвольный origin (вашу ноду);
• корректный проброс HTTP-семантики, включая тело POST-запросов (это критично, разберём отдельно).

CDN-поддомен при такой архитектуре становится публичной точкой входа сервиса: именно он прописывается в клиентском конфиге как Address / SNI / Host, а реальный IP ноды наружу не светится.

Собирать этот слой можно самому — арендуя CDN и настраивая проксирование под свой транспорт, — либо брать whitelisted-вход как готовый сервис. Например, Clearway продаёт VPN-операторам именно «белый» вход перед их нодами (без продажи серверов), с edge-доменом *.whitechannel-x1-cdn.ru; оператор оставляет у себя ноды и панель, а на вход ставит уже настроенный whitelisted-слой. Оба пути валидны — выбор зависит от того, готова ли команда сама вести мониторинг подсетей и тюнинг транспорта.

Транспорт: почему XHTTP, а не Reality или Hysteria2

CDN-edge — это по сути HTTP(S)-прокси. Он пропускает то, что укладывается в веб-семантику, и не пропускает произвольные протоколы. Это сразу отсекает часть привычных решений.

XHTTP в режиме packet-up через CDN — рабочий подход именно потому, что укладывается в обычные HTTP-запросы: для edge это похоже на веб-трафик к «белому» ресурсу, и он проходит.

Reality и Hysteria2 напрямую под троттлингом обычно НЕ проходят. Hysteria2 работает поверх QUIC/UDP — CDN-edge такой транспорт до origin не проксирует. Reality использует собственный TLS-хендшейк, который не является валидным HTTP-обращением к edge, поэтому под режимом белого списка он не доходит. Это не значит, что Reality/Hysteria2 «плохие» — на прямом канале без ограничений они отличны; но под задачу устойчивости за CDN они не подходят.

Поэтому базовый выбор транспорта для сервиса, который должен пережить перевод оператора в белый список, — XHTTP поверх whitelisted CDN. Дальше всё внимание уходит на корректную раскладку данных запроса, потому что именно здесь ломается большинство первых попыток.

Актуальные настройки XHTTP через CDN

Это самая частая и самая неочевидная ошибка при заведении XHTTP через CDN. XHTTP умеет размещать uplink-данные в разных частях запроса, и здесь легко выбрать нерабочий вариант.

Ошибка unexpected EOF сама по себе не определяет причину. В текущем входе Clearway GET с телом отклоняется CDN с ошибкой 413. Проверьте серверный auto и лимит заголовков, затем клиентский header; для других ошибок сопоставьте время и журналы клиента, CDN, gateway и origin. Ответ HTTP 200 и успешный TLS ещё не подтверждают передачу HTTPS через туннель. Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.

Правильная раскладка для прохождения через CDN:

Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.

Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.

Настройка ноды и клиента: панели, порты, совпадение path

На стороне инфраструктуры за CDN живёт обычная нода под управлением одной из панелей — Remnawave, 3x-ui, Marzban или Hiddify. Нода держит XHTTP-инбаунд на выделенном порту (например, 25454), а CDN настроен проксировать входящий трафик на origin-IP:порт.

Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.

Чек-лист параметров, которые обязаны совпадать по обе стороны:

Практический порядок настройки вынесен в пошаговую инструкцию ниже. Главное на этом этапе — не менять параметры транспорта в одном месте, забыв про другое: клиент и нода должны быть зеркальны.

Безопасность origin: файрвол и секрет-заголовок

Как только вы спрятали ноду за CDN, критично, чтобы origin не принимал прямые обращения мимо CDN. Иначе реальный IP ноды рано или поздно засветится (сканеры, утечка из конфига), и тогда весь смысл whitelisted-входа теряется — ноду можно заблокировать или атаковать напрямую.

Два уровня защиты, которые нужно поставить сразу:

1. Файрвол на вход. На XHTTP-порт origin пускать трафик только с IP gateway/CDN-edge. Все остальные источники — drop. Это отсекает и сканеры, и прямые попытки достучаться до ноды.
2. Секрет-заголовок X-Cdn-Auth. CDN добавляет к каждому проксируемому запросу секретный заголовок, а origin проверяет его наличие и значение; запросы без корректного X-Cdn-Auth отбрасываются на уровне ноды. Это защищает даже в случае, если кто-то узнал IP, но не знает секрета.

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

Экономика трафика и учёт в панели

Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.

На стороне учёта потребления помогает панель. В Remnawave есть множитель потребления ноды и per-user лимиты. Множитель определяет, с каким коэффициентом трафик через конкретную ноду списывается против лимита пользователя:

Множитель 0 удобен, когда CDN-нода — это аварийный fallback на время ограничений: пользователь не должен «сгорать» по лимиту из-за вынужденного дорогого маршрута. Так вы отделяете тарифную политику от факта, что клиент временно идёт через whitelisted-вход.

Если не хочется самим держать CDN-слой, мониторить подсети и оптимизировать стоимость запросов, whitelisted-вход можно взять как сервис — например, у Clearway, где эта часть уже настроена и тарифицируется прозрачно, а оператор оставляет у себя ноды, панель и биллинг.

Границы применимости: что whitelist-CDN НЕ решает

Важно не переоценивать инструмент и не смешивать две разные задачи. «Пробить троттлинг» и «разблокировать стриминг» — это не одно и то же.

Whitelisted-CDN решает задачу доступности: трафик доходит до ноды даже под режимом белого списка. Но он никак не меняет репутацию IP, с которого нода выходит в интернет.

Сервисы вроде Kinopoisk и другого российского стриминга банят дата-центровые IP по репутации — им неважно, как трафик дошёл до вашей ноды, важно, что финальный выход идёт с адреса дата-центра. Для доступа к такому контенту нужен резидентный (residential) IP, и whitelist-CDN этого не даёт — это отдельная инженерная задача (residential-exit, отдельные каналы выхода).

Поэтому при проектировании сервиса разделяйте два слоя: устойчивость входа (пережить перевод оператора в белый список — решается whitelisted CDN + XHTTP) и репутация выхода (доступ к контенту, чувствительному к типу IP — решается резидентными адресами). Смешивать их в одном обещании клиенту — значит гарантировать то, что архитектура не покрывает.