Page History

Для корректной работы системы WNAM необходимо спроектировать создать проекты и настроить соответствующее сетевое окружение.

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

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

• контроллер беспроводных точек доступа, который имеет соответствующие функции (называемые производителем hostspot/wispr/external captive portal и т.п.): Cisco WLC, Bluesocket vWLC, Ruckus, Zyxel NXC, Aruba, UniFi, HP MSM
• любая "бытовая" точка доступа с установленной прошивкой OpenWrt/dd-wrt и программным пакетом CoovaChilli
• маршрутизатор с функцией портала перехвата hotspot, возможно со встроенной точкой доступа: Mikrotik (модели RB951Ui-2HnD, RB951G-2HnD, RB750UP, RB2011iL-IN, RB1100AHx2 и т.п.)
• сервер-маршрутизатор Linux, выполняющий роль шлюза по умолчанию для сети абонентов Wi-Fi
• маршрутизатор на основе pfSense (клон FreeBSD) с функцией Captive Portal 
• сервер-концентратор доступа BRAS, например Cisco 7200, Cisco ASR, Alcatel-Lucent SR7750 (требует дополнительной лицензии)

В первую очередь, вы должны построить беспроводную сеть доступа для ваших абонентов. В случае контроллерно-управляемых точек доступа, точки должны соответствовать контроллеру. В остальных случаях можно использовать любые точки доступа. Из соображений безопасности крайне желательно разграничить сетевые сегменты открытой (публичной части), и вашей внутренней сети. Такое разграничение можно обеспечить либо на физическом уровне, либо при помощи VLAN.

В приведенном ниже примере в качестве точек доступа используются Ubiquiti UniFi (открытая сеть без встроенного портала), в качестве маршрутизатора/хотспота Mikrotik.

Image Removed

Для идентификации через СМС сервер будет отправлять команды на отправку СМС с кодом доступа через шлюз СМС-провайдера (в настоящее время поддерживаются провайдеры SMSC, Websms.By, smstraffic, МТС.Коммуникатор, отправка через локально установленный USB GSM модем (утилита gammu), через установленный в маршрутизатор Mikrotik USB модем, или через любого провайдера по протоколу SMPP v3.4 через утилиту kannel). Возможна также отправка голосового вызова на телефон абонента, где автоматически будет продиктован код доступа, через нескольких операторов, а также приём звонка от абонента через шлюз Asterisk.

Если у вас несколько площадок, где вы предоставляете доступ пользователям, вы можете установить на каждой из них по своему маршрутизатору Mikrotik. В таком случае вам необходимо настроить несколько экземпляров "серверов доступа" и "площадок" в соответствующих разделах интерфейса WNAM (внимание: количество площадок лицензируется). Если места предоставления услуги находятся где-тов Интернете (который предоставляет на месте альтернативный провайдер), вы можете связать площадки с центральным узлом (где находится сервер) при помощи VPN (OpenVPN, VPLS, VLAN и т.п.):

Image Removed

Вы можете также привязать несколько площадок на один маршрутизатор MikroTik (несколько экземпляров HotSpot).

Для успешной работы необходима настройка трёх компонентов: WNAM, RADIUS-сервера, портала HotSpot.

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

1. Пользователь подключает свое беспроводное устройство (ноутбук, смартфон, планшет) к беспроводной сети (без авторизации), построенной на основе UniFi или иного радио-оборудования, получает IP-адрес от маршрутизатора (DHCP).
2. Пользователь открывает какую-либо страницу в сети Интернет (либо его устройство само открывает страницу).
3. Маршрутизатор или контроллер (компонент HotSpot) считает сессию пользователя "не авторизованной" и производит перенаправление сессии пользователя "на себя".
4. HotSpot отображает пользователю собственную страницу авторизации (например, rlogin.html для Mikrotik). Указанная страница (шаблон) должны быть предварительно загружена в маршрутизатор, и в ней указана автоматическая отправка формы на внешний сервер WNAM. Производители контроллерно-управляемого радио-оборудования имеют такую функцию в настройках контроллера.
5. Форма содержит ссылку на встроенный в WNAM веб-сервер, который показывает пользователю страницу СМС-идентификации.
6. Пользователь вводит номер своего телефона.
7. При получении номера телефона WNAM генерирует случайный (4 или 6-циферный) код активации, и через СМС-шлюз отправляет его на указанный телефон. Альтернативным способом является запрос пользователя отправить с этого телефона СМС на указанный вами номер - в таком случае, оплата за СМС перекладывается на абонента. 
   Image Removed
