Компания UserGate давно планирует выпустить на рынок UserGate Client — продукт для безопасного удаленного подключения пользователей к корпоративной сети. Как заверяет разработчик, нас ждет VPN-клиент, который в некоторых сценариях можно использовать как решение NAC и даже EDR. 

Мы в Nubes (НУБЕС) настроили и протестировали нерелизную версию UserGate Client совместно с Management Center и NGFW (build 7.1.0.1704R). Результатами решили поделиться на Хабре. 

Спойлер: в целом ок, но есть нюансы. 

В этой статье рассмотрим: 

Что это такое

UserGate Client — решение, которое можно одновременно классифицировать как: 

  • бесплатный Remote Access VPN (Virtual Private Network) для нелицензируемого подключения внешних пользователей к корпоративной сети,

  • решение NAC (Network Access Control). В таком режиме VPN-клиент работает только в связке с другими продуктами экосистемы UserGate (сервером управления Management Center, сервером аналитики Log Analyzer и файрволом нового поколения UserGate). В этом сценарии можно контролировать доступ пользователей к сети и вариативно защищать их станции от угроз,

  • инструмент EDR (Endpoint Detection & Response). Вместе с теми же продуктами решение берет на себя мониторинг состояния безопасности рабочих станций, поиск опасных событий и блокирование этих угроз.

Подробности и подходы к архитектуре

Вариант с бесплатным RA VPN предполагает подключение UserGate Client в режиме NGFW. В этом случае функционал UserGate Client сводится к VPN и сбору-отсылке телеметрии. Вся информация собирается на UserGate NGFW, там же применяется политика доступа, комплаенс-проверка устройства (разработчик называет это профилированием) и принятие решения о дальнейшем допуске клиента в локальную сеть.

Однако в режиме NGFW есть важное неудобство — управление продуктом лежит на стороне конечных пользователей. Второй вариант —  администратор постоянно связывается с ними, чтобы изменить настройки в ПО на их устройствах. 

Второй и третий сценарии предполагают подключение UserGate Client в режиме Management Center (сервер управления). Именно на него отправляются данные телеметрии с устройства. 

С помощью Management Center администратор может централизованно управлять настройками UserGate Client на всех подключенных устройствах и без участия пользователей. Причем сами устройства могут находиться как за периметром локальной сети, так и внутри. 

Связка «‎UserGate Client + Management Center» на практике может выглядеть по-разному. На наш взгляд, есть минимум два актуальных подхода к архитектуре. 

1. Management Center находится внутри корпоративной сети, где также размещаются контроллер, Log Analyzer и другие серверы. При этом сервер управления может «‎жить» внутри сети без публикации:

В этом случае UserGate Client будет работать с актуальными политиками, если устройство находится в той же сети. Если пользователь заберет ноутбук с собой домой, то VPN-клиент будет использовать последние сохраненные политики. 

2. Management Center может «‎жить» внутри сети, но с публикацией наружу. В таком режиме UserGate Client будет подключаться к нему напрямую, всегда использовать актуальные политики и отправлять телеметрию.

Схема расположения Management Center в DMZ-сегменте:

Конечно, в теории возможны другие схемы. Можно, например, использовать два сервера Management Center: один будет управлять парком NGFW, другой — UserGate Client :)

Нюанс. В теории можно использовать нативные средства VPN-подключения, которые встроены в популярные ОС (Windows, Android) и работают по IKEv2. Однако в таком сценарии нет раздельного туннелирования. Управлять маршрутами при нативном подключении можно только добавляя либо исключая их из туннеля. Данные для комплаенс-проверок в этом случае тоже не собираются.

Функционал и необходимые лицензии

По необходимым лицензиям и функционалу разница тоже есть: 

UserGate Client + Management Center 

UserGate Client + NGFW

UserGate Client + нативные средства ОС 

VPN

Endpoint лицензия Management Center,

Лицензия пользователя NGFW 

Лицензия пользователя NGFW

Лицензия пользователя NGFW 

IKev1 (Аутентификация L2TP)

+

+

+

IKev2 (Аутентификация по сертификатам)

+

+

+

IKev2 (Аутентификация по логину-паролю с помощью EAP MS-CHAPv2)

+

+

+

IKev2 (MFA)

+

+

-

IKev2 (Раздельное туннелирование)

+

+

-

HIP (комплаенс-проверки)

Endpoint лицензия Management Center, 

NAC подписка Management Center

Лицензия пользователя NGFW,

NAC подписка NGFW

-

Чтобы изучить базовый функционал, мы решили не лезть в сложные схемы и выбрать более простой для нас способ использования. А точнее — протестировать UserGate Client на машинах вне корпоративной сети с подключением к шлюзу безопасности (UserGate NGFW). 

Требования к установке и варианты аутентификации 

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

  • ОС — Windows 10/11,

  • объем оперативной памяти — от 2 Гб, 

  • процессор с тактовой частотой не ниже 2 ГГц,

  • минимум 200 Мб свободного пространства на жестком диске.

Нюанс. Установить UserGate Client можно только на Windows. Версии для Linux пока нет. По нашим данным, сейчас она находится в разработке.

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

По сертификату

Мы установили решение на виртуальную машину (UG Client 1). Она находится на внешнем периметре. При этом есть внешний адрес, который принадлежит интерфейсу шлюза безопасности, и на него нацелено некое доменное имя. В нашем случае это vpn.nubes.lab. На него выписали сертификат, который содержит доменное имя и ip-адрес. 

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

