Белые списки через CDN: как работает обход блокировок и что нужно знать

Что такое белые списки и почему они меняют правила игры

Белые списки (или allowlist) — это режим фильтрации трафика, при котором доступ разрешён только к ограниченному перечню ресурсов, а всё остальное блокируется по умолчанию. В отличие от чёрных списков, где блокируют конкретные адреса, здесь работает обратная логика: пропускается только то, что явно разрешено. Это делает классические методы обхода, основанные на смене IP или маскировке трафика, малоэффективными, поскольку даже если ваш VPN-сервер технически исправен, он просто недоступен из-за того, что его адрес не входит в разрешённый диапазон.

На практике белые списки применяются в сценариях «суверенного интернета» или при тестировании отключения от глобальной сети. Пользователи мобильных операторов в таких ситуациях замечают, что открываются только сайты из списка — обычно это государственные сервисы, крупные маркетплейсы, банки и популярные медиа. При этом даже небольшие локальные сайты могут быть недоступны, если их IP не попал в перечень. Это создаёт серьёзные неудобства для бизнеса и обычных пользователей, которые не могут получить доступ к нужным ресурсам.

Ключевая особенность белых списков — их динамичность. Списки могут меняться в зависимости от оператора, региона и текущей политики. То, что работало вчера, сегодня может быть заблокировано, и наоборот. Поэтому любые решения должны быть гибкими и предусматривать запасные варианты.

Почему CDN становится ключевым инструментом обхода

CDN (Content Delivery Network) — это распределённая сеть серверов, которая используется для ускорения доставки контента. Когда вы подключаетесь к сайту через CDN, ваш запрос идёт не напрямую к серверу, а к ближайшему узлу CDN, который уже перенаправляет его к источнику. Для конечного пользователя это выглядит как обычное HTTPS-соединение с известным доменом.

При белых списках IP-адреса крупных CDN-провайдеров часто попадают в разрешённые диапазоны, потому что они обслуживают множество популярных сервисов — от банков до государственных порталов. Заблокировать такой CDN целиком означало бы отрезать доступ к этим сервисам, что нежелательно для операторов. Поэтому CDN-фронт становится «белым» — трафик к нему проходит, даже когда прямые подключения к серверам в дата-центрах заблокированы.

Использование CDN для обхода белых списков заключается в том, что ваш VPN-сервер (нода) прячется за доменом CDN. Клиент подключается к CDN-домену, а CDN уже перенаправляет трафик на вашу ноду. Таким образом, реальный IP ноды остаётся скрытым, и блокировка по IP становится бесполезной. Это принципиально отличается от маскировки трафика (например, через TLS), которая скрывает характер соединения, но не решает проблему недоступности адреса.

Как работает связка VLESS и CDN: технические детали

Для работы через CDN необходим HTTP-транспорт, поскольку CDN понимает только HTTP(S) протоколы. Среди популярных вариантов — WebSocket, gRPC и XHTTP. Наиболее практичным для новых конфигураций считается VLESS + XHTTP, так как этот протокол изначально разработан для работы через промежуточные HTTP-прокси и CDN.

XHTTP (или splithttp) разбивает трафик на отдельные HTTP-запросы, что позволяет обходить ограничения CDN, связанные с длительными соединениями. Он поддерживает два режима: auto и packet-up. В режиме auto клиент и сервер автоматически договариваются о направлении передачи данных, но если CDN разрешает только GET-запросы (что часто бывает), необходимо явно указать mode: packet-up на обеих сторонах. Иначе клиент и сервер не смогут согласовать параметры, и соединение не установится.

WebSocket — более старый и совместимый вариант, но он создаёт одну TCP-сессию на соединение, и некоторые CDN могут обрывать её по таймауту. gRPC работает поверх HTTP/2 и стабилен на длинных сессиях, но требует сквозной поддержки HTTP/2, которую не все CDN обеспечивают — некоторые даунгрейдят до HTTP/1.1, что ломает стриминг. Поэтому выбор транспорта зависит от конкретного CDN и его настроек.

Проверка доступности CDN при белых списках

Прежде чем настраивать CDN-фронт, необходимо убедиться, что IP-диапазоны выбранного CDN действительно входят в белый список вашего оператора. Это можно сделать с устройства, находящегося в зоне блокировки, с помощью простой команды curl. Например, вы можете проверить, отвечает ли конкретный edge-IP CDN на HTTPS-запрос, используя опцию --resolve для подмены домена.

Команда выглядит так: curl -s -o /dev/null -w "%{http_code} %{time_connect}\n" https:/// --resolve cdn-domain.example:443:. Если вы получаете код ответа (например, 200 или 404) и время соединения, значит, этот IP доступен. Важно проверить несколько IP-адресов из разных подсетей, так как даже соседние /24 могут вести себя по-разному.

Также стоит проверить, поддерживает ли CDN POST-запросы, так как XHTTP может требовать их для передачи данных. Для этого выполните два запроса: один с методом POST, другой с GET. Если POST возвращает 403 или 405, а GET — 200 или 404, значит, CDN работает в режиме GET-only, и вам придётся использовать packet-up режим.

Настройка CDN-фронта: пошаговый каркас