8. Пользователь вводит код подтверждения
9. При совпадении WNAM производит редирект (средствами HTTP redirect) сессии пользователя в сторону HotSpot маршрутизатора, либо открывает доступ пользователю иным способом.
10. HotSpot производит проверку МАС-адреса пользователя путём отправки RADIUS-запроса серверу WNAM
11. RADIUS-сервер, получив запрос на авторизацию, через Perl-модуль wnam-freeradius-bridge.pl передает в WNAM запрос на авторизацию (MAC-адрес абонентского устройства пользователя, идентификаторы площадки, текущий IP-адрес и т.п.).
12. WNAM авторизует такое обращение, создает в своей базе учётную запись абонента (пользователя) по МАС-адресу (если такого адреса ещё не было), возвращает ответ RADIUS-серверу
13. RADIUS-сервер возвращает ответ маршрутизатору
    Image Removed
14. Маршрутизатор авторизует на своем портале HotSpot сессию пользователя, открывая ему доступ в Internet. 
15. Одновременно с этим отправляет RADIUS-серверу запрос начала сессии (Accounting-Start).
16. RADIUS-сервер транслирует запрос начала учёта сессии в WNAM, тот создаёт запись о новой сессии. Периодически получая сообщения о статусе сессии, WNAM ведет статистику о переданном абонентом трафике.
17. При настройке на маршрутизаторе или контроллере отправки детальных сведений о трафике абонента в сторону WNAM производится привязка получаемой статистики к текущей сессии абонента, и хранение её в базе данных для возможного последующего розыска абонента.
18. По завершении сессии (тайм-аут) сессий закрывается, а пользователь, если ещё не отключился и активен, снова перенаправляется на страницу подтверждения.
    Image Removed

На один номер телефона можно привязать несколько устройств (МАС-адресов), в том числе тех, которые не имеют SIM-карты. Время жизни такой авторизации определяется в параметрах (меню "Конфигурация" - "Общие настройки" - "Авторизация" - "Длительность авторизации телефонного номера"), либо в индивидуальных настройках площадки. рекомендуется выставлять это время в 180 дней. При повторных подключениях того же пользователя, если с момента авторизации не прошло указанное выше время, производится безусловная (без подтверждений и СМС) авторизация сессии.

Настройки административного интерфейса WNAM позволяют установить содержимое страниц, отображаемых абонентам при первоначальном подключении (авторизации) и при каждом последующем подключении к сети. Помимо демонстрации рекламных материалов, формы согласия с условиями предоставления услуги возможно безусловно перенаправлять HTTP-сессию абонента на указанный вами сайт. Во всех случаях производится учёт числа показов и переходов по страницам каждого из типов, с возможностью получить детальную статистику в административном интерфейсе WNAM.

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

Image Removed

значительное число компонентов, а именно:

• устройства сетевого доступа NAS (контроллеры БЛВС для гостевого и/или корпоративного подключения, коммутаторы ЛВС, шлюзы VPN и т.п.);
• сетевую инфраструктуру, обеспечивающую подключение физических или виртуальных серверов WNAM;
• физические или виртуальные машины с ОС Linux для установки системы WNAM, СУБД и других компонентов;
• СМС-шлюзы или программные АТС для отправки идентификационной информации;
• средства мониторинга;
• средства резервного копирования.

