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

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

В российском контексте разговор о белых списках чаще всего связан с ТСПУ, DPI и режимом «разрешено только известное». Техническая база проста: операторская сеть сверяет трафик с наборами правил. На нижнем уровне проверяют IP-адрес и подсеть, выше смотрят порт и протокол, а для HTTPS могут читать имя сервера в TLS ClientHello через SNI. 

Белый список не равен блокировке по одному домену

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

На практике оператор может держать несколько списков сразу. Один список хранит разрешённые IP-адреса или CIDR-подсети. Второй описывает разрешённые порты, например TCP 80 и TCP 443. Третий учитывает прикладные признаки, включая SNI для HTTPS. Четвёртый может касаться DNS, когда внешние резолверы не отвечают, а доступен только DNS самого провайдера.

Пакет пользователя
   |
   | проверка IP или подсети
   | нет в списке -> DROP
   |
   | проверка протокола и порта
   | порт не разрешён -> DROP или TIMEOUT
   |
   | проверка SNI или Host
   | правило сработало -> RST или отказ
   |
   | трафик проходит к сервису

Разница между DROP и RST хорошо видна при диагностике. DROP выглядит как тишина: клиент ждёт ответ и получает тайм-аут. RST выглядит как активный разрыв TCP-соединения. Для пользователя оба сценария часто сводятся к одной фразе «сайт не открывается», но для инженера разница показывает, где примерно сработало правило.

Что происходит на уровнях IP, портов, DNS и SNI

На уровне L3 фильтр смотрит на адрес назначения. Если IP-адрес или подсеть не входит в разрешённый набор, пакет могут отбросить ещё до глубокого анализа. Такой режим дешевле для сети, потому что маршрутизатору или пограничному устройству не нужно разбирать TLS, HTTP и поведение приложения. Минус очевиден: один IP может обслуживать десятки сайтов, API, CDN-узлов и служебных доменов.

На уровне портов правила уточняют, какие типы соединений допустимы. Например, TCP 443 может проходить, а UDP 443 для HTTP/3 или QUIC может не отвечать. Фильтр не обязан одинаково относиться ко всем протоколам на разрешённом IP. Из-за этого один и тот же сайт способен частично открываться в браузере, но ломать видео, пуш-уведомления, авторизацию или мобильное приложение.

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

nslookup example.com
 curl -I https://example.com
 tracert example.com

SNI работает выше, на уровне TLS. Когда браузер подключается к HTTPS-сайту, клиент в начале рукопожатия сообщает имя сервера, чтобы сервер выбрал правильный сертификат для нужного виртуального хоста. Такая логика описана в RFC 6066. До применения ECH имя в SNI видно сетевому наблюдателю, поэтому DPI может принять решение до передачи HTTP-запроса.

TLS 1.3 шифрует большую часть рукопожатия, но обычный SNI остаётся видимым без Encrypted Client Hello. ECH закрывает часть метаданных, но требует поддержки со стороны клиента, сервера и DNS-записей. При фильтрации по IP ECH не решает базовую проблему: если адрес назначения не входит в белый список, соединение не дойдёт до стадии, где шифрование имени сервера вообще поможет.

Где белые списки дают пользу и где ломают сеть

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

На публичном интернете белые списки быстро превращаются в источник побочных поломок. Современный сервис редко живёт на одном домене и одном сервере. Банковское приложение может использовать CDN, антифрод, пуш-уведомления, капчу, облачную аналитику, API партнёров и отдельные домены для картинок. Если администратор добавит в список только главный домен, интерфейс откроется, а авторизация или платёж упадут на скрытом запросе.

Самая частая инженерная ошибка связана с недооценкой зависимостей. В белый список добавляют витринный домен, но забывают домены обновлений, авторизации, телеметрии, хранилища файлов, почтовой отправки и мобильных API. Вторая ошибка: считать белый список статичным. Облачный провайдер меняет IP, CDN переносит узел, сервис добавляет новый домен, а правила продолжают жить вчерашней картиной сети.

Как проверять корректность без опасных сценариев

Администратор должен проверять белые списки на собственных ресурсах и в согласованном контуре. Базовая проверка не требует агрессивного сканирования. Достаточно посмотреть DNS-ответ, TCP-доступность, TLS-сертификат, HTTP-код и маршрут. Если проверка идёт из нескольких операторов или регионов, результаты нужно хранить с датой, временем, сетью и типом подключения, потому что правила могут отличаться даже внутри одной страны.

nslookup site.example
 curl -vI https://site.example
 openssl s_client -connect site.example:443 -servername site.example
 tracert site.example

Нормальная карта зависимостей для сервиса должна включать не только основной сайт. Проверьте домены входа, API, CDN, статические файлы, платёжный шлюз, почтовые уведомления, капчу, мониторинг и обновления приложения. Для каждой зависимости нужны владелец, назначение, домены, порты, критичность и способ деградации. Если сервис без аналитики работает, а без авторизации нет, такие зависимости нельзя ставить в один класс риска.

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

Второй миф: достаточно фильтровать по домену. Для HTTPS одного домена мало, потому что решение часто принимают до HTTP-запроса, а IP-адрес может обслуживать много имён. SNI помогает различать виртуальные хосты, но не описывает всю бизнес-логику приложения. DNS тоже не даёт полной картины, потому что один домен может возвращать разные адреса для разных регионов, провайдеров и времени суток.

Третий миф: список можно составить один раз. Реальная инфраструктура меняется ежедневно. Команда добавляет новый API, подрядчик переносит файлы в другое хранилище, мобильное приложение меняет адрес проверки версии, CDN переставляет трафик на другой узел. Белый список без мониторинга превращается в технический долг, который всплывает как «странная» авария у части пользователей.

Что делать владельцу сервиса

Владельцу сервиса нужен не список доменов «на глаз», а инвентаризация сетевых зависимостей. Начать стоит с журналов веб-сервера, настроек мобильного приложения, карты CDN, записей DNS, внешних API и систем авторизации. Затем нужно прогнать легальные проверки из тех сетей, где сервис должен работать, и зафиксировать, какой компонент ломается первым: резолвинг имени, TCP-соединение, TLS-рукопожатие, HTTP-запрос или прикладной ответ.

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

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