Белые списки: архитектура разрешительного доступа

Две модели: default-allow и default-deny

Политика default-allow разрешает любой трафик, кроме перечисленного в чёрном списке. Она удобна для сети общего назначения: пользователь не замечает фильтра, пока не обратится к конкретному адресу из перечня. Слабость модели в том, что перечень всегда отстаёт — новый адрес работает до момента, пока его не добавят.

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

Выбор между ними — это выбор между двумя типами ошибок. Первая модель иногда пропускает нежелательное, вторая иногда не пропускает нужное. В корпоративной практике встречается гибрид: default-deny для серверного сегмента и default-allow с чёрным списком для пользовательского.

Как ведётся перечень разрешённых адресов

Технически запись может быть трёх видов. IP-адрес или подсеть — самая простая форма, но она ломается, как только сервис меняет инфраструктуру: облачные платформы переназначают адреса динамически. Доменное имя надёжнее по смыслу, но требует, чтобы устройство разбирало DNS или поле SNI. Полный URL применим только к незашифрованному трафику или к прокси, который завершает TLS на себе.

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

Отдельная сложность — сервисы с блуждающими адресами. Записи вида *.googleapis.com покрывают сотни разных функций, включая те, которые администратор открывать не собирался. Сузить такую запись до нужной части часто невозможно без прокси с разбором на уровне запроса.

Что происходит со сторонними зависимостями страницы

Современная веб-страница почти никогда не загружается с одного домена. Типовой корпоративный портал обращается к 8–20 внешним источникам: шрифты, библиотеки JavaScript, счётчики аналитики, виджеты поддержки, карты, скрипты платёжного провайдера, системы защиты от автоматических запросов.

При разрешительной модели в список попадает основной домен, а зависимости — нет. Результат: страница открывается, но шрифты подменяются системными, интерактивные элементы не работают, кнопка оплаты не появляется, а капча висит бесконечным спиннером. Пользователь видит наполовину сломанный сайт и не понимает причины, потому что формально доступ есть.

Диагностика делается вкладкой «Сеть» в инструментах разработчика: запросы к неразрешённым доменам показывают статус (failed) или таймаут. Именно из этого списка обычно и формируется заявка на расширение перечня.

Можно ли обойти белый список и когда это осмысленно

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

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

Отдельно стоит сказать про учебные и гостевые сети. Там разрешительная модель обычно настроена грубо: список не пересматривался год, половина записей устарела, а пользователь не может открыть даже документацию по работе. Это плохо спроектированная сеть, а не защита, и правильный путь — заявка администратору, а не борьба с оборудованием.

Captive-порталы

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

Операционные системы обнаруживают такое состояние сами: Android обращается к connectivitycheck.gstatic.com, Windows — к msftconnecttest.com, устройства Apple — к captive.apple.com. Если вместо ожидаемого короткого ответа приходит перенаправление, система показывает уведомление «Требуется вход в сеть».

Типичный сбой связан с шифрованием DNS. Если на устройстве принудительно включён DoH, запрос уходит на внешний резолвер, портал не может подставить своё перенаправление, и авторизация не запускается — сеть выглядит подключённой, но без доступа. Ровно так же мешает и уже поднятый туннель: порталу нужно увидеть исходный HTTP-запрос.

Корпоративные и учебные сети как повседневный пример

В организациях разрешительная модель обычно применяется к серверному сегменту и к сети производственного оборудования. Промышленный контроллер должен общаться с четырьмя известными адресами и больше ни с кем — тут default-deny естественна и не создаёт неудобств.

В учебных заведениях список чаще строится вокруг образовательных ресурсов: библиотеки, платформы курсов, электронный журнал, почта учреждения. Побочный эффект — блокировка репозиториев кода, пакетных менеджеров и документации, из-за чего практические занятия по программированию упираются в невозможность выполнить pip install или npm i.

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