HotSpot Portal: платформа гостевого Wi‑Fi под брендом оператора

У оператора связи уже есть каналы, сетевое оборудование, техническая поддержка и клиенты из общепита, медицины, торговли, фитнеса и других сфер услуг. Но чаще всего Wi‑Fi для такого клиента заканчивается на установке роутера. Мне стало интересно превратить его в полноценную управляемую услугу, которую оператор или системный интегратор может развернуть в своей инфраструктуре, оформить под собственным брендом и продавать бизнесу за ежемесячную плату.

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

Задача не сводится к красивой странице входа. Статья 44 Федерального закона № 126-ФЗ «О связи» относит порядок идентификации пользователей услуг передачи данных и их оборудования к правилам оказания услуг связи. В действующих Правилах оказания услуг связи по передаче данных, утверждённых постановлением Правительства РФ № 2606, для пунктов коллективного доступа предусмотрена идентификация пользователя и используемого им оконечного оборудования. Одним из практических способов такой проверки является достоверное установление номера мобильного телефона.

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

Журнал авторизации не означает запись всей интернет‑жизни пользователя. HotSpot Portal не сохраняет содержимое переписки и не ведёт архив посещённых страниц. Он хранит технический след: время входа, способ подтверждения, сетевую сессию, IP‑ и MAC‑адреса, точку доступа и RADIUS accounting. DNS‑история вынесена в отдельный диагностический инструмент и не подменяет журнал авторизаций.

Номер телефона, идентификаторы мессенджеров и история сессий образуют ещё один контур требований — обработку персональных данных по № 152-ФЗ. Если клиент оператора собирается отправлять рекламу, согласие на неё должно быть отдельным и доказуемым: это уже статья 18 № 38-ФЗ «О рекламе».

Так появился HotSpot Portal — локально разворачиваемая платформа управляемого гостевого Wi‑Fi под брендом оператора. Гость подтверждает вход телефонным звонком, через MAX или VK. Точки MikroTik и OpenWrt получают временную авторизацию через RADIUS. Бизнес‑клиент работает со своими посетителями и рекламными кампаниями, а оператор видит инфраструктуру, сессии и техническую статистику в единой панели.

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

Что должна уметь операторская платформа

Требования разделились на три уровня.

Для гостя всё должно быть максимально коротко:

1. подключиться к сети;

2. увидеть понятную страницу;

3. выбрать удобный способ подтверждения;

4. получить интернет;

5. попасть на сайт организации.

Бизнес‑клиенту оператора нужны:

• отдельное оформление портала со своим логотипом и цветами;

• база Wi‑Fi‑клиентов с историей визитов и выбранными каналами связи;

• аналитика по подключениям и повторным посещениям;

• рекламные рассылки только по аудитории с отдельным согласием;

• роли сотрудников и скрытие персональных данных.

У оператора или интегратора список длиннее:

• несколько способов авторизации без ручной выдачи паролей;

• ограниченные по времени учётные данные;

• проверенная поддержка MikroTik и OpenWrt/CoovaChilli;

• несколько клиентских организаций и объектов в одной установке;

• отдельные настройки и точки доступа для каждого профиля;

• состояние точек доступа и активных сессий;

• RADIUS accounting и техническая история DNS;

• централизованное управление пользователями и ролями;

• лицензирование по числу подключённых точек доступа;

• обновление программы без потери конфигурации;

• установка в собственной инфраструктуре, без обязательного внешнего облака;

• сборка и установка на серверы amd64 и arm64.

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

Как выглядит вход для гостя

После подключения устройство пытается проверить наличие интернета. Точка доступа перехватывает этот запрос и направляет гостя на captive portal — страницу, которая автоматически появляется в общественных Wi‑Fi‑сетях.

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

При входе по телефону гость указывает номер и отдельно отмечает необходимые согласия. Портал ставит фоновую задачу на звонок. FreePBX/Asterisk создаёт вызов через VoIP GSM‑шлюз Dinstar, а небольшой ARI‑сервис озвучивает одноразовый код. Гость вводит код на странице.

Формы телефона, MAX и VK собраны на одном визуальном каркасе: одинаковые заголовок канала, блок согласий, основное действие и возврат к выбору способа. Различается только то, что действительно требуется выбранному каналу.

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