Настройка CDN-фронта включает несколько ключевых шагов, которые не зависят от конкретной панели управления (Remnawave, Marzban, 3x-ui и т.д.). Сначала создайте поддомен, который будет указывать на CDN. В настройках CDN укажите origin — IP вашей ноды. Важно, чтобы реальный IP ноды не светился ни в одном клиентском конфиге — все подключения должны идти через CDN-домен.

Далее настройте TLS: клиент должен подключаться к CDN по валидному сертификату CDN-домена, а CDN уже будет проксировать трафик на origin по своему TLS. На ноде настройте inbound VLESS с XHTTP на конкретном path, например /xhttp. Этот же path нужно прописать в правилах CDN, чтобы трафик проксировался на origin, а не кэшировался как статика.

Минимальный фрагмент конфигурации Xray для inbound выглядит так: { "protocol": "vless", "streamSettings": { "network": "xhttp", "xhttpSettings": { "path": "/xhttp", "mode": "packet-up" } } }. Если CDN поддерживает POST, можно оставить mode: auto, но при GET-only обязательно packet-up. Также не забудьте отключить кэширование для трафикового path, иначе CDN будет отдавать устаревшие ответы, что особенно критично для подписок VPN.

Проверка работы и имитация сбоя

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

На ноде можно добавить правило iptables, блокирующее входящие соединения с вашего клиентского IP на порт 443: sudo iptables -A INPUT -s <ваш-клиентский-IP> -p tcp --dport 443 -j DROP. Если после этого клиент через CDN остаётся онлайн, значит, фронт настроен правильно. Это важный тест, так как он подтверждает, что трафик идёт через CDN, а не напрямую.

Также стоит проверить, что CDN не кэширует трафик. Для этого можно посмотреть заголовки ответов — они должны содержать Cache-Control: no-cache. Если кэш включён, вы рискуете получать устаревшие данные, что особенно критично для VPN-подписок, которые должны обновляться.

Ограничения и подводные камни CDN-фронтов

Несмотря на эффективность, CDN-фронты имеют ряд ограничений. Во-первых, не все CDN входят в белые списки операторов. Whitelist у разных операторов отличается, и даже внутри одного CDN одни подсети могут быть доступны, а другие — нет. Поэтому необходимо проверять каждую /24 отдельно.

Во-вторых, CDN — это платная услуга, и стоимость может оказаться выше, чем ожидалось. XHTTP генерирует множество мелких HTTP-запросов, и некоторые CDN тарифицируют именно количество запросов, а не только трафик. Это может существенно увеличить расходы при большом количестве пользователей.

В-третьих, использование CDN добавляет дополнительный сетевой хоп, что увеличивает задержку. Для веб-сёрфинга это незаметно, но для онлайн-игр или голосовых звонков может быть критично. Также CDN может обрывать длительные соединения, особенно WebSocket, что требует настройки таймаутов.

Наконец, важно защищать origin-сервер. Если реальный IP ноды станет известен (например, через старые DNS-записи или утечку в сертификате), блокировка будет применена напрямую, и CDN-фронт потеряет смысл. Рекомендуется настроить файрвол так, чтобы принимать соединения на порт 443 только с IP-диапазонов вашего CDN.

Альтернативные подходы и резервные стратегии

CDN-фронт — не единственный способ обхода белых списков, и его стоит комбинировать с другими методами. Например, можно использовать подмену SNI (Server Name Indication) — когда клиент отправляет запрос с именем разрешённого домена (например, vk.com), а реальный трафик идёт на ваш сервер. Этот метод работает, если фильтрация основана только на SNI, но он уязвим к более продвинутым DPI-системам, которые проверяют и другие параметры.

Другой подход — использование облачных сервисов, таких как Yandex Cloud, которые могут иметь IP-адреса, входящие в белые списки. Создание виртуальной машины в таком облаке и настройка VPN на ней может обеспечить доступ, если IP-пул облака разрешён. Однако это работает не всегда и зависит от политики оператора.

Также существуют специализированные whitelist-CDN, которые целенаправленно держат свои диапазоны в разрешённых списках под задачу фронта для VPN-нод. Это коммерческие решения, которые гарантируют доступность, но стоят дороже обычных CDN. Для бизнеса, которому критична доступность сайта, такие решения могут быть оправданы.

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

Практические рекомендации для бизнеса и пользователей

Для владельцев сайтов, которые хотят сохранить доступность во время белых списков, важно понимать, что заставлять клиентов использовать VPN — плохая стратегия. Это снижает конверсию и создаёт барьеры. Вместо этого стоит рассмотреть настройку CDN-инфраструктуры, которая позволит сайту открываться напрямую, без дополнительных действий со стороны посетителей.

При выборе CDN-провайдера обращайте внимание на его присутствие в белых списках основных операторов. Крупные CDN, обслуживающие банки и госуслуги, имеют больше шансов быть разрешёнными. Также важно проверить, поддерживает ли CDN необходимые протоколы (XHTTP, WebSocket) и не блокирует ли POST-запросы.

Для обычных пользователей, которые хотят обойти белые списки, рекомендуется использовать VPN-клиенты с поддержкой подписок, которые автоматически обновляют конфигурации. Многие клиенты, такие как v2rayNG, Nekobox, Invizible, позволяют импортировать подписки и переключаться между серверами. Также полезно иметь несколько запасных конфигураций с разными SNI и транспортами.

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

Вопросы и ответы