Настройка доменной аутентификации Wi-Fi с использованием Radius от Microsoft. Часть I. – Альянс

Вступление

Начнем нашу серию статей с подготовки, для начала нам нужен Radius Server, который мы будем поднимать и настраивать в облачной среде MS Azure. Представим, что вы уже читали наши статьи и у вас есть некоторое понимание настройки Mikrotik, сам настроенный роутер этой марки, у вас есть подписка в Azure и поднятый VPN с ней, допустим, для 1C.

Соединять с землей мы будем не поднятием VPN, а использовать уже используемый VPN и пиринг сетей.

Настройка FreeRADIUS.

Начнем с установки и настройки FreeRADIUS сервера.

В операционной системе Gentoo это делается довольно просто, достаточно ввести команду
=====================================================
root@s2 ~ # emerge -av freeradius

These are the packages that I would merge, in order:

Calculating dependencies …done!

[ebuild N ] net-dialup/freeradius-1.0.5-r1 -edirectory
-frascend -frnothreads -frxp -kerberos -ldap -mysql pam
-postgres -snmp ssl -udpfromto 2,240 kB

Total size of downloads: 2,240 kB

Do you want me to merge these packages? [Yes/No]
=====================================================

Если планируется хранить базу пользователей во внешних базах (например, ldap, mysql или postgre), то перед сборкой RADIUS сервера надо активировать соответствующие флаги, позволяющие собрать FreeRADIUS с поддержкой mysql/postgre и/или ldap:
=====================================================
# USE=”mysql ldap” emerge -av freeradius
=====================================================

После проверки включенности нужных флагов, достаточно нажать клавишу Y и пакет будет собран и установлен в систему:
=====================================================

<….>

— !targe sym /usr/lib/rlm_digest-1.0.5.la
— !targe sym /usr/lib/rlm_detail.so
— !targe sym /usr/lib/rlm_detail-1.0.5.la
— !targe sym /usr/lib/rlm_counter.so
— !targe sym /usr/lib/rlm_counter-1.0.5.la
— !targe sym /usr/lib/rlm_checkval.so
— !targe sym /usr/lib/rlm_checkval-1.0.5.la
— !targe sym /usr/lib/rlm_chap.so
— !targe sym /usr/lib/rlm_chap-1.0.5.la
— !targe sym /usr/lib/rlm_attr_rewrite.so
— !targe sym /usr/lib/rlm_attr_rewrite-1.0.5.la
— !targe sym /usr/lib/rlm_attr_filter.so
— !targe sym /usr/lib/rlm_attr_filter-1.0.5.la
— !targe sym /usr/lib/rlm_always.so
— !targe sym /usr/lib/rlm_always-1.0.5.la
— !targe sym /usr/lib/rlm_acct_unique.so
— !targe sym /usr/lib/rlm_acct_unique-1.0.5.la
— !targe sym /usr/lib/libradius.so
— !targe sym /usr/lib/libradius-1.0.5.la
— !targe sym /usr/lib/libeap.so
— !targe sym /usr/lib/libeap-1.0.5.la
>>> original instance of package unmerged safely.
>>>

Вышеприведенный лог сборки (его конец) показывает, что FreeRADIUS 1.0.5 успешно установлен в систему (о чем сообщает строка ” net-dialup/freeradius-1.0.5-r1 merged”). Можно приступать к его настройке.

1 файл /etc/raddb/clients.conf

Для начала пропишем клиентов (в данном случае — точку доступа) в файле /etc/raddb/clients.conf
#—————————————————-
client 192.168.1.250/32 {
secret = test1234
shortname = test_ap
}
#—————————————————-

Эта запись означает, что клиент с адресом 192.168.1.250 авторизируется на RADIUS-е с паролем test1234. Имя test_ap будет использована при логировании событий, связанных с этой точкой доступа.

Не забываем сменить стандартный пароль для localhost_клиентов:
#—————————————————-
secret = very_strong_secret_password
#—————————————————-

2 файл /etc/raddb/radiusd.conf

Теперь разберемся с основным файлом конфигурации Radius-а /etc/raddb/radiusd.conf

Секция Modules{ }, раздел mschap { }

Включаем

use_mppe = yes # использовать алгоритм mppe

require_encryption = yes # использовать шифрование

require_strong = yes # только сильное шифрование

3 файл /etc/raddb/proxy.conf