Нюанс. При подключении UserGate Client можно использовать только именные сертификаты SSL. Wildcard-сертификат не поддерживается. Поверьте: лучше не тратить время на попытки заставить работать то, что работать не будет. 

По логину-паролю

Что касается варианта с логином-паролем, то здесь все намного проще. Вводим данные пользователя. Если он состоит в определенных группах пользователей на NGFW, то разрешаем/запрещаем подключение. При положительном решении выделяется соответствующий туннельный адрес. После этого пользователь может пользоваться интернетом и/или локальной сетью. 

В чем принципиальная разница этих двух вариантов? В том, что в режиме NGFW процесс подключения и выбор метода аутентификации лежит на стороне пользователя. А в режиме Management Center созданные администратором политики «‎спускаются» на UserGate Client. Пользователю остается лишь выбрать доступный вариант подключения. 

Процесс настройки 

Разворачиваем стенд

Итак, мы решили выяснить, как работает новое решение VPN IKEv2 и как его настроить средствами UserGate 7.1. Для этого мы собрали тестовый стенд, который выглядит так: 

Подробнее о стенде

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

  1. Кластер UserGate c VPN-серверами в режиме active-passive (по центру схемы).

  2. Внешний периметр, имитирующий публичную зону (Untrusted, розовый блок справа). В ней мы создали две виртуальные машины с VPN-клиентом на борту. Одна работает в режиме «‎UserGate Client + NGFW», другая — «‎UserGate Client + Management Center».

  3. Внутренняя сеть компании (Trusted), в которой находится три машины: 

  • с Active Directory, на ней же будут роли сервера Microsoft RADIUS NPS и центра сертификации Microsoft CA. Последний будет выпускать сертификаты для VPN-серверов и пользователей, 

  • с Management Center, который мы позже опубликуем, чтобы UserGate Client из внешнего периметра мог в нем регистрироваться и получать какие-то централизованно настроенные параметры,

  • с Log Analyzer — это скорее бонусный сервер, на который будут отправляться логи о событиях с удаленных устройств пользователей.

Начинаем с сертификатов SSL

Технически для тестирования можно использовать сертификаты, которые несложно сгенерировать утилитой OpenSSL. Другой вариант — получить их от корпоративного центра сертификации Microsoft СА (Certificate Authority).

Первый вариант мы не рассматриваем совсем, так как его используют редко — сертификатами OpenSSL сложно управлять. Поэтому мы воспользовались вторым способом. 

Сертификат сервера

На машине с Active Directory, которая является контроллером нашего домена nubes.lab, поднимаем роль Microsoft СА (Certificate Authority). Далее выпускаем сертификат по обычному сценарию. 

Единственное, что мы сделали вне стандартной процедуры, — настроили DNS-записи. Добавили записи auth, block, logout, которые ведут на адрес интерфейса UserGate в зоне Trusted. Также создали записи для публикации Management Center (mc), VPN-адреса (vpn). 

Во втором случае видим адрес внешнего интерфейса кластера UserGate — 192.168.0.254, через который мы потом будем публиковать Management Center и выстраивать к нему VPN-туннель с удаленных устройств пользователей из недоверенной зоны:

Для выпуска серверного сертификата нам понадобится шаблон Web Server (для пользовательского сертификата используется шаблон User). 

Что здесь важно учесть? В свойствах шаблона указываем, что он предназначен для цифрового подписания (в поле Purpose стоит Signature and encryption). 

Также видим роль нашего сервера — Server Authentication в поле Intended Purpose.   

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

Нюанс. Если мы откроем в каждом из шаблонов вкладку Security, то увидим, что у аутентифицированных пользователей нет права на запрос сертификата. Чтобы запросить его, мы делегируем эту возможность какому-то аккаунту. Мы, например, разрешили делать запросы любому пользователю из нашего домена (через Active Directory). 

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

А дальше открывается окно, в котором пошагово выбираем Active Directory Enrollment Security — Web Server. Потом указываем все параметры, которые нам необходимы: 

  • в Subject name: Type — Common name (обязательно для сертификата сервера), Value — vpn.nubes.lab (прописываем на свое усмотрение),

  • в Alternative name: Type — DNS, Value — vpn.nubes.lab. Здесь еще дополнительно завели ip-адрес внешнего интерфейса кластера UserGate — 192.168.0.254, о котором мы уже говорили выше. 

Такая настройка позволит нам подключаться как по доменному имени, так и по ip-адресу.  

Затем переходим на вкладку Private Key и указываем, что закрытый ключ для этого сертификата может быть экспортирован: 

Теперь можно нажимать на Enroll. После этого закрываем окно запроса и видим наш сертификат в списке:

Далее его можно экспортировать. Обязательно делаем это с закрытым ключом и придумываем пароль для контейнера.  

Также есть другой вариант — сделать запрос из консоли UserGate NGFW. Можно создать CSR и перенести его на центр сертификации. Далее там подписываем запрос, получаем открытый ключ и импортируем обратно в NGFW.

Сертификат пользователя

В Active Directory у нас есть два пользователя — User1 и User2. Именно с их устройств (машин) мы будем подключаться по VPN к NGFW.

Выпустим сертификаты для User1 и User2. Если у вас под рукой есть машина в домене, то запрос сертификата лучше делать на ней либо через веб-службу регистрации сертификатов. Но мы по