← Все статьи

Термин «белые списки» пришёл из сетевой безопасности задолго до того, как его стали обсуждать в новостях о Рунете. В корпоративных сетях whitelist используется десятилетиями: вместо того чтобы пытаться перечислить всё, что нужно блокировать, администратор перечисляет то, что разрешено, и закрывает остальное по умолчанию. Это самая жёсткая модель сетевой фильтрации, и она хорошо описана в учебниках по информационной безопасности. В этой статье разберём белые списки именно как технологию: как они работают, какие у них варианты реализации, какие данные туда попадают и как операторы связи в России применяют этот механизм в 2026 году.

Whitelist vs blacklist: разница на пальцах

В сетевой безопасности есть два полярных подхода к фильтрации трафика:

  • Чёрный список (blacklist). По умолчанию разрешено всё. В список явно вносят то, что нужно запретить. Удобно, когда «плохих» ресурсов немного и они хорошо известны.
  • Белый список (whitelist). По умолчанию запрещено всё. В список явно вносят то, что нужно разрешить. Жёстче, но более предсказуемо: ничего «случайно нового» в сеть не попадёт.

Whitelist часто используется в банковских внутренних сетях, в АСУ ТП на промышленных объектах, в школьных сетях и в любой инфраструктуре, где админ предпочитает явный контроль входов и выходов. У этого подхода есть и обратная сторона: ведение списка — это работа. Любой новый сервис нужно занести вручную, иначе он не заработает.

Где живёт фильтр: уровни проверки

Whitelist можно реализовать на разных уровнях сетевого стека. От уровня зависит, по каким именно признакам система решает, пропустить пакет или нет:

  • L3 — IP-адрес и подсеть. Самый ранний и самый «грубый» способ. Фильтр сравнивает destination IP пакета со списком разрешённых диапазонов. Плюс — крайне быстро. Минус — современные CDN (Cloudflare, Akamai, Fastly) держат миллионы доменов на одних и тех же IP, поэтому только по адресу разрешённое от запрещённого не отделить.
  • L4 — порты и протоколы. Можно дополнительно сузить: например, разрешить только TCP/443 и заблокировать всё остальное. Это уже даёт информацию о типе трафика, но не о его содержимом.
  • L7 — DPI и SNI inspection. Глубокая инспекция пакетов. Фильтр читает первые байты TLS-handshake и достаёт из них SNI (Server Name Indication) — поле, в которое клиент сам пишет имя домена. Если домен в whitelist — пропускаем, иначе соединение рвётся (RST) или замораживается. Этот уровень и используется для большинства современных whitelist-фильтраций.
  • DNS-уровень. Альтернатива: фильтр сидит в роли DNS-резолвера и просто не отдаёт IP для доменов вне списка. Самый простой способ, но обходится сменой DNS-сервера.

В реальной инфраструктуре обычно используется не один уровень, а комбинация. Например, у мобильного оператора PGW может одновременно проверять и IP-подсеть, и SNI: пакет должен соответствовать обоим условиям, иначе сессия не устанавливается.

Что обычно входит в белый список в РФ

