Привет, Хабр!
Думаю вы уже в курсе что происходит в РФ с белыми списками. кратко: в РФ работают белые списки, ТСПУ в режиме drop-all пропускает только одобренные IP + SNI, рунет медленно но верно становится ИнТрАнЕтОм. Я об этом писал в Чебурнет 2026 и DPI IS ALL YOU NEED, но там было больше про историю и законы.
А здесь будет только техника. как это работает, как мы это сканировали, что нашли.
Статья основана на результатах сканирования белых списков через мобильный интернет Мегафона. Весь код и данные лежат в репозитории - openlibrecommunity/twl (обновляется в идеале еженедельно).
Что такое белые списки
Если у вас открывается vk.com но не открывается google.com - Это ТСПУ работающий в режиме белых списков. Физический сигнал у вас есть. Байты идут. Просто ТСПУ решает какие байты пропустить, а какие дропнуть.
Классические блокировки работают по принципу чёрных списков - "запрещено 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 картина другая:
Протокол/порт
Статус
ICMP
OK
TCP:80
OK
TCP:443
OK
UDP:443 (QUIC)
NO_RESP
UDP:53
NO_RESP
UDP:51820 (WireGuard)
NO_RESP
TCP 80/443/22 работают. Всё остальное мимо. Фильтрация идёт не только по IP, но и по портам. UDP режется почти весь - включая QUIC, DNS и логично WireGuard на стандартных портах. в зависимости от оператора ситуация может меняться, но обычно все именно так.
L7: как ТСПУ читает SNI
Если IP в белом списке, ТСПУ смотрит на SNI внутри TLS ClientHello.
Для проверки - берём вайтлист IP Яндекса и пытаемся подключиться с разными SNI:
SNI
Результат
TLS handshake OK, HTTP 302
TLS handshake OK, HTTP 406
Connection reset by peer
TLS handshake OK, HTTP 406
google.com прошёл. Казалось бы, странно - гугл же заблокирован. Но нет, гугл заблокирован только по IP, а в чёрном списке SNI его нет. Моя теория - если бы туда запихнули google.com - легли бы тысячи легитимных сервисов, которые ходят на Google API через свои собственные IP. Поэтому в SNI-блеклисте только совсем явные вещи: твиттер, отдельные домены заблокированных ресурсов и... но почему то заблокированный telegram SNI все равно отдает OK, почему - я так и не выяснил.
Забавный нюанс - правила SNI-фильтрации неконсистентны между подсетями:
SNI
через 77.88.55.242 (Яндекс)
через 87.240.132.78 (VK)
через 217.20.147.1 (MAX)
OK
FAIL
OK
OK
OK
OK
FAIL
Один и тот же SNI через Яндекс пропускается, через VK и MAX - режется. Либо правила ТСПУ разные для разных ASN, либо на каких-то узлах их забыли обновить. Факт в том, что единого общего чёрного списка SNI нет.
Где физически сидит ТСПУ
Когда пакет идёт по сети, у него есть счётчик - TTL. Каждый роутер на пути уменьшает его на единицу. Линукс начинает с 64. Получил пакет с TTL 53 - значит он прошёл 11 роутеров. Получил с TTL 62 - всего два.
Теперь смотрим что приходит от Яндекса и что приходит от Телеграма (заблокированного):
Ответ от ya.ru - 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:
#
ASN
Организация
IP
1
AS200350
12 906
2
AS9123
Timeweb
2 904
3
AS12389
Ростелеком
2 312
4
AS47764
VK
1 958
5
AS34879
ССТ
1 806
6
AS198610
Beget
1 644
7
AS57363
CDNvideo
1 638
8
AS29182
IOT
1 591
9
AS197695
1 380
10
AS49505
Selectel
1 037
11
AS13238
YANDEX LLC
978
12
AS50340
Selectel
917
13
AS3216
Билайн
884
14
AS210079
EuroByte
869
15
AS47541
VK
791
Яндекс.Облако - 12 906 IP. Каждый пятый адрес в белом списке принадлежит им. Yandex.Cloud тупо хостит половину сервисов, от которых зависит государство, и выкинуть его из БС невозможно. Именно поэтому это главная точка для обхода .
VK через три разных ASN набирает ~3000 IP. Selectel - почти 2000 через два ASN. Timeweb - 2904. Мобильные операторы тоже в списке - МТС (531), Билайн (884), МегаФон (236), их внутренняя инфраструктура.
А еще почему то мемы.смешные.online нету в белых списках, кто знает почему?
Что не так с этим списком
Агрегировал все IP в /24 подсети. Считал плотность - сколько IP из 256 попадает в БС.
Максимальная плотность: 37.5%. Подсетей с плотностью 50%+: ноль.
Плотность
Подсеть
Владелец
37.5%
185.71.67.0/24
Storm Networks
34.4%
95.129.236.0/24
DDOS-GUARD
32.0%
87.240.166.0/24
VK CDN
31.6%
87.240.167.0/24
VK CDN
31.6%
77.88.0.0/24
Яндекс
30.1%
31.31.198.0/24
Почему не 100%? Потому что masscan находит только IP где реально что-то слушает на 443. В подсетях много пустых адресов без серверов. Но фильтрация-то идёт по CIDR целиком - то есть вся подсеть /24.
Вывод: для своего сервера лучше брать IP из подсетей с высокой плотностью, хотя в конце концов это не так уж и роляет.
DNS в режиме белых списков
Отдельная история с DNS у МЕГАФОНА. Проверял доступность разных DNS-серверов.
Все внешние DNS - TIMEOUT:
DNS
Статус
8.8.8.8 (Google)
TIMEOUT
1.1.1.1 (Cloudflare)
TIMEOUT
77.88.8.8 (Яндекс)
TIMEOUT
10.233.58.133 (Мегафон)
РАБОТАЕТ
Порт UDP:53 на любые внешние DNS закрыт. Работает только DNS самого провайдера.
Пример - curl max.ru резолвится и работает, потому что использует DNS Мегафона. Попробуй dig @8.8.8.8 ya.ru - timeout.
И опять - это зависит от провайдера. У разных операторов разные правила.
География: где и когда работает БС
Белые списки работают неравномерно:
Регион
Режим работы
Москва
Эпизодически, ~3 часа
Санкт-Петербург
Редко, бывают недели без БС
Большинство регионов
Постоянно 24/7
Зависит от региона И от провайдера. У Мегафона и Т2 в одном регионе БС работает постоянно, в другом включается по расписанию. У МТС свои правила. У Билайна свои.
Даже не регионы — районы. Точки. Едешь по городу и видишь полную энтропию: на одной остановке работает один IP, на следующей он уже недоступен, а ещё через километр БС вообще отключены и интернет внезапно нормальный. Что именно в белом списке - тоже меняется от точки к точке. Подробнее в разделе про приоритеты.
Вот наглядный пример из чата olc - человек в реальном времени описывает, как обход БС и сам БС работают от вышки к вышке.
Кстати, обход тут через olcng, наш бесплатный opensource инструмент.
И списки тоже разные у разных операторов. Одна подсеть в БС у Мегафона может не быть у МТС.
Списки постоянно меняются. Что-то добавляют, что-то убирают. Поэтому у нас в olc есть репа где это еженедельно обновляется - openlibrecommunity/twl.
Приоритеты в белых списках
После анализа получается такая иерархия:
1 уровень (обязательный) - max.ru. Всегда в БС. У всех. Везде. Этот мессенджер можно даже не проверять - он работает всегда.
2 уровень (почти всегда) - vk.com, ya.ru, Государственно значимая инфраструктура.
3 уровень (необязательный) - банки, маркетплейсы, прочие сервисы. Тут лотерея: у Мегафона может быть Тинькофф, а у МТС - нет. Логики никакой.
Забавная деталь: почти все банки в БС - кроме Сбербанка. При этом salutejazz.ru - сервис видеозвонков от сбера - есть. Крупнейший банк страны недоступен, а его корпоративная видеозвонилка которой пользуется полтора землекопа - пожалуйста.
Отдельный жанр: VPN в белом списке
Когда просканировал список доменов по whitelisted IP, обнаружил кое-что. В белом списке полно VPN-сервисов. Государство душит VPN на L7 через TLS-фингерпринты, режет протоколы, банит сервисы - а в собственном белом списке лежат сотни серверов со словом vpn в домене. Вот просто навскидку:
zalupavpn.dpdns.org - без комментариев.
vpn.gov45.ru - государственный VPN (Курганская область)
russvpn.ru, vpn-russia.cherna.ru - патриотические, тоже пропускаются.
И это только VPN. А ещё есть GitLab.
Пока рыл список, случайно наткнулся на ittask-git.gitlab.yandexcloud.net. Попробовал curl через БС:
Открывается. Страница логина GitLab, через мобильный инет в режиме белых списков. Не через VPN, не через прокси - напрямую.
Что не работает в БС
Сначала закроем тему методов которые не помогут ( в зависимости от провайдера может менятся ):
QUIC/HTTP3 - иногда блокируется даже на домашних провайдерах без БС. UDP:443 режется. В режиме БС тем более.
ECH/ESNI (Encrypted Client Hello) - блокируется ТСПУ. И даже если бы работал, не помог бы. Потому что основная блокировка идёт по IP (L3), а не по SNI. Шифровать имя домена бесполезно, когда сам адрес назначения не в белом списке.
Обычный VPN на обычном VPS за границей - не работает тк IP не в БС.
Что работает и как их обойти
Метод 1: VLESS + Reality на российском VPS
Основной метод. Работает стабильно, относительно просто настраивается.
Требования:
IP сервера в белом списке (VPS у Timeweb/Yandex/VK)
SNI whitelisted домена (vk.com, ya.ru, vklive.enotfast.com)
Reality + XTLS-Vision для маскировки
Пример конфига:
vless://UUID@IP:443?type=tcp&security=reality&pbk=...&fp=chrome&sni=vklive.enotfast.com&sid=...&flow=xtls-rprx-vision
Где брать VPS:
Провайдер
Плюсы
Минусы
Timeweb
Бесплатный reroll IP
Долго выбивать, но дело времени
Бесплатный грант 4000₽ при регистрации, высокий шанс попасть в БС
Быстро сносят
VK Cloud
Долго держится
Сложная верификация и сложно выбивать, дорого
Хорошие SNI для маскировки (из сканирования 1176 whitelisted доменов):
Яндекс CDN: storage.yandex.net, yastatic.net
VK CDN: userapi.com, vkuser.net, vkuservideo.ru
Хостинги: hosting.reg.ru
CDN: cdnvideo.ru, okcdn.ru
Остальные из списка openlibrecommunity/twl
Опасные SNI - те которые проверяются:
twitter.com / x.com / youtube.com - RST через некоторые IP
Всё что очевидно заблокировано
Метод 2: Yandex Cloud Functions
Serverless-функция как прокси. Эндпоинт functions.yandexcloud.net универсально в БС у всех провайдеров.
Free tier (бессрочный, ежемесячно):
1 000 000 вызовов
100 000 ГБ-секунд
40 000 ГГц-секунд
Пишешь SOCKS5 клиент, подключаешь к функции - готово. DPI не применяется к IP Яндекса на уровне L3 и L7, домены *.yandexcloud.net в белом списке SNI/CIDR у всех провайдеров.
Минусы - нужна карта для верификации Yandex Cloud, производительность хуже чем у прямого VPS.
Метод 3: Yandex API Gateway (Reverse Proxy)
Новый способ от olc, представляющий собой настоящий абуз инфраструктуры Яндекса. Мы используем Yandex API Gateway как прокладку (зеркало) между нами и нашим сервером (VPS), IP которого не входит в белые списки.
Как это настроить:
Берем свой домен. например, furry.xiqull.xyz и делегируем его на Cloudflare.
Идем в Yandex Cloud -> Certificate Manager. Выпускаем бесплатный Let's Encrypt сертификат на наш домен.
Проходим валидацию: добавляем CNAME запись _acme-challenge... в Cloudflare указывающую на сервер Яндекса, выключаем "оранжевое облако", оставляя проксирование только по DNS, Ждем выпуска сертификата.
Создаем API Gateway в Yandex Cloud.
В спецификации OpenAPI прописываем проксирование всех запросов на IP (или домен) вашего сервера, на котором крутится Nginx.
В разделе "Домены" вашего API-шлюза привязываем наш домен и выпущенный сертификат.
Наконец, в 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 - туннель через видеозвонки
Мой проект. Писал про него отдельную статью. Принцип: паразитируем на whitelisted сервисах видеозвонков. Трафик идёт через WebRTC SFU. самый сложный в настройке но почти бесплатный и работает везде где работает telemost/jazz/wbstream.
Каналы:
Канал
Статус
Скорость
DataChannel
Работает
до 10 MB/s
V8 Channel
В разработке
~1 MB/s
VideoChannel
В разработке
~100 KB/s
Сервисы: telemost.yandex.ru, salutejazz.ru, stream.wb.ru.
Самый стабильный - wbstream от Wildberries. У них почти нет прослойки посередине которая анализирует трафик, почти прямой relay. Говнокод спасает.
Статус: пре-альфа. Подробности в репо openlibrecommunity/olcrtc.
Метод 5: xDNS
Туннелирование через DNS-запросы.
Работает только там где UDP:53 к внешним DNS открыт.
Схема:
Клиент → 8.8.8.8 → "кто NS для f.example.com?" → fns.example.com (твой сервер:53) → Xray
Скорость низкая - природа DNS-протокола. Не для HD-видео, но для текста и ssh хватит. MAN тут happchat/78343/172504
Метод 6: TURN relay
Использование публичных TURN серверов VK/Яндекса для relay WireGuard.
Работает - но быстро банят. Яндекс уже заточил свои TURN серверы relay'ить только на IP Яндекса. VK натыкал капч.
Время жизни: непредсказуемо. Но дырка новая появляется регулярно, потому что компании сами же их и делают. есть реализация от cacggghp/vk-turn-proxy
Битва методов
Метод
Сложность
Стоимость
Стабильность
Скорость
VLESS + Reality на VPS
Низкая
~2000₽/мес
Высокая
Yandex Functions или API Gateway
Средняя
Бесплатно (free tier каждый месяц)
Высокая
Средняя
olcRTC
Высокая
VPS
?
Средняя
xDNS
Высокая
Домен + VPS
Низкая
TURN relay
Средняя
VPS
Низкая
Средняя
Обычный ТСПУ никуда не делся
Кстати: белые списки это не замена обычных блокировок, а слой поверх них. Тот же ТСПУ что на домашнем провайдере рубит запрещённые домены по чёрному списку и палит VPN по TLS-фингерпринтам - здесь работает точно так же. Просто до него твои пакеты ещё должны пройти через L3-фильтр белого списка.
Это значит:
Нужна маскировка под браузер (uTLS в Xray/Sing-box)
fp=chrome или fp=firefox в конфиге обязательно
Reality сама по себе не спасает если фингерпринт палевный
Всё что блокируется на домашнем инете - блокируется и тут, сверху
Что делать сейчас
Да ничего особо. На домашнем инете чебурнет не наступит, БС - это история про мобильный инет, и то не везде.
Так что подписывайся на наш тгк, там выкладываем новые способы и обновлённые списки.
Итого
Запрещено всё, разрешено избранное.
Что мы точно знаем по экспериментам:
Фильтрация двухуровневая: L3 (IP) + L7 (SNI)
ТСПУ на 2-м хопе, генерирует RST для заблокированных IP
UDP режется почти полностью - DNS, QUIC, WireGuard
63 тысячи IP в белом списке из 46 миллионов.
Работает неравномерно - по регионам, районам и провайдерам
У каждого оператора свой белый список. Но есть те кто в нём всегда.
Что работает для обхода:
VLESS + Reality на российском VPS - основной метод
Yandex Cloud Functions - универсальный вариант
olcRTC - экспериментально, через видеозвонки
xDNS - если UDP:53 открыт
Наши контакты
Гитхаб: openlibrecommunity
Код сканера и пруфы: openlibrecommunity/twl
Телеграм канал:t.me/openlibrecommunity ( фри прокси для обхода бс в закреп посте )
По проблемам: zarazaex@tuta.io
UPD: ребята, мой сайт шипко.смешные.online теперь в БС, не рофл, сами чекните
UPD: я не спал часов 13, пишу эту статью, мой баланс на симке ушел в минус, я не знаю залетит ли это, я не знаю что со мной будет и одобрят ли статью, LOL
UPD: еще есть темка с абузом сертификатов для обхода БС, но об этом как нить позже
UPD: оказывается хабр и докер есть в БС
Обсуждение
Комментарии открыты для зарегистрированных читателей. Ответы остаются рядом с записью и не смешиваются с общей лентой.