Недавно мне посчастливилось заняться достаточно интересной практической задачей по организации общественного доступа в Интернет для международной компании «Coffee Сup», имеющей 5 собственных баров формата «кофе с собой» в разных городах, а так же дилеров по всей России и странах СНГ. Нужно все сделать, так как мы любим: желательно быстро и достаточно качественно. Гостевой доступ в Интернет организуется не только ради удобства пользователей сервиса, но и, в первую очередь, с точки зрения пользы для бизнеса: принудительно смотришь рекламу и получаешь свой бесплатный Интернет. В наше время, это уже абсолютно повсеместный сервис, встречаемый от метро и аэропортов, до торговых центров и других общественных площадок. Этими удаленными осенними вечерами родилось решение «сделай все своими руками», поэтому делюсь опытом и практическими наработками. Сразу забегу вперед, стоимость решения на один бар вышла 3700 рублей за оборудование и совсем немного сверху в счет аренды сервера. Но вернемся к нашей задаче.    С чего мы начали, так это с поиска готовых решений на рынке. С этим нет проблем, поддержка различного оконечного оборудования, «дружественный» интерфейс по его подключению на аутсорсинг, обещанная гарантия, что все по закону, всего 1000 рублей в месяц абонентской платы за каждое подключение. А для «Coffee Сup» это уже 5000 рублей/месяц, что равно 60 000 рублей/год (не считая оборудование). Поиском готовых аппаратно-программных реализаций даже не занимались – полная скука, даже можно сказать осенняя хандра. В общем, не наш метод. Надо во всем самим разобраться и все сделать самому.    Для начала была проведена декомпозиция и детализация задачи:  Разобраться в нормативно-правовых актах, чтобы все было по закону.  Выбрать и закупить необходимое оборудование.  Настроить и интегрировать оборудование в уже существующую инфраструктуру баров.  Настроить Hotspot (сконфигурировать роутеры и сделать страницы авторизации на сервисе под задачи маркетинга).  Настроить централизованное управление (удаленное управление маршрутизаторами, базу данных, backend и frontend).    Обо всем по порядку. Нам нужны постановления правительства России и от 31 июля 2014 г. №758 «О внесении изменений в некоторые акты …» и от 12 августа 2014 г.  №801 «О внесении изменений в некоторые акты …». Одно дополняет второе, как видно, между ними успело пройти целых 2 недели. В соответствии с ними (немного перефразировано для большей ясности): при оказании универсальных услуг связи по передачи данных и предоставлению доступа к сети Интернет с использованием пунктов коллективного доступа, мы обязаны идентифицировать пользователей в результате достоверного установления абонентского номера, назначенного пользователю.    Это единственно приемлемое решение в настоящее время, все остальные предлагаемые законом решения нам явно не подходят (паспорта, госуслуги и т.д.). Цитируем снова: сведения о пользователях …, а также об объеме и времени оказания им услуг связи хранятся … не менее 6 месяцев.    Что понимать под «объемом оказания им услуг связи» мы решили уточнить у роскомнадзора, написали им письмо и ничего до сих пор не получили в ответ. Остается на наше усмотрение: под объемом будем понимать результаты «NetFlow» (сбора информации об открытых пользователями соединениях, подробнее можно прочитать на https://en.wikipedia.org/wiki/NetFlow).    С этим разобрались, уже хорошо. Дошло дело до всеми любимого федерального закона от 27 июля 2006 г. №152-ФЗ «О персональных данных». Закон в принципе понятный, уже обкатанный вдоль и поперек, технически сложного он ничего не содержит – сплошная организационная рутина: согласия, политики, приказы и т.д. Попадаем ли мы со своим Hotspot под его действие? Ведь мы будем хранить просто номера телефонов… Ответ – не попадаем. Точку в этом вопросе в настоящее время ставит роскомнадзор на своем сайте в разделе вопросов и ответов (https://15.rkn.gov.ru/p8880/p15987/):    Согласно ст. 3 Федерального закона от 27.07.2006 №152-ФЗ «О персональных данных» Персональные данные - любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных). Абонентский номер (номер телефона) это выделяемый абоненту номер, (совокупность цифровых знаков) при заключении с абонентом договора об оказании услуг телефонной связи. Данный номер служит для обозначения и возможности идентификации конечного оборудования абонента в сети связи при соединении с ним абонентских устройств из чего следует, что номер телефона без указания на его владельца не является информацией, на основании которой это лицо (субъекта персональных данных) можно однозначно идентифицировать и его использование не может подразумевать обработку персональных данных его владельца.    Приступаем к технической части. В качестве оборудования было решено приобретать роутеры MikroTik по следующим причинам: поддерживают технологию Hotspot, отличное качество,  высокая гибкость, дружелюбные русскоязычные сообщества. Самое главное, наличие возможности работы в диапазоне 2.4 и 5 ГГц, чтобы нашему WiFi никто не мешал. Выбрали «hAP ac lite TC» (подробно про него можно посмотреть на сайте производителя https://mikrotik.com/product/RB952Ui-5ac2nD-TC, в характеристиках нам все нравится, особенно «Operating System RouterOS»). 3700 рублей каждый, отличная цена. Из рекомендаций – вполне можно приобретать изделия, бывшие в употреблении, рынок в Москве наиболее насыщенный и приятный по ценам, а доставка сейчас работает отлично в любой регион. Арендовали в Интернете Linux сервер, особо каких-то требований к этому вопросу тоже не предъявляли.    Все бары уже имели подключение к Интернет. Везде по-разному, где-то стоял 4G USB модем в другом роутере, где-то использовался мобильный WiFi роутер со встроенным аккумулятором. Изменять существующую инфраструктуру было запрещено из-за боязни, что что-нибудь перестанет безвозвратно работать, а все переделывать и безосновательно финансово удорожать проект – не хотелось. MikroTik везде интегрировался без проблем. Например, покажем как настроено получение Интернет по WiFi (как настроено это дело по кабелю от другого роутера или через 4G USB модем оставлю без комментариев):    Добавили скрипт в dhcp-client и скорректировали работу своего NAT (можно было бы настроить masquerade, однако вспомнили презентацию технического специалиста компании MikroTik «My holy war against masquerade», а также, что masquerade частный случай SRC-NAT и отказались от этой идеи):    Интернет до MikroTik-ов получили, далее настроили качественно и безопасно наши роутеры в  качестве точки доступа. Опишем только интересное. Сделали два профиля безопасности для WiFi (free и staff), включили сразу 3 WiFi сети: две для staff (для обоих диапазонов 2.4 и 5 ГГц, так как не все оборудование в барах умеет работать в 5 ГГц) и одну free (только на 5 ГГц). На 2.4 ГГц free решили не делать, так как приоритет отдан предоставлению Интернет пользователям с современными мобильниками, и кроме того наши роутеры умеют делать до 4 точек доступа одновременно. Рекомендовали барам все оборудование переподключить на staff, так как позже была задана приоритезация трафика в маршрутизаторах, а это значит, что никто из гостей нам не провалит "служебный" Интернет. В настройках WiFi оставили много параметров по-умолчанию, чтобы поддерживать максимальный парк подключаемых устройств. Важно помнить, что беспроводной интерфейс, выступающий в качестве клиента WiFi (через который мы забираем Интернет), должен быть обязательно master.    Настроили firewall, обязательно сделали отдельное правило для icmp (чтобы не было скрытых проблем с раздачей Интернет от вышестоящих маршрутизаторов) и заложили будущий VPN. Пример для 4G свистка:    Qos выполнили через маркировку трафика, скоростные лимиты выбрали из реальных измерений (мы использовали сервис от Яндекс «Интернетометр»):   Задействовали семейные DNS сервера от Яндекса: все-таки рабочий Интернет, да и место общественное.    На практике было установлено, что некоторые провайдеры блокируют использование не своих DNS-серверов. Чтобы решить это, можно получать адреса DNS серверов от вышестоящего маршрутизатора при работе DHCP-клиента (активация use-peer-ntp) или вложить свои DNS запросы в VPN туннель, а на арендуемом сервере настроить NAT и включить ip forward:    Настало время настройки технологии Hotspot непосредственно на роутерах. MikroTik из коробки поддерживает саму технологию, однако мы ее кастомизировали под "Coffee Cup", а также выполнили все требования российского законодательства. В процессе был найден полезный ресурс (https://mikrotik-training.ru/), посвященный настройке оборудования MikroTik, наработками которого мы воспользовались в своем проекте. Приступим к описанию. Создали профиль для Hotspot. При подключении к сети free роутер показывает web страницы авторизации в сервисе Hotspot от имени сайта coffeecuptogo.com, время жизни «cookie» задали 4 часа  (по истечении которых пользователя отправляются на переподключение). Работа технологии Hotspot, разумеется, касается только гостевой сети.    Здесь же в профиле пользователей создали скрипты, которые автоматически срабатывают при подключении и отключении пользователей. Логика у обоих скриптов одинаковая. Сначала собирается информацию на роутере, затем она отправляется методом http-get на наш сервер, на котором все это аккумулируется в базу данных (разберем ее позднее). Для защиты своего сервера от спама придумали ключ, который также передается и, в первую очередь, проверяется на сервере. На роутере собирается: имя роутера (для каждого бара задали его индивидуально), текущее время и дата на роутере (удобно их забирать здесь, а не получать на сервере, чтобы не заморачиваться потом в backend-е с часовыми поясами в разных барах), mac гостя, его ip в гостевой сети, а также текущие белый и серый ip адреса роутера (белый адрес мы берем через внешний сервис, хотя нет проблем его забирать на нашем сервере через массив $_SERVER в PHP, на котором написан наш backend), номер телефона клиента, который мы позже будем получать через форму авторизации в Hotspot и присваивать его значение в качестве имени пользователя (на сервер отправляется с первой цифрой 7), а также имя хоста телефона (может потом пригодится где-нибудь в маркетинге или статистике). Кстати новые версии iOS при подключении к точке доступа без пароля не передают имя хоста, что реализовано с целью сохранения конфиденциальности. Переменной LOGIN мы передаем отключился (LOGIN=2) ли клиент или наоборот подключился (LOGIN=1). Скрипт для аутентификации имеет вид:    Скрипт для деаутентификации имеет вид:    О том, что мы сохраняем и можем использовать в маркетинговых целях информацию о наших клиентах, а также конкретно какую именно информацию и пользовательское согласие на это, мы оформили в политике конфиденциальности, показываемой на странице авторизации в Hotspot. Теперь разберем сердце нашего сервиса, а именно скрипт, который будет автоматически выполняться на роутере каждые 10 секунд (через scheduler, разумеется). Для его работы донастроили логирование:    Наш скрипт обнаруживает в логе MikroTik сообщение с темой «hotspot» со словами «login failed». Эти записи будут появляться автоматически. Со стороны клиента это выглядит так: загрузилась форма авторизации на Hotspot, пользователь ввел свой телефонный номер, нажал кнопку получить пароль, в течение 10 секунд ему приходит пароль посредством SMS, пользователь вводит этот пароль и получает Интернет. На роутере это выглядит немного по-другому: произошла попытка авторизации на сервисе Hotspot неизвестного пользователя (ошибка «login failed»), скрипт получает имя этого пользователя (из того же лога) и его короткий пароль посредством http-get на наш backend (на сервере генерируются случайные пароли в нужном нам формате, опишем это позже), создает такого пользователя Hotspot, отправляет номер телефона и пароль методом http-get в SMS центр (который пересылает пароль на номер пользователя) и «очищает» лог с темой «hotspot» (уменьшает его до 1 строки и сразу увеличивает до 1000 строк). Случайный пароль генерируется на сервере, потому что RouterOS не имеет встроенной функции генерации случайных чисел, а самодельные решения из математических операций со временем (и т.п.) не всегда дают нужный результат. Создание такого механизма на MikroTik заслуживает независимого исследования. Кроме этого сделали защиту от пользователей, которые попытаются получить много SMS (и обнулить наш счет в SMS центре). Для этого воспользовались не по назначению возможностями firewall, а именно адрес листом. Каждого пользователя Hotspot (фактически его номер телефона) скрипт записывает в  /ip firewall address-list на 5 минут, а при попытке аутентификации на Hotspot, проверяет, нет ли там такого пользователя. Побочным явлением этого решения является появление «посторонних» записей в address-list – попытка RouterOS определить IP адрес для каждой DNS записи. Просто не обращаем на это внимание. В качестве SMS центра выбран sms.ru, так как у заказчика уже был с ними договор и оформлены все необходимые документы, в следствие чего уже был закреплен корректный caller id «Coffee Cup» (в качестве номера телефона, от имени которого приходят SMS).    Российское законодательство обязывает нас сохранять объем оказания пользователям услуг связи, поэтому настроили связку коллектора и клиента «Net-flow». На сервере с backend-ом:    На MikroTik (обращаем внимание на версию 5 протокола, так как коллектор работает именно с ней):    Кроме этого с целью сохранения конфиденциальности от третьих лиц (в том числе провайдера Интернет) передачу «Net-flow» трафика осуществляем по VPN каналу (ширины его полностью хватает для этой задачи). Настало время разобраться с формой авторизации в сервисе. При создании Hotspot в RouterOS появляется набор каталогов и файлов, отвечающих за его работу. Нас интересуют файлы /flash/hotspot/login.html и /flash/hotspot/alogin.html. Первый – это страница авторизации на сервисе, а вторая – это страница, которая будет показана пользователю после успешной авторизации. Подробнее об этом можно почитать тут https://wiki.mikrotik.com/wiki/Manual:Customizing_Hotspot.    Сверстали (переделали) login.html под заказчика, сохранили необходимую RouterOS структуру web страницы. Подробно расписали политику конфиденциальности.    Очень хотелось на странице alogin.html просто сделать редирект на сайт заказчика, но у этого решения есть большой минус: сайт подгружается не моментально (временная задержка на редирект, да и скорость Интернета не всегда достигает отличных значений). Если сверстать эту страницу и положить ее в память роутера, то она будет показана пользователю моментально. То, что мы и сделали. Единственное ограничение - это объем страницы, ведь в нашем маршрутизаторе всего 16 Мб памяти и львиную ее долю забирает созданная RouterOS структура файлов и каталогов Hotspot. Можно, конечно, присоединить USB flash, но не очень хочется занимать свободный (не всегда) единственный USB порт на MikroTik. Мы уместили alogin.html со всеми ссылками в 500 кб. На этом настройка Hotspot закончена, настал черед  разобрать backend.        Начнем с сервера. На нем работает база данных MySQL,  в которую накапливается информация о регистрациях пользователей в Hotspot, передаваемая скриптами роутеров. Принимается и сохраняется в базу данных информация посредством backend страницы на PHP, она же генерирует пароли для пользователей. Создали админку для заказчика и прокинули VPN до роутеров (надо же их администрировать кому-то). Теперь подробнее.    Как мы помним, маршрутизаторы передают нам: имя роутера, текущее время и дату, mac гостя, его ip в гостевой сети, а также текущие белый и серый ip адреса роутера, номер телефона клиента, имя хоста телефона и статус (авторизация или деавторизация). Все это аккумулируется в таблице registration. Информацию о барах (имя устройства MikroTik и описательная информация о его расположении) накапливается в таблице coffeepoints (здесь нам все сразу известно). По просьбе заказчика ввели излишнюю таблицу users, в которой накапливается информация о пользователях сервиса: номер телефона, и в каком баре впервые он появился. Создали техническую таблицу status, в которой переводится придуманные нами коды 1 или 2 в значения login и logout. Для резервного копирования базы данных лучше, конечно, настроить автоматическую репликацию, однако в связи с не большими объемами хранения информации в нашем проекте мы пошли другим путям: в cron еженедельно выполняется mysqldump базы данных, результаты периодически копируются в ручную на локальный хост.    Разберем одностраничный код backend. В общем виде там все работает так: проверяется корректность передаваемого на сервер APIKEY, если все верно, тогда наполняется база данных. Сначала извлекается из базы данных информация, описывающая бар. Затем проверяется, новый ли пользователь пришел в бар (в этом случае заполняется таблица users), или информация о нем уже содержится в базе данных. Переводятся в текст коды status. Затем вся необходимая информация заполняется в таблицу registrations. Если APIKEY не передавался (или не верен), то просто генерируется случайный пароль.    Осталось поговорить про админку, с которой заказчик сможет работать самостоятельно. Можно, конечно, просто установить на сервер готовые решения по работе с базой данных посредством web интерфейса (вроде phpmyadmin или adminer), но мы сделали все под ключ. Так как web дизайн это не наш конек, да и интереса к нему особо нет, то воспользовались нашим любимым getbootstrap.com. На выходе - строгий адаптивный frontend. В разделе «Регистрации» отображается журнал регистраций в сервисе, т.е. таблица registrations базы данных.    В разделе «Пользователи» видим информацию из таблицы users, в разделе «Бары» из coffeepoints, в разделе «Статусы» из status, а раздел «Подключения» введен для отладки. Поля дата и время передаются роутерами не в совсем красивом формате, что можно преобразовывать на нашем backend, но на функционал это не сильно влияет. Добавили возможность фильтровать вывод, а также экспорт в "MS Exel". Да и вообще здесь можно писать код в свое удовольствие, с делом и просто так. Не судите строго.    Пару слов о настройке VPN. Разумеется, VPN сервер вертится здесь же на арендуемом сервере (вот такой комбайн вышел), в качестве протокола выбран OpenVPN, как наиболее гибкий, безопасный и стабильный. С его настройкой нет никаких проблем: сделали инфраструктуру открытых ключей, нагенерировали сертификатов, самоподписали их. RouterOS, правда, умеет пока работать только с TCP соединением для OpenVPN, но это не беда. В целом, соединения устанавливаются и работают годами без проблем. В результате имеем удаленный доступ до роутеров из любой точки мира, самое главное не забываем работать в «Safe mode» (режим MikroTik, при котором в случае долгого обрыва канала управления маршрутизатор автоматически отменяет последнее изменение своей конфигурации), ведь настраивать удаленно firewall - это верная примета к дальней поездке. А также обращаем внимание на то, что по нашей ошибке при переносе настроенных конфигураций между роутерами, возможно совпадение mac адресов сетевых интерфейсов, что может доставить немного хлопот.    Наконец наша статья подошла к концу. Опираясь на имеющиеся в Интернете наработки,  мы самостоятельно запустили сервисы Hotspot для баров компании «Coffee Сup», функционирующих в рамках действующего российского законодательства, используя силу оборудования MikroTik, мощь PHP и универсальность MySQL. Не боимся экспериментировать и разбираться с разными технологиями. Всех с наступающим 2021 годом!