Точный состав whitelist-списков у российских операторов не публикуется как единый документ — он формируется и обновляется регуляторами и техническими подразделениями ТСПУ. Но из практических наблюдений и публичных обсуждений (Habr, профильные форумы) вырисовывается типовой набор категорий:

  • Государственные сервисы. Госуслуги, ФНС, Пенсионный фонд России, МВД, региональные порталы услуг, налог.ру, мос.ру.
  • Крупные банки. Сбер, ВТБ, Альфа-Банк, Тинькофф (Т-Банк), Газпромбанк, Россельхозбанк, ОТП, Райффайзен и десятки других. Включая мобильные приложения и API для онлайн-банкинга.
  • Платёжная инфраструктура. НСПК (Мир, СБП), Юmoney, агрегаторы наподобие ЮКасса. Без них не работают платежи в магазинах.
  • Российские IT-гиганты. Яндекс (поиск, почта, карты, такси, маркет, музыка, кинопоиск), VK (ВКонтакте, Mail.ru, Одноклассники, Облако, Дзен), Авито, Wildberries, Ozon, Lamoda.
  • Российский видеохостинг и стриминг. Rutube, VK Видео, Кинопоиск, IVI, Okko, Premier, Wink.
  • Федеральные СМИ. Сайты крупных газет и телеканалов: РИА, ТАСС, RT, Россия 24, Первый, региональные информационные порталы.
  • Операторы связи. Билайн, МТС, Мегафон, Tele2, Yota — собственные сайты, личные кабинеты, IVR-сервисы.
  • Системы мессенджинга в части национальной экосистемы. Max, корпоративные мессенджеры VK Teams, Битрикс24.
  • Здоровье и образование. ЕМИАС, региональные системы записи к врачу, портал диспансеризации, образовательные платформы (РЭШ, Учи.ру).
  • Транспорт и логистика. РЖД, Аэрофлот, S7, Победа, Почта России, СДЭК, Boxberry.

Что обычно в whitelist не входит: глобальные мессенджеры и сервисы, не имеющие российского представительства; зарубежные стриминг-сервисы и медиаплатформы; иностранные банки; сторонние почтовые сервисы вне РФ; сторонние CDN, на которых лежат «всё подряд».

Технические тонкости: SNI, ESNI и ECH

Фильтрация по SNI работает потому, что в стандартном TLS 1.2 и базовом TLS 1.3 имя домена уходит в первом пакете в открытом виде — и оператор может его прочитать. Но в IETF давно обсуждаются механизмы, шифрующие SNI:

  • ESNI (deprecated) — ранний черновик, шифровал только SNI.
  • ECH (Encrypted Client Hello) — современный стандарт, шифрует весь Client Hello. Cloudflare включает ECH с 2023 года, Mozilla активирует его в Firefox при поддержке резолвера.

Для whitelist-фильтрации это означает: фильтр на L7 теряет возможность видеть имя домена. В ответ операторы по всему миру (не только в РФ) используют разные стратегии: либо блокируют сам факт ECH, либо опускаются на L3 и фильтруют по IP, либо включают режим «по умолчанию режем всё, кроме известных IP-диапазонов в whitelist». Так whitelist становится строже.

Как это реализовано у мобильных операторов

В сотовой сети LTE/5G трафик абонента всегда выходит через PGW (Packet Gateway) или UPF (User Plane Function в 5G). Это место — естественная точка для DPI и фильтрации. Конкретные системы — это российский ТСПУ (технические средства противодействия угрозам), плюс встроенные продукты вендоров оборудования (Huawei, NSN, Ericsson, отечественные NFV-решения).

Алгоритм проверки одного TLS-соединения упрощённо такой:

  1. Абонент инициирует TCP/443 на IP X.
  2. PGW смотрит: IP X входит ли в разрешённый диапазон (whitelist по подсетям)?
  3. Если да — соединение продолжает идти, но PGW параллельно ждёт TLS Client Hello.
  4. В Client Hello читается SNI. Если домен в whitelist — пропускаем дальше. Если нет — отправляется TCP RST или просто выкидывается пакет.
  5. Для HTTP/3 (QUIC) проверка аналогична, но смотрят первый Initial-пакет с QUIC Crypto Frame, где также прокачивается SNI.

На практике у разных операторов настройки немного отличаются: где-то строже, где-то мягче, где-то отдельно обрабатывается DNS over HTTPS (DoH) и DNS over TLS (DoT). Подробнее о VLESS+Reality, который выглядит для DPI как «обычный TLS к разрешённому домену», — в нашем материале «VPN-протоколы: VLESS, Hysteria, Shadowsocks».

История фильтрации в Рунете

