Captive portal: один Wi-Fi, несколько уровней доступа

September 19, 2026

Цикл «Не светим лишнего». Выпуск 8.

Captive portal большинство видело в гостинице: подключились к Wi‑Fi, открылась страница, приняли правила или ввели номер комнаты — появился Интернет.

Для корпоративной сети интереснее другой сценарий. До авторизации клиенту доступны только DHCP, DNS и портал. После входа он получает не просто «Интернет есть», а конкретную роль firewall.

Один SSID, разные права

Например, на объекте есть технологический Wi‑Fi.

Гостевой ваучер даёт только Интернет.
Сотрудник получает внутренний портал и телефонию.
Инженер видит мониторинг и сетевое оборудование.
Подрядчик по камерам — только CCTV-сегмент на четыре часа.
Аварийный профиль открывает расширенный доступ и сразу пишет событие в журнал.

Пользовательский интерфейс один, а политика выбирается по учётной записи, ваучеру, группе RADIUS или дополнительному коду.

Captive portal — это веб-страница, через которую сеть проводит пользователя до выдачи обычного доступа. На MikroTik такую модель реализует HotSpot. RADIUS может хранить пользователей, срок сессии и дополнительные атрибуты политики.

Как проходит трафик

Неавторизованный клиент получает адрес, но firewall разрешает ему только минимальный набор. Попытка открыть сайт приводит к captive portal detection или редиректу на страницу входа. После успешной авторизации устройство появляется среди активных клиентов, а правила начинают пропускать нужные направления.

Важно: современный HTTPS нельзя безопасно «подменить» редиректом на чужой сертификат. Поэтому нормальный портал полагается на специальные проверки captive portal в ОС, доступ к своему hostname и аккуратный walled garden — список адресов, доступных до входа.

Плюсы

пользователю не нужно ставить приложение;
удобно выдавать временные ваучеры;
можно различать группы доступа;
сессия и timeout управляются централизованно;
хорошо работает в контролируемой локальной сети;
RADIUS даёт единый учёт и accounting.

Минусы

механизм привязан к конкретному сегменту и шлюзу;
не все устройства красиво открывают портал;
HTTPS и приложения без браузера могут выглядеть как «Интернет не работает»;
MAC-адреса на телефонах рандомизируются;
общая учётка плохо различает людей;
открытый Wi‑Fi до портала сам по себе не шифрует радиообмен.

Где можно больно ошибиться

Считать MAC надёжной личностью. MAC-cookie удобна для повторного входа, но адрес можно подменить, а ОС может использовать private MAC. Для чувствительной роли нужна пользовательская авторизация.

Не включить client isolation. Два гостя в одном Wi‑Fi не должны свободно ходить друг к другу на SMB и RDP.

Открыть слишком широкий walled garden. До авторизации разрешают CDN или домен, который умеет проксировать произвольный трафик, и портал превращается в декорацию.

Использовать один инженерный ваучер месяцами. Ваучер должен иметь срок, число одновременных сессий и понятного владельца.

Смешать гостевой и технологический трафик без сегментации. Роль firewall не отменяет VLAN, отдельные подсети и базовую изоляцию.

Не продумать отказ RADIUS. Надо заранее выбрать fail closed или ограниченный аварийный профиль. Выдавать всем полный доступ при недоступности сервера — плохой fallback.

Дополнительная авторизация внутри Wi‑Fi

Интересный вариант: базовый доступ у сотрудника уже есть, но для входа в технологическую группу он открывает отдельную страницу и подтверждает действие TOTP. Firewall на короткое время добавляет его текущий адрес в расширенный список. Это уже мостик к нашему отдельному TOTP-порталу, который сможет работать не только в Wi‑Fi, но и из Интернета.

Ранее в цикле

Документация и источники

#network