Что такое белый список и почему в него нельзя «просто попасть»
Белый список (allowlist) — это режим, при котором оператор связи пропускает трафик только к заранее одобренному набору IP-адресов и доменов, а всё остальное блокирует по умолчанию. Это зеркальная противоположность привычной блокировке: там запрещают конкретные сайты, здесь — разрешают конкретные и режут всё остальное.
В России такой режим включают при веерных (региональных) отключениях мобильного интернета — точечно, на часы или дни, обычно по решению властей региона. В типичный белый список у ряда операторов попадают:
- госсервисы (Госуслуги, сайты ведомств);
- крупные банки и платёжные системы;
- маркетплейсы (Ozon, Wildberries) и часть e-com;
- иногда — инфраструктура и CDN Яндекса и VK, потому что через них работают карты, такси и доставка.
Точный состав списка операторы не публикуют и он различается по регионам и датам, поэтому конкретику стоит воспринимать как наблюдаемую закономерность, а не как официальный перечень.
Ключевой момент: фильтрация идёт на уровне сети оператора и ТСПУ, до того как трафик выйдет в интернет. Поэтому «попасть в список» настройкой на телефоне нельзя — решает не ваше устройство, а то, куда адресован первый пакет. Единственный способ пройти — сделать так, чтобы ваш трафик по всем сетевым признакам вёл к ресурсу, который уже разрешён.
Почему обычный VPN не помогает при веерных отключениях
Обычный коммерческий VPN арендует серверы в дата-центрах. Их IP принадлежат хостингам (Hetzner, DigitalOcean, OVH и т. п.) и в белые списки не входят. Когда оператор переходит в режим allowlist, происходит вот что:
- Приложение VPN пытается открыть соединение к IP вашего сервера.
- Этот IP не в списке разрешённых → оператор молча роняет пакеты (обычно без RST, просто drop).
- Клиент бесконечно «подключается» и отваливается по таймауту.
Не спасает и смена протокола. WireGuard, OpenVPN, голый VLESS или Shadowsocks упираются в одну стену: фильтр отсекает по адресу назначения, а не по содержимому. Даже идеально замаскированный протокол бесполезен, если пакет адресован в заблокированную по умолчанию сеть — до анализа трафика дело не доходит.
| Признак | Обычный VPN | Что видит оператор в режиме allowlist |
|---|---|---|
| IP назначения | дата-центр (хостинг) | нет в списке → блок |
| Домен (SNI) | vpn.example.com | нет в списке → блок |
| Протокол | WireGuard/OpenVPN/VLESS | не важен, до проверки не доходит |
| Итог | — | соединение не устанавливается |
Вывод жёсткий, но честный: если провайдер обещает «работает при любых блокировках», а под капотом обычный сервер на хостинге, — при веерном отключении он не работает. Проходит только то, что для сети неотличимо от белого ресурса.
Как обходить белые списки: трафик через whitelisted-ресурс
Рабочая логика одна: заставить свой трафик идти через ресурс, который уже в белом списке. На практике это почти всегда CDN (сеть доставки контента) крупного российского игрока — именно CDN операторы оставляют включёнными, иначе перестанут работать карты, банки и госсервисы.
Есть два практических подхода.
1. VPN на whitelisted-CDN. Клиент подключается не к «голому» серверу, а к домену, который обслуживается белым CDN. Для оператора соединение выглядит как обычный запрос к разрешённому CDN: IP из белой подсети, правильный SNI, обычный HTTPS/HTTP3-трафик. CDN проксирует запрос до вашего реального сервера, где работает VPN-логика. Технически это обычно VLESS поверх XHTTP или HTTPUpgrade за CDN.
2. Домен-фронтинг (domain fronting) через белый CDN. Приём, при котором «внешний» адрес запроса (то, что видит оператор — SNI и IP) указывает на разрешённый домен CDN, а «внутренний» (заголовок Host внутри зашифрованного HTTPS) — на ваш сервис на том же CDN. Снаружи всё выглядит как обращение к белому домену; настоящий адресат скрыт внутри TLS. Работает только пока CDN допускает несовпадение внешнего и внутреннего хоста — многие крупные провайдеры (включая Google и Cloudflare) это ограничили ещё в 2018 году, так что метод сильно зависит от конкретного CDN.
Именно этот принцип лежит в основе подхода whitelist-CDN как сервис для VPN-операторов: оператор ставит перед своими серверами легальный CDN-домен, и его трафик для сети выглядит «белым». Для одиночного пользователя вывод простой — важно не «какой VPN», а через какую инфраструктуру он ходит.
| Подход | Что видит оператор | Плюс | Ограничение |
|---|---|---|---|
| VPN на whitelisted-CDN | запрос к белому CDN | стабильно при allowlist | нужен провайдер с такой инфраструктурой |
| Домен-фронтинг | белый SNI, скрытый Host | не нужен свой сервер-фронт | CDN часто запрещает fronting |
| Обычный VPN | дата-центровый IP | — | не проходит allowlist |
Механика: как трафик проходит через белый CDN
Чтобы понять, почему это работает, разложим путь пакета по шагам.
- Клиент → белый домен. Приложение открывает HTTPS-соединение к домену вида
cdn.example.ru, который резолвится в IP из сети CDN. Эта /24-подсеть (например, Яндекса или российского CDN) входит в белый список оператора. - Оператор проверяет и пропускает. ТСПУ видит разрешённый IP и разрешённый SNI → пакет проходит. Именно здесь решается всё.
- CDN принимает и проксирует. Edge-узел получает запрос и по своим правилам форвардит его на origin — ваш сервер с VPN-логикой.
- Origin отвечает через CDN. Ответ идёт обратно тем же путём; для оператора это обычная отдача контента с белого CDN.
Технические нюансы, из-за которых «в одном приложении работает, в другом нет»:
- CDN часто не пропускает POST или требует конкретный режим передачи. Если edge отдаёт только GET, транспорт нужно явно перевести в upload-режим (в XHTTP это
packet-up) через отдельный поток. Клиент, который этого не умеет, будет молча падать — при этом на том же сервере другой клиент подключится. - Кэширование. CDN может кэшировать ответы; для туннеля обязательны заголовки
no-cache, иначе соединение «залипает» на закэшированном ответе. - HTTP/2 против HTTP/3. Не все связки CDN+клиент одинаково стабильны; иногда выручает принудительный HTTP/1.1 Upgrade.
Для пользователя вывод практичный: стабильность зависит не от бренда приложения, а от того, насколько аккуратно у сервиса настроена связка с CDN.
Обход белых списков на мобильном интернете
Мобильный интернет — главный сценарий: веерные отключения бьют в первую очередь по сотовым сетям, а не по домашнему проводному интернету. Особенности мобильного случая:
- CGNAT и общие IP. У мобильных операторов вы за большим NAT, но на исходящую фильтрацию по белому списку это не влияет — фильтр смотрит на адрес назначения, а не на ваш.
- Домашний проводной интернет часто живёт дольше. Если рядом есть Wi-Fi от домашнего провайдера, при отключении именно мобильного сегмента он может работать штатно. Первый практический шаг — проверить, не остался ли доступ по Wi-Fi.
- iOS-клиенты капризны к обновлению конфигурации. Ряд приложений на iOS (например, Happ) агрессивно кэширует подписку. Если после смены сервера ничего не подключается, помогает удалить и заново добавить профиль подписки, а не просто нажать «обновить».
Порядок действий на телефоне при подозрении на белый список:
- Проверьте, открываются ли Госуслуги/банк/маркетплейс, но не открывается всё остальное, — это признак allowlist, а не обычного сбоя сети.
- Переключитесь на Wi-Fi, если он есть, — этот сегмент может быть не затронут.
- Если пользуетесь VPN — убедитесь, что он ходит через whitelisted-CDN, а не через обычный сервер. Обычный при allowlist не подключится.
- При проблемах на iOS — пересоздайте профиль подписки (delete + re-add).
Обход белых списков бесплатно — честно, без обещаний
Запрос «обход белых списков бесплатно» понятен, но здесь важно называть вещи своими именами. Инфраструктура на белом CDN стоит денег: трафик через российский whitelist-CDN обходится примерно в 0,6–2,8 ₽ за гигабайт плюс оплата за запросы, и кто-то это оплачивает. Если сервис бесплатный, за него платите либо вы (данными, рекламой), либо он держится на энтузиазме и потому нестабилен.
Что бывает под вывеской «бесплатно» и какие риски:
| Вариант | Как обычно устроено | Риск |
|---|---|---|
| Публичные бесплатные VPN | обычные хостинг-серверы | при allowlist не работают вовсе |
| Бесплатные подписки в Telegram | общие ключи на перегруженных серверах | нестабильно, ключи быстро отваливаются |
| «Бесплатные» приложения из сторов | монетизация через данные/рекламу | логирование и перепродажа истории трафика |
| Свой сервер за whitelisted-CDN | вы платите за CDN сами | требует навыков, но контроль полный |
Честный расклад:
- Полностью бесплатного и одновременно стабильного обхода белых списков не существует — нужен платный whitelisted-канал.
- Условно бесплатно реально для технически подкованных: свой VLESS-сервер + аккаунт у CDN, где вы платите только за реальный трафик. При аккуратной настройке это дешевле любой подписки, но это работа, а не кнопка.
- Не ставьте случайные бесплатные VPN из сторов ради обхода блокировок — риск, что трафик логируется и перепродаётся, выше пользы.
Если нужен рабочий вариант без возни — выбирайте платный сервис, который прямо показывает, что ходит через whitelisted-CDN, а не просто пишет «обходит любые блокировки».
Впн с обходом белого списка: чек-лист выбора
Короткий практический список, по которому можно оценить любой VPN на устойчивость к белым спискам:
- Спросите про инфраструктуру. Есть ли фронт через whitelisted-CDN (Яндекс, VK, российский CDN)? Ответ «у нас обычные серверы в Европе» означает, что при allowlist сервис не сработает.
- Проверьте протокол-обёртку. VLESS поверх XHTTP/HTTPUpgrade за CDN — рабочий признак; голый WireGuard/OpenVPN на дата-центровом IP — нет.
- Уточните про GET/POST и кэш. Зрелый провайдер знает, что CDN может требовать GET-режим (
packet-up) иno-cache, — это признак, что связка реально тестировалась в бою, а не «на бумаге». - Тест в реальных условиях. По-настоящему проверить устойчивость можно только во время реального веерного отключения. Гипотезы «должно работать» не считаются — многие решения, работающие при обычной блокировке, отваливаются при allowlist.
- Оцените честность. Обещание «100% всегда работает бесплатно» — красный флаг. Устойчивый обход стоит денег и имеет ограничения.
Для операторов и энтузиастов вывод тот же, что и для пользователей: устойчивость даёт не выбор протокола, а то, что ваш трафик неотличим от обращения к уже разрешённому белому ресурсу.