Это — всё что вам надо знать о белых списках: как устроены и 6 способов обхода

Привет!

Думаю вы уже в курсе что происходит в РФ с белыми списками. кратко: в РФ работают белые списки, ТСПУ в режиме drop-all пропускает только одобренные IP + SNI, рунет медленно но верно становится ИнТрАнЕтОм. Я об этом писал в Чебурнет 2026 ^[1] и DPI IS ALL YOU NEED ^[2], но там было больше про историю и законы.

А здесь будет только техника. как это работает, как мы это сканировали, что нашли.

Статья основана на результатах сканирования белых списков через мобильный интернет Мегафона. Весь код и данные лежат в репозитории - openlibrecommunity/twl ^[3] (обновляется в идеале еженедельно).

Что такое белые списки

Если у вас открывается vk.com ^[4] но не открывается google.com ^[5] - Это ТСПУ работающий в режиме белых списков. Физический сигнал у вас есть. Байты идут. Просто ТСПУ решает какие байты пропустить, а какие дропнуть.

Классические блокировки работают по принципу чёрных списков - "запрещено X, Y, Z, остальное можно". Белые списки работают наоборот: запрещено всё, кроме явно разрешённого.

Архитектура фильтрации: L3 + L7

Начнём с самого важного. Белые списки работают на двух уровнях одновременно.

Уровень 1 (L3, сетевой) - CIDR-фильтрация по IP. Список разрешённых подсетей. Пакет идёт не к разрешённому IP -> drop на маршрутизаторе ещё до DPI.

Уровень 2 (L7, приложения) - DPI проверяет SNI в ClientHello. Даже если IP разрешён, но SNI в чёрном списке - RST.

Порядок такой:

Пакет → [L3: IP в белом списке?]
          ↓ НЕТ → DROP (пакет просто исчезает)
          ↓ ДА
       [L7: SNI в чёрном списке?]
          ↓ ДА → RST (соединение рвётся)
          ↓ НЕТ → PASS (трафик идёт)

Разберём оба уровня по порядку.

L3: пакеты физически не выходят наружу

Для не-вайтлист IP (Google, Telegram, Twitter) не работает вообще ничего. Ни ICMP, ни TCP:80, ни TCP:443, ни произвольный UDP. 100% packet loss по всем направлениям.

Пакеты физически не покидают сеть оператора. Маршрутизатор на 2-м прыжке просто не пускает трафик дальше, если dst IP не в списке.

Для вайтлист IP картина другая:

TCP 80/443/22 работают. Всё остальное мимо. Фильтрация идёт не только по IP, но и по портам. UDP режется почти весь - включая QUIC, DNS и логично WireGuard на стандартных портах. в зависимости от оператора ситуация может меняться, но обычно все именно так.

L7: как ТСПУ читает SNI

Если IP в белом списке, ТСПУ смотрит на SNI внутри TLS ClientHello.

Для проверки - берём вайтлист IP Яндекса и пытаемся подключиться с разными SNI:

google.com ^[5] прошёл. Казалось бы, странно - гугл же заблокирован. Но нет, гугл заблокирован только по IP, а в чёрном списке SNI его нет. Моя теория - если бы туда запихнули google.com ^[5] - легли бы тысячи легитимных сервисов, которые ходят на Google API через свои собственные IP. Поэтому в SNI-блеклисте только совсем явные вещи: твиттер, отдельные домены заблокированных ресурсов и... но почему то заблокированный telegram SNI все равно отдает OK, почему - я так и не выяснил.

Забавный нюанс - правила SNI-фильтрации неконсистентны между подсетями:

Один и тот же SNI через Яндекс пропускается, через VK и MAX - режется. Либо правила ТСПУ разные для разных ASN, либо на каких-то узлах их забыли обновить. Факт в том, что единого общего чёрного списка SNI нет.

Где физически сидит ТСПУ

Когда пакет идёт по сети, у него есть счётчик - TTL. Каждый роутер на пути уменьшает его на единицу. Линукс начинает с 64. Получил пакет с TTL 53 - значит он прошёл 11 роутеров. Получил с TTL 62 - всего два.

Теперь смотрим что приходит от Яндекса и что приходит от Телеграма (заблокированного):

• Ответ от ya.ru ^[6] - TTL 53. Одиннадцать хопов, это настоящий сервер где-то далеко.

• "Ответ" от Telegram - TTL 62. Два хопа. Не может сервер Телеграма быть так близко.

Значит никакого ответа от Телеграма не было. Ответ сгенерировало устройство которое стоит прямо у оператора, сразу за первым роутером:

[Ты] → [роутер оператора] → [ТСПУ] → [интернет]