Чтобы лучше понять контекст 2026 года, кратко по этапам:

  • 2012. Введён Единый реестр запрещённой информации. Это типичный blacklist: операторы блокируют конкретный список доменов и URL. Whitelist на тот момент не обсуждается.
  • 2017–2018. Попытки массовой блокировки одного из мессенджеров и связанные с этим проблемы для случайных IP-диапазонов CDN. Стало очевидно, что L3-blacklist в эпоху облаков работает плохо.
  • 2019. Закон о «суверенном интернете», ТСПУ становится обязательным элементом инфраструктуры операторов.
  • 2022–2023. Усиление DPI на L7 с фокусом на SNI inspection.
  • 2024. Точечные whitelist-режимы у мобильных операторов в отдельных регионах в моменты повышенной нагрузки и инцидентов.
  • 2025–2026. Whitelist-режим обсуждается и применяется как стандартный инструмент обеспечения работы критической инфраструктуры в условиях нестабильного внешнего трафика.

Сколько процентов сайтов это покрывает

По разным оценкам и публикациям на профильных ресурсах, в whitelist в среднем попадает несколько сотен крупных доменов и около 0,1–0,3% от всего числа доменов рунета. С точки зрения трафика это, однако, заметная доля: на государственные сервисы, банки, Яндекс-экосистему, VK и крупные торговые площадки приходится огромное число пользовательских сессий в день.

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

Влияние на пользователей

В режиме whitelist обычная активность — банкинг, доставка, такси, ВКонтакте, Госуслуги — работает как обычно. Заметные изменения касаются:

  • Сторонних мессенджеров и почтовых сервисов вне whitelist.
  • Глобальных стриминговых платформ.
  • Сторонних DNS (1.1.1.1, 8.8.8.8) — не всегда дотягиваются.
  • Сервисов с непрямой инфраструктурой. Какой-нибудь сторонний сайт может «лежать» не потому, что он сам в чёрном списке, а потому что его CDN не входит в whitelist.

Для понимания, насколько в принципе VPN полезен с точки зрения сетевой безопасности и приватности, см. «Что такое VPN простыми словами» и «Как VPN защищает персональные данные».

Whitelist в корпоративном контексте

Чтобы лучше понимать, что такое whitelist «вообще», полезно посмотреть на корпоративные сети. Например, в банковском контуре:

  • Inbound — закрыто всё, кроме явно разрешённых IP филиалов и партнёров.
  • Outbound — закрыто всё, кроме списка доменов поставщиков услуг.
  • На уровне DNS — резолвятся только корпоративные имена и явно разрешённые внешние.
  • На уровне TLS-инспекции — выборочный mitm-перехват для проверки исходящего трафика.

Точно те же принципы лежат в основе любого whitelist на уровне ISP — меняется только масштаб и содержание самого списка.

Whitelist и DNS over HTTPS

Отдельный технический сюжет — DoH/DoT. Когда DNS-запросы идут не через провайдерский DNS, а напрямую к стороннему резолверу по HTTPS, оператор не видит, какие домены резолвит абонент. Это снижает точность L7-фильтра на этапе DNS, но не отменяет SNI-фильтрацию: имя домена всё равно появляется в TLS Client Hello.

В whitelist-режиме операторы часто включают дополнительные правила:

  • Блокировка трафика к известным DoH-резолверам (cloudflare-dns.com, dns.google, dns.quad9.net) — если адрес домена не в whitelist.
  • Принудительный редирект DNS-запросов на оператора (DNS hijacking на UDP/53).
  • Проверка ALPN на TLS — если ALPN указывает на h3 (HTTP/3) к адресу не из whitelist, соединение разрывается.

Whitelist и QUIC/HTTP-3

HTTP/3 на UDP усложняет фильтрацию, но не делает её невозможной. Большинство операторов сегодня делают одно из:

  • Полностью режут UDP/443 при whitelist-режиме. Тогда HTTP/3 деградирует до HTTP/2 на TCP.
  • Фильтруют QUIC по SNI в первом Initial-пакете.
  • Допускают QUIC только к разрешённым IP-диапазонам.

