Принципы работы

Для корректной работы WNAM вам необходимо запроектировать и настроить значительное число компонентов, а именно:

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

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

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

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

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

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

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

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

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

Рекомендуется проектировать объемы ресурсов таким образом, чтобы:

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

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

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

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

• 2-4 vCPU
• 8 Gb vRAM
• 50 HB HDD (любого типа)

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

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

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

• 2-4 vCPU
• 8-16 Gb vRAM
• 50 HB HDD (любого типа)

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

• 50 HB HDD (типа SSD)

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

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

В случае аварии основного сервера 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, вы можете рассмотреть этот сценарий.

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

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

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

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

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

• 4-8 vCPU
• 16 Gb vRAM
• 50 HB HDD (любого типа) - системный диск
• 50 HB HDD (типа SSD) - для СУБД
• 500 HB HDD (типа SATA) - для дампов СУБД

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

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

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

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

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

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

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

• 4-8 vCPU
• 16 Gb vRAM
• 50 HB HDD (любого типа) - системный диск
• 50 HB HDD (типа SSD) - для СУБД
• 500 HB HDD (типа SATA) - для дампов СУБД
  
  

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

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

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

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

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

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

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

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

Вынос роли веб-сервера на отдельную виртуальную машину

Установку на ней SSL-сертификата, обеспечивающего, в конечном счете, шифрование передаваемого трафика управления системой

Настройку разграничения доступа к различным разделам интерфейса путем тонкой настройки конфигурационного файла 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;
 }

}