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

[ZigFisher]

Спасибо за статью, однако в текущих реалиях интереснее было-бы рассмотреть вариант связи между точками доступа и сервером без VPN, тем более WG.
А так-же нераскрыт вопрос, как будете подтверждать авторизацию через VK/MAX в случае прихода запроса из компетентных органов на конктный выход в инет. В случае с телефонным звонком в любую сторону или SMS всё прекрасно, есть биллинг и сотовый оператор, а вот при авторизации через мессенджеры эпизодически могутвозникать некоторые доказательные коллизии, которые могут попить крови у того, кого вызовут "на ковёр" в случае разбирательств. А дела громкие бывают, мошенники часто используют публичные хотспоты, когда денежку выводят, и у компетентных органов часто первый вопрос, а не в сговоре-ли владелец хотспота или системы в общем с мутными личностями ;)

[nikitajava]

Спасибо, замечания по существу.

WireGuard в показанной установке — не обязательная часть протокола, а выбранный способ создать закрытый контур и не публиковать наружу RouterOS API, CoA и обычный RADIUS/UDP. Вариант без VPN вполне возможен: RADIUS можно передавать через RadSec с взаимной проверкой сертификатов, а управляющие операции — через HTTPS/mTLS. MikroTik поддерживает RadSec штатно. Для точек за NAT серверные команды при этом лучше выполнять через локальный агент, устанавливающий исходящее защищённое соединение с платформой. Такой вариант планирую отдельно разобрать в технической статье.

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

Правильная схема — при первой привязке дополнительно получать подтверждённый номер телефона либо предварительно проверять его звонком/SMS. Например, MAX предоставляет кнопку request_contact и подписывает данные HMAC — можно проверить, что пользователь передал именно номер, привязанный к его аккаунту. Для VK аналогичную привязку можно реализовать через Mini App с получением номера и проверяемой подписью.

Кроме того, для ответа на запрос недостаточно одной записи «пользователь подтвердил вход». Нужно связать в единый журнал время и часовой пояс, способ проверки, номер телефона, ID мессенджера, MAC, внутренний IP, точку доступа, RADIUS Acct-Session-Id, внешний IP и, при NAT, трансляцию исходного порта. Последнего полноценного контура в текущей версии ещё нет, и это действительно важное направление развития.

Так что замечание принимаю: авторизацию через мессенджеры корректнее пока называть удобным дополнительным каналом, а не безусловной заменой идентификации по телефонному номеру. Спасибо, добавлю это ограничение в материал.

[nikitajava]

В продолжение темы идентификации: наиболее надёжным дополнительным способом здесь могла бы стать авторизация через Госуслуги — ЕСИА.

Такой вариант прямо предусмотрен пунктом 28 Правил оказания услуг связи по передаче данных. В отличие от обычного идентификатора пользователя MAX или VK, ЕСИА позволяет подтвердить личность владельца учётной записи.

Технически сценарий будет выглядеть так: гость выбирает «Через Госуслуги», проходит авторизацию в ЕСИА, после чего портал проверяет подписанный ответ и принимает только подтверждённую учётную запись. В журнале нужно связать идентификатор ЕСИА, ФИО и время аутентификации с MAC-адресом, внутренним IP, точкой доступа, RADIUS-сессией и данными NAT.

Это не просто добавление ещё одной OAuth-кнопки. Для промышленной эксплуатации оператору потребуется зарегистрировать свою информационную систему в ЕСИА, получить мнемонику, зарегистрировать сертификат и пройти тестовое подключение. В локально разворачиваемой версии платформы эти реквизиты должны принадлежать самому оператору, а не разработчику HotSpot Portal.

Добавлю ЕСИА в план развития проекта. После такой интеграции телефон и Госуслуги можно будет использовать как основные способы идентификации, а MAX/VK — как дополнительные удобные каналы либо привязывать их к уже подтверждённой личности. Спасибо за комментарий — он подсветил важную границу между удобной авторизацией и доказуемой идентификацией.

[ZigFisher]

Спасибо за ниформацию.

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

По авторизации через мессенджеры я задавал вопрос не просто так, а с учетом некоторого опыта. В случае звонков или SMS (они не рентабельны и тупят) следователю из органов, который будет общаться легче сложить 1+1+1=, т.е. ваш официальный ответ "на бумаге", выписку от сотового оператора на стороне принимающей звонок и выписку на стороне осуществляющей звонок. Если итоговое число будет 3, то даже самый недальновидный опер отпустит вас с миром. А вот по поводу "всякого там у вас подписанного HMAC" вам надо будет приложить еще некоторые усилия, иногда очень и очень значительные что-бы объясниться. Это хозяину системы и хотспотов на заметку, что-бы не больно было при вызове в органы и не жалеть об затраченном времени.

Ну а теперь именно по авторизации через ЕСИА и VK/MAX. Конечно, некоторый контингент хочет эти "кнопАчки" так как нажимая их и ник можно получить пользователя и может какую-то еще информацию интересную, т.е. с точки зрения бизнеса и аналитики кнопочки прекрасны.
Но вот вы, лично, как разработчик, стали-бы заходить через соцсети, а тем более через ЕСИА, если перед вами есть возможность еще и звонком зайти ? Заход через соцсети и ЕСИА оправдан только когда нет мобильной связи, совсем и окончательно и еще главнее - если это очень-очень доверенный хотспот. В любом противном случае, сделайте звонок или получите его - риск что-то слить случайно или принять проблем как пользователь - минимален.

Все эти входы через месенджеры, просто что-бы не устраивать монополии и немного "разбавить концентрат" всех норм и ограничений. Учитывая совокупность проблем справа (от органов, при запросах "докажите") и слева (от пользователей, которые могут сказать что аккаунт был сломан при заходе через ваш хотспот, обвинения иногда наивны и беспочвенны, но органы их рассматривают с удовольствием) мы для себя сделали вывод один - только звонок, без вариантов. ЕСИА есть как официальный дополнительный резерв, им пользуются 0,1% отмороженых пользователей, хотя скорее всего всё придет к тому что работать в будущем придется только с ним, все эти звонки и мессенджеры могут отменить/запретить.

Причем звонки в центр идентификации желательно делать от пользователя, т.е. взять какой-то многоканальный номер 8-800, настроить на прием звонков через API, это относительно недорого, и делать сравнение введенного номера пользователя с точкой входа и номером непосредственно позвонившим. Потому что когда ваша система будет звонить (или отправлять SMS), в случае жалоб какого-то идиота-пользователя, с владельца системы будут спрашивать, почему он звонил потерпевшему, в момент кражи средств и "какой процент вы с этого имеете". Извините, но скажу честно, в этом бизнесе важно не только предложить качественное решение, найти и удовлетворить клиентов, быть стабильными и развиваться на рынке, но еще и "защитить свою задницу", потому что когда будут вызывать на всякие муторные беседы, просто послать инженера не получится, хотят общаться с директором, замом, тех.директором и т.д. а после нескольких таких консультаций возможны нервные срывы и т.д. Здоровье и спокойствие прежде всего !

[nikitajava]

Спасибо за замечания. Что касается авторизации через соцсети, то вы правы, их лучше использовать когда нет телефонной связи. Дело в том, что один из моих заказчиков - одна из сетей заправок, где не на всех объектах есть хорошая телефонная связь. Заказчик просил добавить авторизацию VK/MAX. А моя система позволяет на разных объектах добавлять разные типы авторизации.