Настоятельно рекомендуется обращаться для этой цели к системным интеграторам, имеющим опыт работы с системой WNAM. Особенно, если требуется построение сложной, нагруженной и распределенной инсталляции системы WNAM для нужд корпоративной авторизации. Получить рекомендации по выбору системного интегратора можно, отправив запрос на info@netams.com. Компания-разработчик системы WNAM не может рекомендовать "идеальный" дизайн сопутствующих систем: сетевой инфраструктуры, средств виртуализации, средств обеспечения информационной безопасности, резервного копирования, доменной структуры Windows и т.п. 

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

В первую очередь, необходимо изучить сценарии работы основных способов авторизации:

• сценарий гостевой авторизации;
• сценарий корпоративной авторизации.

В работе системы вы можете одновременно использовать оба сценария. А также для использования в крупной сети настоятельно рекомендуется организовать два не связанных между собой кластера систем WNAM, работающих в разных информационных контурах: один только для гостевой, другой только для корпоративной авторизации.

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

• число одновременно идущих процедур авторизации и число одновременно работающих в сети гостей / эндпоинтов;
• физические характеристики имеющихся серверов;
• требования по отказоустойчивости и географическому разнесению узлов системы.

В конечном счете, устойчивая работа системы WNAM определяется нагрузкой на неё, которая напрямую связана с числом Web- и RADIUS-запросов, попадающих на систему. Рекомендуется проектировать объемы ресурсов таким образом, чтобы:

• нагрузка на процессор сервера не превышала 50% (т.е. величина LA сервера была вдвое меньше числа установленных процессорных ядер);
• задержка RADIUS-ответа в среднем не превышала 40 миллисекунд.

1.Типовой сценарий малой нагрузки

Если в сети находится менее 200 точек доступа (т.е. менее 1000 одновременно работающих гостевых клиентов) или корпоративная авторизация требует менее чем 200 эндпоинтов, подойдет дизайн, в котором все компоненты системы авторизации работают на одном физическом или виртуальном сервере.

Image Added

Типовые характеристики такого сервера:

• количество виртуальных процессоров: 2-4 vCPU;
• оперативная память: 8 Gb vRAM;
• объем жесткого диска: 50 HB HDD (любого типа).

2. Сценарий средней нагрузки без отказоустойчивости

Если в сети находится менее 500 точек доступа (т.е. менее 5000 одновременно работающих гостевых клиентов) или корпоративная авторизация требует менее чем 500 эндпоинтов, рекомендовано вынести на отдельный сервер базу данных MongoDB.

Image Added

В данном случае понадобится два одинаковых сервера с характеристиками:

• количество виртуальных процессоров: 2-4 vCPU;
• оперативная память: 8-16 Gb vRAM;
• объем жесткого диска: 50 HB HDD (любого типа).

Дополнительно для сервера MongoDB необходимо:

• объем жесткого диска: 50 HB HDD (типа SSD).

3. Сценарий высокой нагрузки с локальной отказоустойчивостью

Если в сети находится менее 1000 точек доступа (т.е. менее 10000 одновременно работающих гостевых клиентов) или корпоративная авторизация требует менее чем 1000 эндпоинтов, рекомендовано создать отказоустойчивый кластер MongoDB. Такой кластер требует трёх узлов (primary, secondary, arbiter), причем только два из них несут копию базы, а третий участвует в кворуме. Также желательно вынесение прокси-сервера на отдельный узел для того, чтобы перенести нагрузку обработки SSL-трафика с сервера приложения.

Image Added

В случае аварии основного сервера MongoDB (на схеме справа) система WNAM автоматически переключит запись/чтение на резервный сервер СУБД (на схеме слева). 

В таком случае понадобится три одинаковых сервера с характеристиками:

• количество виртуальных процессоров: 4-8 vCPU;
• оперативная память: 16 Gb vRAM;
• объем жесткого диска: 50 HB HDD (любого типа) системные диски.

Дополнительно для двух серверов MongoDB (primary, secondary) необходимо:

• объем жесткого диска: 50 HB HDD (типа SSD) - для СУБД;
• объем жесткого диска: 500 HB HDD (типа SATA) - для дампов СУБД.

4. Сценарий средней нагрузки с распределенной отказоустойчивостью