Поэтому современные клиенты адаптивно умеют возвращаться с QUIC на TCP при необходимости — это видно и в браузерах, и в нашем клиенте Hiddify, и в HAPP.

Whitelist у разных операторов в РФ

Реализация немного разнится:

  • МТС — традиционно строгая фильтрация SNI на уровне PGW. Активно блокирует QUIC/UDP вне whitelist.
  • Билайн — больше работает по IP-диапазонам, меньше по SNI. Что в моменте может быть строже или мягче в зависимости от конкретной локации.
  • Мегафон — комбинированная схема, активная блокировка сторонних DoH-резолверов.
  • Yota — следует за Мегафон, но иногда мягче в части IPv6.
  • Tele2 — есть особенности по обработке роуминговых SIM и по реакции на нестандартные ALPN.

Важно: эти наблюдения меняются от месяца к месяцу. Whitelist — это не статика, это динамическая система, и её содержание адаптируется.

Whitelist и мобильное vs фиксированное соединение

На фиксированном домашнем интернете (Ростелеком, Дом.ру, ЭР-Телеком, региональные ISP) в большинстве случаев whitelist не вводится: фильтрация идёт по blacklist (Реестр запрещённой информации) и по более мягким правилам ТСПУ. На мобильных операторах в моменты крупных инцидентов whitelist может временно ужесточаться. В разных регионах ситуация бывает разной.

Whitelist и IoT, корпоративные SIM

Отдельный класс трафика — M2M/IoT SIM-карты, банкоматные SIM, корпоративные платежные терминалы. Они у операторов часто работают именно в whitelist-режиме давно: терминал должен соединяться только с банковским процессингом, и больше никуда. Это самый яркий пример «правильного» whitelist в проде. И это технология, которая в РФ существует много лет и никем не оспаривается.

QQ NET в условиях нестабильного мобильного интернета

QQ NET ориентирован на стабильное и быстрое соединение в любых условиях, в том числе в мобильных сетях, где параметры связи колеблются. Для этого у нас есть специальные узлы LTE-1 и LTE-2 — расположенные в инфраструктуре, рассчитанной именно на нестабильные мобильные подключения. Эти узлы работают на современных протоколах:

  • VLESS + XHTTP — транспортный уровень, который ведёт себя как обычный HTTPS-трафик.
  • Reality — слой, при котором TLS-handshake виглядит идентично соединению с обычным крупным сайтом, без характерных «отпечатков» VPN-протоколов.
  • Адаптивная маршрутизация — клиент сам выбирает наиболее быстрый узел и протокол с учётом текущего состояния канала.
  • Низкий ping и стабильный jitter в мобильных сетях за счёт архитектуры.

Подробно про используемые протоколы — в материале «VPN-протоколы: VLESS, Hysteria, Shadowsocks». Если хотите попробовать сервис — есть 3 дня бесплатного доступа за подписку на канал @qq0net. Подробности — на странице тарифов и в материале «Пробный период VPN: как протестировать».

Связанные материалы

Итог

Белый список — это давно известная технология сетевой безопасности: «по умолчанию запрещено всё, разрешено только перечисленное». В Рунете 2026 года этот механизм встроен в ТСПУ и применяется на уровне мобильных операторов и в корпоративных сетях. Технически он работает на нескольких уровнях — от IP-подсетей до SNI inspection и QUIC Initial-фильтрации. С точки зрения обычного пользователя в whitelist попадает большая часть привычной российской цифровой инфраструктуры: государственные сервисы, банки, Яндекс, VK, крупные ритейлеры. Понимание того, как это устроено, помогает разобраться в реальной картине Рунета и осознанно выбирать инструменты для стабильного интернета — например, узлы QQ NET LTE-1 и LTE-2, спроектированные для устойчивой работы в мобильных сетях.