После перехода в мессенджер бот показывает запрос на подтверждение. Когда гость нажимает кнопку, портал получает результат, открывает доступ и отправляет ссылку на сайт организации. Ни пароль от Wi‑Fi, ни одноразовый код пользователю передавать не приходится.

Когда подтверждение получено, система создаёт временный RADIUS‑ваучер. Для MikroTik она также может выполнить вход устройства по MAC‑адресу на стороне точки доступа. После этого гость получает интернет и перенаправляется на сайт организации.

В упрощённом виде путь выглядит так:

телефон гостя

↓

точка доступа → captive portal → звонок или бот

↑ ↓

└──── RADIUS Access‑Accept ← подтверждение

За этой короткой цепочкой скрывается довольно много состояния: профиль организации, IP и MAC устройства, исходный адрес перехода, срок действия кода, выбранный способ входа, согласия и результат сетевой авторизации. Все эти данные нужно связать с одной попыткой, но не позволить повторно использовать просроченный токен.

Из чего состоит система

Главный сервер работает в инфраструктуре оператора или интегратора. На нём находятся веб‑интерфейс, Go‑приложение, база, очередь задач и сетевые службы. Точки доступа на клиентских объектах соединяются с платформой через WireGuard, поэтому RADIUS и служебные интерфейсы не приходится открывать в интернет.

Основные компоненты такие:

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

Один из вариантов установки на объекте

Платформа не привязана к конкретной модели сервера или точки доступа. В одной из действующих установок используются потолочные MikroTik cAP, а управляющий узел развёрнут на Raspberry Pi 4. Этот вариант хорошо показывает, что для одного небольшого объекта не требуется тяжёлая инфраструктура: питание точек подаётся по Ethernet, а сервисы работают на компактном ARM‑компьютере.

Для оператора Raspberry Pi не является целевой центральной платформой. При массовом подключении объектов те же пакеты следует устанавливать на серверы или виртуальные машины с резервным копированием и мониторингом. Поддержка arm64 остаётся полезной для небольших автономных узлов и пилотных внедрений.

Что видят оператор и его клиент

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

Гостевой портал и административный вход разделены. На странице авторизации осталась только форма без описания возможностей системы: сотруднику нужно быстро войти в рабочую панель, а не читать повторную презентацию продукта.

Сессии

В списке видно, когда был выдан доступ, когда он истекает, каким способом пользователь подтвердил вход и к какому ваучеру относится запись. Телефоны, идентификаторы мессенджеров и MAC‑адреса скрываются в зависимости от роли сотрудника.

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

Аналитика

На дашборде собраны текущие подключения, уникальные и повторные посетители, средняя продолжительность сессии и динамика по времени. Есть разрез по точкам доступа и выгрузка CSV.

На основе авторизаций сервис ведёт базу клиентов Wi‑Fi: хранит выбранный способ входа, первую и последнюю дату визита, повторные подключения и привязку к объекту. Телефон и идентификаторы мессенджеров относятся к персональным данным, поэтому доступ к ним зависит от роли сотрудника, а в обычных списках они маскируются.

Согласие на технически необходимую обработку и согласие на рекламные сообщения учитываются отдельно. Это не только вопрос интерфейса: рассылка не должна использовать всех, кто когда‑либо подключался к Wi‑Fi. Администратор может сформировать аудиторию из согласившихся клиентов и отправить рекламу организации через подключённые каналы MAX и VK. Таким образом, гостевой Wi‑Fi становится не только способом выдать интернет, но и аккуратным каналом возврата постоянных гостей — при условии прозрачного согласия и возможности отказаться от сообщений.

Рассылка поддерживает не только текст, но и изображение с кнопкой перехода на сайт организации. Ниже — тестовое рекламное сообщение, отправленное через MAX.

DNS‑история

CoreDNS пишет структурированный журнал запросов, а worker читает его с сохранением позиции. Запись связывается с IP клиента и, когда это возможно, с гостевой сессией. В интерфейсе можно фильтровать домены, адрес клиента, тип запроса и период.

Здесь важно не приписывать системе лишнего. Она не читает содержимое HTTPS‑страниц, поисковые запросы или переписку. DNS обычно показывает только домен, причём современные приложения могут использовать DNS over HTTPS и обходить локальный резолвер. Это инструмент диагностики и ограниченной сетевой аналитики, а не «просмотр всего интернета пользователя».