Сканирование: что внутри белого списка

Если ТСПУ отвечает RST для заблокированных IP и пропускает только разрешённые - значит можно просто прогнать masscan по всем российским подсетям через интерфейс с БС и получить полный список того, что пропускается.

Так и сделали. Источник - 80 600 российских подсетей (RU allocation от RIPE). Логика: порт 443 открылся через БС — значит IP в списке.

Дисклеймер: мы любители. Masscan долбит как сумасшедший и теряет пакеты пачками, половина IP на 443 просто никого не слушает, часть отвечает через раз. Реальные цифры могут плавать на 20-30%. Но мы не академический институт с финансированием и не пишем статью в журнал, для понимания масштаба хватит.

Итого: 63 126 IP в белом списке. 2 557 уникальных ASN. Из 46 миллионов российских адресов через БС пропускается ~0.14%.

Топ-15 ASN по количеству IP:

Яндекс.Облако - 12 906 IP. Каждый пятый адрес в белом списке принадлежит им. Yandex.Cloud ^[10] тупо хостит половину сервисов, от которых зависит государство, и выкинуть его из БС невозможно. Именно поэтому это главная точка для обхода .

VK через три разных ASN набирает ~3000 IP. Selectel - почти 2000 через два ASN. Timeweb - 2904. Мобильные операторы тоже в списке - МТС (531), Билайн (884), МегаФон (236), их внутренняя инфраструктура.

А еще почему то мемы.смешные.online нету в белых списках, кто знает почему?

Что не так с этим списком

Агрегировал все IP в /24 подсети. Считал плотность - сколько IP из 256 попадает в БС.

Максимальная плотность: 37.5%. Подсетей с плотностью 50%+: ноль.

Почему не 100%? Потому что masscan находит только IP где реально что-то слушает на 443. В подсетях много пустых адресов без серверов. Но фильтрация-то идёт по CIDR целиком - то есть вся подсеть /24.

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

DNS в режиме белых списков

Отдельная история с DNS у МЕГАФОНА. Проверял доступность разных DNS-серверов.

Все внешние DNS - TIMEOUT:

Порт UDP:53 на любые внешние DNS закрыт. Работает только DNS самого провайдера.

Пример - curl max.ru ^[12] резолвится и работает, потому что использует DNS Мегафона. Попробуй dig @8.8.8.8 ya.ru ^[6] - timeout.

И опять - это зависит от провайдера. У разных операторов разные правила.

География: где и когда работает БС

Белые списки работают неравномерно:

Зависит от региона И от провайдера. У Мегафона и Т2 в одном регионе БС работает постоянно, в другом включается по расписанию. У МТС свои правила. У Билайна свои.

Даже не регионы — районы. Точки. Едешь по городу и видишь полную энтропию: на одной остановке работает один IP, на следующей он уже недоступен, а ещё через километр БС вообще отключены и интернет внезапно нормальный. Что именно в белом списке - тоже меняется от точки к точке. Подробнее в разделе про приоритеты.

Вот наглядный пример из чата olc ^[13] - человек в реальном времени описывает, как обход БС и сам БС работают от вышки к вышке.

Кстати, обход тут через olcng ^[14], наш бесплатный opensource инструмент.

И списки тоже разные у разных операторов. Одна подсеть в БС у Мегафона может не быть у МТС.

Списки постоянно меняются. Что-то добавляют, что-то убирают. Поэтому у нас в olc есть репа где это еженедельно обновляется - openlibrecommunity/twl ^[3].

Приоритеты в белых списках

После анализа получается такая иерархия:

1 уровень (обязательный) - max.ru ^[12]. Всегда в БС. У всех. Везде. Этот мессенджер можно даже не проверять - он работает всегда.

2 уровень (почти всегда) - vk.com ^[4], ya.ru ^[6], Государственно значимая инфраструктура.

3 уровень (необязательный) - банки, маркетплейсы, прочие сервисы. Тут лотерея: у Мегафона может быть Тинькофф, а у МТС - нет. Логики никакой.

Забавная деталь: почти все банки в БС - кроме Сбербанка. При этом salutejazz.ru ^[15] - сервис видеозвонков от сбера - есть. Крупнейший банк страны недоступен, а его корпоративная видеозвонилка которой пользуется полтора землекопа - пожалуйста.

Отдельный жанр: VPN в белом списке

Когда просканировал список доменов по whitelisted IP, обнаружил кое-что. В белом списке полно VPN-сервисов. Государство душит VPN на L7 через TLS-фингерпринты, режет протоколы, банит сервисы - а в собственном белом списке лежат сотни серверов со словом vpn в домене. Вот просто навскидку:

• zalupavpn.dpdns.org ^[16] - без комментариев.

• vpn.gov45.ru - государственный VPN (Курганская область)

• russvpn.ru ^[17], vpn-russia.cherna.ru ^[18] - патриотические, тоже пропускаются.

И это только VPN. А ещё есть GitLab.

Пока рыл список, случайно наткнулся на ittask-git.gitlab.yandexcloud.net ^[19]. Попробовал curl через БС:

Открывается. Страница логина GitLab, через мобильный инет в режиме белых списков. Не через VPN, не через прокси - напрямую.

Что не работает в БС

Сначала закроем тему методов которые не помогут ( в зависимости от провайдера может менятся ):

QUIC/HTTP3 - иногда блокируется даже на домашних провайдерах без БС. UDP:443 режется. В режиме БС тем более.

ECH/ESNI (Encrypted Client Hello) - блокируется ТСПУ. И даже если бы работал, не помог бы. Потому что основная блокировка идёт по IP (L3), а не по SNI. Шифровать имя домена бесполезно, когда сам адрес назначения не в белом списке.

Обычный VPN на обычном VPS ^[20] за границей - не работает тк IP не в БС.

Что работает и как их обойти

Метод 1: VLESS + Reality на российском VPS

Основной метод. Работает стабильно, относительно просто настраивается.

Требования:

1. IP сервера в белом списке (VPS ^[20] у Timeweb/Yandex/VK)

2. SNI whitelisted домена (vk.com ^[4], ya.ru ^[6], vklive.enotfast.com ^[21])

3. Reality + XTLS-Vision для маскировки

Пример конфига:

vless://UUID@IP:443?type=tcp&security=reality&pbk=...&fp=chrome&sni=vklive.enotfast.com&sid=...&flow=xtls-rprx-vision

Где брать VPS ^[20]:

Хорошие SNI для маскировки (из сканирования 1176 whitelisted доменов):

• Яндекс CDN: storage.yandex.net ^[22], yastatic.net ^[23]

• VK CDN: userapi.com ^[24], vkuser.net ^[25], vkuservideo.ru ^[26]

• Хостинги: hosting.reg.ru ^[27]

• CDN: cdnvideo.ru ^[28], okcdn.ru ^[29]

• Остальные из списка openlibrecommunity/twl ^[30]

Опасные SNI - те которые проверяются:

• twitter.com ^[7] / x.com ^[31] / youtube.com ^[9] - RST через некоторые IP

• Всё что очевидно заблокировано

Метод 2: Yandex Cloud Functions

Serverless-функция как прокси. Эндпоинт functions.yandexcloud.net ^[32] универсально в БС у всех провайдеров.

Free tier (бессрочный, ежемесячно):

• 1 000 000 вызовов

• 100 000 ГБ-секунд

• 40 000 ГГц-секунд

Пишешь SOCKS5 клиент, подключаешь к функции - готово. DPI не применяется к IP Яндекса на уровне L3 и L7, домены *.yandexcloud.net ^[33] в белом списке SNI/CIDR у всех провайдеров.

Минусы - нужна карта для верификации Yandex Cloud, производительность хуже чем у прямого VPS ^[20].

Метод 3: Yandex API Gateway (Reverse Proxy)

Новый способ от olc, представляющий собой настоящий абуз инфраструктуры Яндекса. Мы используем Yandex API Gateway как прокладку (зеркало) между нами и нашим сервером (VPS ^[20]), IP которого не входит в белые списки.

Как это настроить:

1. Берем свой домен. например, furry.xiqull.xyz ^[34] и делегируем его на Cloudflare.

2. Идем в Yandex Cloud -> Certificate Manager. Выпускаем бесплатный Let's Encrypt сертификат на наш домен.

   

3. Проходим валидацию: добавляем CNAME запись _acme-challenge... в Cloudflare указывающую на сервер Яндекса, выключаем "оранжевое облако", оставляя проксирование только по DNS, Ждем выпуска сертификата.

   

4. Создаем API Gateway в Yandex Cloud.

   

5. В спецификации OpenAPI прописываем проксирование всех запросов на IP (или домен) вашего сервера, на котором крутится Nginx.

   

6. В разделе "Домены" вашего API-шлюза привязываем наш домен и выпущенный сертификат.

7. 

8. Наконец, в Cloudflare добавляем CNAME запись, которая направляет наш домен на служебный домен Yandex API-шлюза

   

Пример OpenAPI спецификации для шлюза:

openapi: 3.0.0
info:
  title: имя
  version: 1.0.0