Теперь открываем файл /etc/raddb/proxy.conf и добавляем в конец этого файла
#—————————————————-
realm DEFAULT {
type = radius
authhost = LOCAL
accthost = LOCAL
}
#—————————————————-

DEFAULT реалм, добавленный нами, позволяет всем аккаунтам, которые не попали ни в один вышезаданный реалм, проверяться на локальном радиусе. В нашем случае это означает, что все windows-аккаунты с отрезанной доменной частью будут проверяться локально.

4 файл /etc/raddb/eap.conf

Переходим к настройке протокола EAP. Его настройки располагаются в отдельном файле, который, в свою очередь, подключается к основному /etc/raddb/radiusd.conf вот такой конструкцией:
#—————————————————-
$INCLUDE ${confdir}/eap.conf
#—————————————————-

Открываем /etc/raddb/eap.conf

В секции eap{ }
#—————————————————-
default_eap_type = peap # по-умолчанию, используем EAP-PEAP
#—————————————————-

Раскомментируем секцию, относящуюся к peap:
#—————————————————-
peap {
default_eap_type = mschapv2
}
#—————————————————-

Но этого недостаточно для функционирования PEAP, нам также необходимо активировать (раскомментировать) секцию, отвечающую за EAP-TLS:
#—————————————————-
tls {
private_key_password = whatever
private_key_file = ${raddbdir}/certs/cert-srv.pem

certificate_file = ${raddbdir}/certs/cert-srv.

В данном случае использованы цифровые сертификаты, сгенерированные автоматически, при установке пакета freeradius. Можно, конечно, создать собственные сертификаты, подписанные своим (или сторонним) сертификационным центром, но для простоты объяснения, этот этап опущен (он будет подробно расписан в следующей части статьи). Для работы RADIUS-сервера для обеспечения работы EAP-PEAP протокола, вышеприведенных настроек будет достаточно.

6 права доступа к /etc/raddb/

Пара слов о безопасности. При установке пакета freeradius создается пользователь radiusd и группа radiusd, которая является основной для этого пользователя. Права на директорию конфигурационных файлов RADIUS устанавливаются следующие:
=====================================================
# /bin/ls -l /etc | grep raddb
drwxr-x— 3 root radiusd 4096 Oct 12 15:10 raddb
=====================================================

7 запуск radiusd в режиме отладки

На этом настройка FreeRadius сервера завершена. Можно запустить его в режиме отладки командой

# /usr/sbin/radiusd -fX

Настройка точки доступа.

Здесь описывается лишь настройка точки доступа в качестве Radius-клиента. Разумеется, интерфейсы точек доступа разных производителей будут выглядеть по-разному, но общие принципы настроек изменяться не будут.

Надо сделать следующее:

• включить WPA;
• выбрать тип шифрования (AES или TKIP)
• прописать адрес RADIUS-сервера
• прописать пароль доступа (shared secret) к RADIUS-серверу

Вводим SSID беспроводной сети (WPA-PEAP), активируем “Security” и жмем кнопку “Configure Security”.

В появившемся окне выбрать WPA RADIUS в пункте “Security Mode”. Далее алгоритм шифрования — установить AES (или TKIP, если клиентское оборудование AES не поддерживает). Далее вводим адрес машины, где установлен RADIUS сервер и порт, по которому оный принимает запросы (порт 1812 — является стандартным).

Осталось задать “Shared Secret” (пароль на подключение) и все — настройка точки доступа на этом завершена.

Добавление FreeRadius в автостарт

Осталось лишь остановить FreeRADIUS сервер, запущенный в режиме отладки, добавить его в автостарт…
=====================================================
# rc-update add radiusd default
* radiusd added to runlevel default
=====================================================

…для того, чтобы radiusd сервис запускался при старте системы, и запустить его (однократно) в нормальном режиме:
=====================================================
# /etc/init.d/radiusd start
* Starting radiusd … [ ok ]
=====================================================

Все, настройка системы на этом завершена.

Freeradius

FreeRadius будем поднимать на CentOS 7.6. Здесь ничего сложного, ставим обычным способом.

yum install freeradius freeradius-utils freeradius-ldap -y

Из пакетов ставится версия 3.0.13. Последнюю можно взять на

Linux

Я проверял на Ubuntu 18.04, 18.10, Fedora 29, 30.

Для начала, скачиваем себе сертификат. Я не нашел в Linux, есть ли возможность использовать системные сертификаты и есть ли там вообще такое хранилище.

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

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

anonymous — clientdomain — домен, на который выпущен сертификат

Non-samsung

C 7 версии при подключении WiFi можно использовать системные сертификаты, указав только домен:

domain — домен, на который выпущен сертификатanonymous — client

Samsung

Как уже писал выше, Samsung-устройства не умеют использовать системные сертификаты при подключении WiFi, и у них нет возможности подключаться по домену. Поэтому надо вручную добавить корневой сертификат центра сертификации (ca.pem, берем на Radius сервере). Вот здесь будет использовать самоподписанный.

Скачиваем сертификат себе на устройство и устанавливаем его.

Установка сертификата

При этом, надо будет установить рисунок разблокировки экрана, пин-код или пароль, если он еще не установлен:

Я показал сложный вариант установки сертификата. На большинстве устройств достаточно просто нажать на скаченный сертификат.

Когда сертификат установлен, можно переходить к подключению:

сертификат — указываем тот, который устанавливалианонимный пользователь — guest

Windows 10

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

Далее нужно создать новое подключение. Для этого идем в параметры сети и Интернет -> Центр управления сетями и общим доступом -> Создание и настройка нового подключения или сети:

Вручную прописываем имя сети и меняем тип безопасности. После нажимаем на изменить параметры подключения и во владке Безопасность выбираем проверку подлинности сети — EAP-TTLS.

Заходим в параметры, прописываем конфиденциальность аутентификации — client. В качестве доверенного центра сертификации выбираем добавленный нами сертификат, ставим галочку «Не выдавать пользователю приглашение, если не удается авторизовать сервер» и метод проверки подлинности выбираем — незашифрованный пароль (PAP).

Возможные вопросы

В: как передавать профиль/сертификат сотруднику?

О: Все сертификаты/профили я храню на фтп с доступом через веб. Поднял гостевую сеть с ограничением по скорости и доступом только в интернет, за исключением фтп. Аутентификация держится 2 дня, после чего сбрасывается и клиент остается без интернета. Т.о. когда сотрудник хочет подключиться к WiFi, сначало он подключается к гостевой сети, заходит на фтп, скачивает нужный ему сертификат или профиль, устанавливает их, и после может подключаться к корпоративной сети.

В: почему не использовать схему с MSCHAPv2? она же более безопасная!

О: во-первых, такая схема хорошо работает на NPS (Windows Network Policy System), в нашей реализации необходимо дополнительно настраивать LDAP (FreeIpa) и хранить хэши паролей на сервере. Доп. настройки делать не желательно, т.к. это может привести к различным проблемам сихронизации УЗ. Во-вторых, хеш представляет собой MD4, так что это не особо повышает безопасность

В: можно ли авторизовывать устройтсва по mac-адресам?

О: НЕТ, это не безопасно, злоумышленник может подменить мак-адреса, и тем более авторизация по мак-адресам не поддерживается на многих устройствах

В: зачем вообще все эти сертификаты использовать? можно же и без них подключаться

Контроллер ubiquiti

На контроллере поднимаем отдельную сеть. Пусть будет 192.168.2.0/24Идем в настройки -> профиль. Cоздаем новый:

Прописываем адрес и порт radius-сервера и пароль, который прописывали в файле clients.conf:

Создаем новое имя беспроводной сети. В качестве метода аутентификации выбираем WPA-EAP (Enterprise) и указываем созданный radius-профиль:

Все сохраняем, применяем и идем дальше.

Настройка ias и точек доступа

После настройки беспроводных клиентов можно перейти к настройке сервера IAS и точек доступа. На сервере IAS необходимо задать политику удаленного доступа, которая свяжет аутентификационные запросы WLAN с требованиями аутентификации 802.1x, основанной на сертификатах.

Нажав правую кнопку на панели с детальной информацией, следует выбрать New Remote Access Policy. Нажмите Next на первой странице мастера New Remote Access Policy Wizard. На следующей странице требуется выбрать Use the wizard to set up a typical policy for a common scenario, ввести имя политики удаленного доступа, например WLAN Access for Domain Computers, и нажать Next.

Настройка клиентов

Начнем с самого сложного!

Настройка прохождения трафика через пиринг до земли.

Переходим к роутеру Mikrotik, заходим в интерфейс и идем во вкладку IP – Ipsec – Policies, нажимаем «крестик» и добавляем новую политику. На вкладке General  выбираем нужный нам peer, через который у вас идет VPN, ставим галочку на «Tunnel», вводим исходный адрес и удаленный адрес во вкладках Src и Dst, соответственно. Заходим во вкладку Action и ставим наши предложения, на которых работает VPN.

Либо консольно:

/ip ipsec policy add dst-address=(удаленный адрес)/23 peer=peer_S2S proposal=proposal_S2S src-address=(локальный адрес)/24 tunnel=yes 

Если в строке PH2 State надпись established, то все готово, можно заходить по RDP на машину.

P.S. Azure создает машину на английском языке, и если вам не удобно, то вы можете её русифицировать, подробно про это в нашей отдельной статьи.

Конец первой части. 

Настройки беспроводных клиентов

Следующий шаг — настройка сети на всех беспроводных клиентских компьютерах. Здесь мы снова воспользуемся групповыми политиками для автоматизации процесса. Используя тот же GPO, что и раньше, нужно перейти к узлу Computer ConfigurationWindows SettingsSecurity SettingsWireless Network (IEEE 802.1x) Policies.

Нажмите правую кнопку на панели с детальной информацией и выберите Create Wireless Network Policy. Затем следует нажать Next на первой странице мастера Wireless Network Policy Wizard и ввести имя политики, например 802.1x Computer Certificate WLAN Policy. Щелкните Next, выберите Edit policies и нажмите Finish.

В диалоговом окне свойств политики 802.1x Computer Certificate WLAN требуется перейти на закладку Preferred Networks. Здесь нужно ввести Service Set Identifier (SSID) WLAN и настроить параметры аутентификации. Нажмите Add и введите SSID беспроводной сети, например AcmeSecureWLAN.

Теперь следует перейти на закладку IEEE 802.1x. Выберите Smart Card or other certificate с типом EAP расширенного протокола аутентификации и Computer only как тип аутентификации компьютера. Затем необходимо настроить параметры сертификата, нажав Settings.

В диалоговом окне Smart Card or other Certificate Properties выберите Use a certificate on this computer и Use simple certificate selection (Recommended), как показано на экране 1. Эти две настройки заставляют беспроводного клиента выбирать соответствующие сертификаты (один из которых мы только что распространили) из их персонального хранилища сертификатов и использовать эти сертификаты для аутентификации на сервере IAS.

Следует убедиться, что клиенты регистрируются в нужной WLAN, а не в некой сети, выдающей себя за вашу WLAN и развернутой злоумышленниками. Для этого нужно выбрать в соответствующем диалоговом окне параметр Validate server certificate, иначе беспроводной клиент будет доверять любой WLAN, которая имеет такое же название, как и ваша AcmeSecureWLAN.

Затем нужно выбрать в следующем окне CA, который выпустил сертификат для сервера IAS, в данном случае это STO CA. Нажмите OK три раза, чтобы закрыть все диалоговые окна. Теперь, когда компьютер в следующий раз применит этот GPO, он будет иметь конфигурацию беспроводной сети, только что заданную вами.

Немного о методах eap

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

Из википедии:

EAP — фреймворк аутентификации, который часто используется в беспроводных сетях и соединениях точка-точка. Формат был впервые описан в RFC 3748 и обновлён в RFC 5247.
EAP используется для выбора метода аутентификации, передачи ключей и обработки этих ключей подключаемыми модулями называемыми методами EAP. Существует множество методов EAP, как определенных вместе с самим EAP, так и выпущенных отдельными производителями. EAP не определяет канальный уровень, он только определяет формат сообщений. Каждый протокол использующий EAP имеет собственный протокол инкапсуляции сообщений EAP. Сами методы:

• LEAP — проприетарный протокол, разработан CISCO. Найдены уязвимости. В настоящее время не рекомендуется использовать
• EAP-TLS — хорошо поддерживаемый среди вендоров беспроводных соединений. Является безопасным протоколом, поскольку является преемником SSL стандартов. Настройка клиентской достаточно сложна. Нужен клиентский сертификат помимо пароля. Поддерживается во многих системах
• EAP-TTLS — широко поддерживается во многих системах, предлагает хорошую безопасность, используя PKI сертификаты только на сервере аутентификации
• EAP-MD5 — другой открытый стандарт. Предлагает минимальную безопасность. Уязвим, не поддерживает взаимную аутентификацию и генерацию ключей
• EAP-IKEv2 — основан на Internet Key Exchange Protocol version 2. Обеспечивает взаимную аутентификацию и установление сеансового ключа между клиентом и сервером
• PEAP — совместное решение CISCO, Microsoft и RSA Security как открытый стандарт. Широко доступен в продуктах, обеспечивает очень хорошую безопасность. Схож с EAP-TTLS, требуя только сертификат на серверной стороне
• PEAPv0/EAP-MSCHAPv2 — после EAP-TLS, это второй широко используемый стандарт в мире. Используется клиент-серверная взаимосвязь в Microsoft, Cisco, Apple, Linux
• PEAPv1/EAP-GTC — создан Cisco как альтернатива PEAPv0/EAP-MSCHAPv2. Не защищает аутентификационные данные в любом случае. Не поддерживаются в Windows OS
• EAP-FAST — метод, разработанный Cisco для исправления недостатков LEAP. Использует Protected Access Credential (PAC). Полностью не доработан

Из всего этого разнообразия, выбор все таки не велик. От метода аутентификации требовалось: хорошая безопасность, поддержка на всех устройствах (Windows 10, macOS, Linux, Android, iOS) и, собственно, чем проще, тем лучше. Поэтому выбор пал на EAP-TTLS в связке с протоколом PAP.

Возможно возникнет вопрос — Зачем же использовать PAP? ведь он передает пароли в открытом виде?

Получение сертификатов

Теперь необходимо получить сертификат для сервера IAS. Откройте оснастку Certificates на сервере IAS. Когда появится приглашение выбрать учетную запись пользователя, службы или компьютера, следует выбрать компьютер. Когда появится приглашение выбрать между удаленным или локальным, нужно выбрать локальный.

Затем в главном окне оснастки Certificates требуется нажать правую кнопку на папке PersonalCertificates и выбрать All Tasks, Request New Certificate (запрос нового сертификата). Нажмите Next па первой странице мастера Certificate Request Wizard. На следующей странице нужно выбрать Computer как тип шаблона сертификации и нажать Next.

Теперь необходимо получить сертификаты для всех клиентских компьютеров беспроводной сети. Наиболее простой путь — создать сертификационный запрос в Group Policy Object (GPO), который будет применяться ко всем компьютерам, которым требуется доступ к WLAN.

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

В Group Policy Object Editor следует перейти к узлу Computer ConfigurationWindows SettingsSecurity SettingsPublic Key PoliciesAutomatic Certificate Request Settings для установки автоматического запроса сертификатов. Далее необходимо нажать правую кнопку на панели с подробной информацией, выбрать New, Automatic Certificate Request (автоматический запрос сертификата) и нажать Next на первой странице мастера.

На следующей странице следует выбрать шаблон Computer, нажать Next, затем Finish. На экране появится запрос на сертификат типа Computer в папке Automatic Certificate Request Settings. В следующий раз каждый из компьютеров применит этот GPO и будет запрашивать сертификат типа Computer с CA, чтобы сохранить его в своем персональном контейнере сертификатов.

Предисловие

Как говорил послушник нежитиво в игре с русской локализацией в Warcraft 3: «Нужно больше золота». В нашем случае речь пойдет про безопасность, ведь, как всем известно, в корпоративной среде – безопасности много не бывает: «Нужно больше безопасности» и немного треша.

Проверка

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

Компьютер должен подключиться к WLAN автоматически, и в правом нижнем углу экрана появится значок, свидетельствующий о наличии активного беспроводного соединения. Затем нужно попробовать соединиться с сетью с неавторизованного клиента. Важно убедиться, что WLAN блокирует его. Можно воспользоваться анализатором WLAN и удостовериться, что беспроводной трафик действительно зашифрован.

Если возникнут какие-либо проблемы, можно будет диагностировать их при помощи беспроводного клиента, точки доступа либо сервера IAS. На клиенте следует проверить журналы System и Security на предмет наличия в них сообщений об ошибках, относящихся к сертификатам.

Большинство точек доступа имеют функцию ведения журнала, с помощью которой можно отследить неполадки со связью как между клиентом IAS или RADIUS, так и между AP и IAS. На сервере IAS можно просмотреть ошибки в журнале System, который находится в C:windowssystem32logfiles.

Службы сертификатов

Серверу IAS требуется сертификат для представления себя беспроводным клиентам, поэтому необходим сервер сертификатов Certificate Authority (CA) с запущенной либо на Windows 2003, либо на Windows 2000 службой сертификатов. Сервер СА также будет выпускать сертификаты для всех беспроводных клиентов для авторизации их на сервере IAS.

Если домен AD все еще работает на контроллере домена Windows 2000 и в компании пока нет корпоративного сервера СА, то я бы порекомендовал установить службу сертификатов на существующий сервер Windows 2000, как Enterprise Root CA — вместо установки службы сертификатов на сервер IAS Windows 2003.

Устанавливая Certificate Services, мы тем самым создаем инфраструктуру открытых ключей (public key infrastructure, PKI). Для крупной корпоративной инфраструктуры PKI необходимо установить корневой сервер сертификатов, который будет выдавать сертификаты подчиненным СА.

Чтобы избежать компрометации корневого СА, следует держать его отключенным от локальной сети и выдавать сертификаты только с подчиненных СА. Если подчиненный СА будет скомпрометирован, можно будет отозвать его сертификат с корневого СА и опубликовать в сети новый список отозванных сертификатов (certificate revocation list, CRL).

Многоуровневая иерархия СА предохранит инфраструктуру PKI в случае компрометации СА. Однако это может оказаться избыточным для небольших сетей. Для простоты в таких сетях можно ограничиться установкой одного Enterprise Root CA на существующем сервере Windows 2000 и выдавать сертификаты прямо с него.

Откройте приложение Add/Remove Programs, выберите Add/Remove Components. Перед установкой Certificate Services необходимо установить Microsoft IIS, поскольку Certificate Services использует IIS для административных и сертификационных запросов. Установив IIS из Control Panel, следует убедиться, что включена поддержка Active Server Pages (ASP), так как она требуется для работы Certificate Services.

После установки IIS можно установить Certificate Services. Когда появится приглашение выбрать, какой тип СА установить, следует указать Enterprise Root CA. Enterprise в данном случае означает, что Certificate Services будет автоматически интегрирован в AD, что позволит автоматически получать списки пользователей и компьютеров.

Далее от пользователя требуется ввести идентификационную информацию для СА. Я использовал имя STO CA (экран 1). После установки Enterprise Root CA все компьютеры в домене автоматически будут доверять сертификатам, выпущенным СА. Это происходит потому, что, когда компьютеры находят новый корпоративный CA, опубликованный в AD, они автоматически добавляют сертификаты, выпущенные этим СА, в свое хранилище Trusted Root Certification Authorities.

Создание группы ресурсов, вм, пиринг сетей

Для начала заходим в Azure, переходим в вашу подписку и создаём группу ресурсов. Пишем понятное вам название (лучше разделять ваши приложения и сервера на разные группы ресурсов, в зависимости от назначения этих ресурсов. Выбираем удобный вам регион (лучший для России – это Западная Европа).

Наша группа ресурсов готова, можем приступать к разворачиванию виртуальной машины. Заходим в группу ресурсов и нажимаем «Добавить». Выбираем нужную редакцию ОС, после вводим настройки ВМ, а именно местоположение, название ВМ, её размер, имя пользователя и пароль, закрываем доступ к портам и нажимаем «Далее».

Выбираем категорию дисков и добавляем новые, если потребуется, нажимаем «Далее». Создаем новую виртуальную сеть, можете делать любую адресацию, главное, чтобы адресное пространство и подсеть не пересекались, т.е. адресное пространство по /23 маске, а подсеть по /24 маске, убираем общедоступный IP и закрываем порты, нажимаем «Просмотр и создание».

После того, как машина создалась не трогаем её, а идём настраивать пиринг сетей, после уже приступаем к Mikrotik.

Attention!

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

Для настройки пиринга сетей заходим в нашу группу ресурсов, после заходим созданную виртуальную сеть, ищем вкладку «Пиринги» и нажимаем на неё. Мы попали в окно создания пиринга, выбираем вашу подписку, в которой находится нужная вам группа ресурсов, после выбираем сеть, к которой у вас подвязан VPN.

Заключение

На этом завершается вторая часть статьи. Мы научились настраивать беспроводную сеть для работы в режиме чистого WPA с аутентификацией клиентов через EAP-PEAP, с хранением базы аккаунтов во внешней базе (в данном случае — в текстовом файле). Если не хочется связываться с собственным центром сертификации, то информации, приведенной выше, более чем достаточно для построения защищенной беспроводной сети.