Состояние точки доступа

Для MikroTik портал получает загрузку процессора, памяти и накопителя, число активных сессий и состояние зеркалирования трафика. С этой же страницы можно синхронизировать параметры и применить конфигурацию FreeRADIUS.

Слово NAS здесь означает Network Access Server — сетевое устройство, которое принимает подключение гостя и обращается к RADIUS. К сетевому хранилищу этот раздел отношения не имеет.

WireGuard

Точки можно связать с сервером защищёнными туннелями. В панели видны интерфейсы, состояние и количество пиров; приватные ключи через API не выдаются.

WireGuard не делает небезопасную службу безопасной сам по себе, но уменьшает наружную поверхность: RADIUS, управление точками и служебный обмен остаются во внутреннем контуре.

Зачем такая платформа оператору

Оператор уже продаёт бизнесу канал связи, аренду оборудования, статический IP и техническое обслуживание. Управляемый гостевой Wi‑Fi становится ещё одной регулярной услугой, а не разовой настройкой роутера. Платформа устанавливается в инфраструктуре оператора и оформляется под его бренд: собственные название, логотип, домен и контакты поддержки видят и бизнес‑клиенты, и их гости.

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

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

Почему я выбрал Go

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

Сейчас из одного исходного дерева собираются четыре исполняемых файла:

hotspot‑api

hotspot‑worker

hotspot‑scheduler

hotspot‑tzsp

В этом проекте особенно пригодились следующие возможности Go:

• отдельный бинарный файл для каждого процесса и предсказуемая поставка зависимостей;

• простая сборка под amd64 и arm64;

• мощная стандартная библиотека для HTTP и сетевого кода;

• удобная конкурентность для API, фоновых задач и сетевых обработчиков;

• типы помогают удерживать контракты между API, очередью и хранилищем;

• тесты чистой логики запускаются без всей инфраструктуры.

Как это устанавливается

Production‑вариант работает как набор systemd‑служб. Для него собирается Debian‑пакет hotspot-portal-go.

В пакет входят:

• четыре Go‑сервиса;

• собранный React‑интерфейс;

• unit‑файлы systemd;

• миграции и служебные шаблоны;

• проверенная во время CI сборка CoreDNS;

• конфигурация интеграции с FreeRADIUS.

Сам FreeRADIUS берётся из репозитория дистрибутива как зависимость пакета. Копировать в свой .deb ещё один бинарник RADIUS было бы плохой идеей: тогда обновления безопасности дистрибутива перестали бы применяться ожидаемым образом.

CoreDNS, напротив, кладётся в пакет заранее. Установка не должна внезапно скачивать исполняемый файл с GitHub: это мешает повторяемости и ломается именно тогда, когда сервер разворачивают в изолированной сети.

GitLab CI сначала прогоняет тесты и собирает builder‑образы с нужными версиями инструментов. Эти образы хранятся в приватном Harbor. Release‑тег запускает сборку пакетов для amd64 и arm64, после чего артефакты попадают во внутренний репозиторий пакетов.

Docker Compose тоже оставлен как отдельный вариант для разработки и изолированных установок. Но в production выбран один источник истины: пакет и systemd. Смешивать контейнерный CoreDNS, системный FreeRADIUS и worker, который перезапускает то одно, то другое, оказалось слишком трудно диагностировать.

Что получилось в итоге

HotSpot Portal охватывает весь путь от подключения гостя до диагностики сетевой инфраструктуры:

подключение → подтверждение → сетевой доступ → учёт сессии → диагностика

Гостю не нужно знать о RADIUS, ARI, ваучерах и туннелях. Он видит бренд конкретной организации, выбирает звонок или мессенджер и получает интернет.

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

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

В таком виде проект можно развивать как тиражируемую платформу для операторов связи и системных интеграторов. Они разворачивают её у себя, подключают точки своих клиентов и продают управляемый гостевой Wi‑Fi как регулярную услугу под собственным брендом.

В следующей статье хочу разобрать проект глубже: как проходит авторизация от первого HTTP‑запроса до Access-Accept, как связаны FreePBX, GSM‑шлюз и ARI, что именно делает RADIUS accounting и почему DNS‑история однажды оказалась пустой, хотя сайты у гостя открывались.