Если сеть соответствует характеристикам сценариев 2 или 3, но при этом требуется получить полную отказоустойчивость системы, при которой её работоспособность сохраняется при выходе из строя одного из серверов системы WNAM, можно использовать сценарий средней нагрузки с распределенной отказоустойчивостью.

При таком сценарии (4.1) репликация данных производится не средствами кластера СУБД MongoDB, а путем пересылки информационных сообщений между двумя разрозненными автономными инстансами (экземплярами) MongoDB, каждый из которых взаимодействует только с локальным экземпляром системы WNAM.

Image Added

В таком режиме понадобится наcтроить репликацию данных средствами Kafka.

Для административного доступа в веб-интерфейс, а также для редиректа HTTP-запросов клиентов от оборудования хотспота понадобится настроить кластерный IP-адрес серверов. Кластерный IP-адрес серверов (.1 на схеме) необходимо указать в качестве единственного адреса RADIUS-сервера на оборудовании.

Если не требуется использовать гостевой доступ, можно настроить любой из двух серверов системы WNAM через веб-интерфейс, и в качестве RADUIS-сервера на используемом оборудовании указать оба IP-адреса (.2 и .3 на схеме).В случае аварии любого из серверов система продолжит выполнять свои функции. Преимуществом этого сценария является отсутствие необходимости иметь общий (кластерный) IP-адрес, что возможно лишь при нахождении обоих серверов в одном сетевом сегменте. Таким образом, можно настроить два сервера авторизации системы WNAM, находящихся в разных сетях (разных дата-центрах или даже разных городах), сценарий 4.2:

Image Added

При настройке данного сценария понадобится два одинаковых сервера с характеристиками:

• количество виртуальных процессоров: 4-8 vCPU;
• оперативная память: 16 Gb vRAM;
• объем жесткого диска: 50 HB HDD (любого типа) системные диски;
• объем жесткого диска: 50 HB HDD (типа SSD) - для СУБД;
• объем жесткого диска: 500 HB HDD (типа SATA) - для дампов СУБД.

5. Сценарий высокой нагрузки с распределенной отказоустойчивостью

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

Image Added

В данном сценарии понадобится создать два или три (по числу имеющихся площадок ЦОД) одинаковых кластера системы WNAM в составе трех серверов, каждый из которых должен иметь такие характеристики:

• количество виртуальных процессоров: 8 vCPU;
• оперативная память: 32 Gb vRAM;
• объем жесткого диска: 50 HB HDD (любого типа) системный диск;
• объем жесткого диска: 50 HB HDD (типа SSD) - для СУБД (для серверов 1 и 3);
• объем жесткого диска: 500 HB HDD (типа SATA) - для дампов СУБД (для сервера 2).

6. Сценарий высокой нагрузки с распределенной отказоустойчивостью и поддержкой изолированной работы

Если имеется множество (сотни) удалённых площадок (сайтов), с которыми невозможно гарантировать постоянное наличие сетевой связи как минимум с одним из ЦОД, в котором работает экземпляр системы WNAM, необходимо сформировать сетевую конфигурацию, при которой даже при отсутствии сетевой связности будет обеспечиваться работоспособность корпоративной авторизации. При этом допустима деградация услуги (например, увеличение длительности процесса авторизации, невозможность изменения настроек и/или просмотра статистики, невозможность обеспечить подключение новых устройств и т.п.). В таком случае, на каждой такой площадке необходимо установить специализированного агента авторизации (RADIUS-прокси/кэширующий сервер). В обычном режиме работы он прозрачно пропускает через себя запросы авторизации, маршрутизируя их в сторону доступных ЦОД с работающей системой WNAM. Результат авторизации сохраняется. При разрыве сетевой связности этот сервер проводит авторизацию устройств самостоятельно, пользуясь накопленными ранее данными.

Image Added

При этом в каждом филиале потребуется развернуть виртуальную машину или Docker-контейнер с ПО, имеющим следующие требования:

• количество виртуальных процессоров: 1-2 vCPU;
• оперативная память: 2 Gb vRAM;
• объем жесткого диска: 16 HB HDD (любого типа).

Взаимодействие компонентов

В состав системы WNAM входит значительное число системного и прикладного ПО, которое взаимодействует друг с другом в пределах одного сервера (виртуальной машины), а также между серверами. В дополнение к этому, система взаимодействует с внешним миром (сервера доступа, пользовательские устройства, администраторы) по различным протоколам стэка TPC/IP. Описание такого обмена приведено в соответствующем разделе.

Резервное копирование

Настоятельно рекомендуется настроить резервное копирование системы WNAM одновременно по обоим направлениям:

• для серверов, на которых работает MongoDB: через cron (демона-постановщика задач систем Unix) по расписанию, раз в сутки ночью, дамп базы данных в файлы, на другой (относительно основного) физический диск, с удалением старых резервных копий;
• резервное копирование виртуальной машины целиком, используя средства резервного копирования используемой платформы виртуализации. 

При использовании кластерного варианта MongoDB можно не копировать разделы, содержащие файлы БД (в любом случае восстановить из "горячего бэкапа" кластерную БД не получится). Резервное копирование виртуальных машин должно включать в себя копии дампов БД, которые должны формироваться до того, как проводится процедура бэкап.

Управление доступом к административному интерфейсу

Поскольку система WNAM представляет собой монолитное Java-приложение, то обработчик веб-интерфейса администратора ("административный веб-интерфейс"), личный кабинет клиента/менеджера подразделения и интерфейс авторизующегося гостевого клиента по умолчанию работают внутри одного процесса. Для того, чтобы разделить возможность доступа разным категориям пользователей этого интерфейса с точки зрения безопасности, наиболее оптимальным сценарием является:

1. Вынос роли веб-сервера на отдельную виртуальную машину.
2. Установка на виртуальной машине SSL-сертификата, обеспечивающего, в конечном счете, шифрование передаваемого трафика управления системой.
3. Настройка разграничения доступа к различным разделам интерфейса путем тонкой настройки конфигурационного файла nginx.

Применяемые в системе пути (ссылки) группированы следующий образом:

Таким образом, целесообразно разрешить доступ к административному интерфейсу системы только с тех IP-адресов, в которых находятся АРМ администраторов этой системы, используя такой конфигурационный файл (/etc/nginx/sites-available/wnam):

server {
 listen 443 ssl default_server;
 listen [::]:443 ssl default_server;
 ssl_certificate /etc/nginx/cert/fullchain_2023.crt;
 ssl_certificate_key /etc/nginx/cert/key2023.key;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_prefer_server_ciphers on;
 ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
 ssl_ecdh_curve secp384r1;
 ssl_session_cache shared:SSL:10m;
 ssl_session_tickets off;
 ssl_stapling on;
 ssl_stapling_verify on;
 resolver 8.8.8.8 8.8.4.4 valid=300s;
 resolver_timeout 5s;
 add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
 add_header X-Frame-Options SAMEORIGIN;
 add_header X-Content-Type-Options nosniff;

ssl_dhparam /etc/ssl/certs/dhparam.pem;

root /var/www/html;
 index index.html;
 server_name wifi.provider.ru;
 client_header_buffer_size 16k;
 large_client_header_buffers 2 16k;

location / {
 proxy_pass http://127.0.0.1:8080/;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header Host $host;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_read_timeout 300;
 proxy_connect_timeout 300;

proxy_buffer_size 16k;
 proxy_buffers 4 16k;
 proxy_busy_buffers_size 16k;
 client_body_buffer_size 16K;
 client_max_body_size 8m;

}

location /wnam/ {
 proxy_pass http://127.0.0.1:8080/wnam/;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header Host $host;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_read_timeout 300;
 proxy_connect_timeout 300;

 allow 127.0.0.1; # internal page contructor 
 allow 192.168.199.0/24; # администраторы офис
 allow 234.56.78.90; # админ василий пупкин, из дома
 deny all;

 client_max_body_size 20M;
 }

}

...