servers:
- url: https://ур.лэ.apigw.yandexcloud.net
- url: https://са.й.т
paths:
  /{proxy+}:
    x-yc-apigateway-any-method:
      x-yc-apigateway-integration:
        type: http
        url: http://а.й.п.и/{proxy}
      parameters:
      - explode: false
        in: path
        name: proxy
        required: true
        schema:
          type: string
        style: simple
  /:
    get:
      x-yc-apigateway-integration:
        type: http
        url: http://а.й.п.и/

Трафик от вас пойдет на железобетонно разрешенные IP Yandex Cloud API Gateway, который легитимно терминирует TLS (сертификат-то настоящий) и проксирует HTTP/HTTPS трафик на ваш спрятанный сервак.

Метод 4: olcRTC - туннель через видеозвонки

Мой проект. Писал про него отдельную статью ^[35]. Принцип: паразитируем на whitelisted сервисах видеозвонков. Трафик идёт через WebRTC SFU. самый сложный в настройке но почти бесплатный и работает везде где работает telemost/jazz/wbstream.

Каналы:

Сервисы: telemost.yandex.ru ^[36], salutejazz.ru ^[15], stream.wb.ru ^[37].

Самый стабильный - wbstream от Wildberries. У них почти нет прослойки посередине которая анализирует трафик, почти прямой relay. Говнокод спасает.

Статус: пре-альфа. Подробности в репо openlibrecommunity/olcrtc ^[38].

Метод 5: xDNS

Туннелирование через DNS-запросы.

Работает только там где UDP:53 к внешним DNS открыт.

Схема:

Клиент → 8.8.8.8 → "кто NS для f.example.com?" → fns.example.com (твой сервер:53) → Xray

Скорость низкая - природа DNS-протокола. Не для HD-видео, но для текста и ssh хватит.

Метод 6: TURN relay

Использование публичных TURN серверов VK/Яндекса для relay WireGuard.

Работает - но быстро банят. Яндекс уже заточил свои TURN серверы relay'ить только на IP Яндекса. VK натыкал капч.

Время жизни: непредсказуемо. Но дырка новая появляется регулярно, потому что компании сами же их и делают. есть реализация от cacggghp/vk-turn-proxy ^[39]

Битва методов

Обычный ТСПУ никуда не делся

Кстати: белые списки это не замена обычных блокировок, а слой поверх них. Тот же ТСПУ что на домашнем провайдере рубит запрещённые домены по чёрному списку и палит VPN по TLS-фингерпринтам - здесь работает точно так же. Просто до него твои пакеты ещё должны пройти через L3-фильтр белого списка.

Это значит:

• Нужна маскировка под браузер (uTLS в Xray/Sing-box)

• fp=chrome или fp=firefox в конфиге обязательно

• Reality сама по себе не спасает если фингерпринт палевный

• Всё что блокируется на домашнем инете - блокируется и тут, сверху

Что делать сейчас

Да ничего особо. На домашнем инете чебурнет не наступит, БС - это история про мобильный инет, и то не везде.

Так что подписывайся на наш тгк ^[13], там выкладываем новые способы и обновлённые списки.

Итого

Запрещено всё, разрешено избранное.

Что мы точно знаем по экспериментам:

• Фильтрация двухуровневая: L3 (IP) + L7 (SNI)

• ТСПУ на 2-м хопе, генерирует RST для заблокированных IP

• UDP режется почти полностью - DNS, QUIC, WireGuard

• 63 тысячи IP в белом списке из 46 миллионов.

• Работает неравномерно - по регионам, районам и провайдерам

• У каждого оператора свой белый список. Но есть те кто в нём всегда.

Что работает для обхода:

• VLESS + Reality на российском VPS ^[20] - основной метод

• Yandex Cloud Functions - универсальный вариант

• olcRTC - экспериментально, через видеозвонки

• xDNS - если UDP:53 открыт

Наши контакты

• Гитхаб: openlibrecommunity ^[40]

• Код сканера и пруфы: openlibrecommunity/twl ^[3]

• Телеграм канал: t.me/openlibrecommunity ^[13] ( фри прокси для обхода бс в закреп посте )

• По проблемам: zarazaex@tuta.io ^[41]

UPD: ребята, мой сайт шипко.смешные.online ^[42] теперь в БС, не рофл, сами чекните

UPD: я не спал часов 13, пишу эту статью, мой баланс на симке ушел в минус, я не знаю залетит ли это, я не знаю что со мной будет и одобрят ли статью, LOL

UPD: еще есть темка с абузом сертификатов для обхода БС, но об этом как нить позже

UPD: оказывается хабр есть в БС