Приветствую читателей в шестой публикации цикла статей, посвященных продукции компании UserGate. В данной статье будет рассматриваться, каким образом можно предоставить доступ для удаленных пользователей к внутренним ресурсам компании средствами UserGate.
Я покажу, как настроить Remote access VPN и SSL VPN. В первом случае UserGate необходимо настроить в качестве сервера, а пользователи со своей стороны должны будут настроить клиент для подключения к UserGate (UserGate поддерживает работу со стандартными клиентами большинства популярных операционных систем). Во втором случае пользователям необходим только браузер, но не ко всем типам ресурсов можно настроить доступ таким образом.
VPN для удаленного доступа клиентов
У UserGate нет собственного клиента VPN, поэтому для создания туннелей используется протокол Layer 2 Tunnelling Protocol (L2TP), а для защиты передаваемых данных - протокол IPSec. Так как протокол L2TP/IPsec поддерживается большинством современных операционных систем это позволяет настроить подключение к UserGate средствами стандартных клиентов. Как я писал выше, UserGate выступает в качестве сервера и для того чтобы настроить его необходимо выполнить следующие действия:
в разделе “Сеть” необходимо разрешить сервис VPN для зоны из которой будут подключаться клиенты, у меня это зона “Untrusted”. Далее в этом же разделе нужно создать зону, в которую помещаются клиенты, подключаемые через VPN, можно использовать уже существующую зону “VPN for remote access”.
Для того чтобы трафик мог ходить из зоны “VPN for remote access” в необходимые нам зоны, создаем в разделе “Политики сети” правило NAT или используем предустановленное правило “NAT from VPN for remote access to Trusted and Untrusted”. Оно разрешает наттирует трафик из зоны “VPN for remote access” в зоны “Trusted” и “Untrusted”.
Следующим шагом будет создания правила межсетевого экрана, для этого в разделе “Политики сети” включаем уже существующее правило “VPN for remote access to Trusted and Untrusted”или создаем свое правило (данное правило должно разрешать прохождения трафика из зоны “VPN for remote access” в зоны “Trusted” и “Untrusted”).
Далее создаем профиль авторизации в разделе “Пользователи и устройства”. Здесь можно использовать тот же профиль авторизации, что используется для авторизации пользователей для получения доступа к сети интернет, но согласно руководству UserGate для авторизации VPN нельзя использовать методы прозрачной авторизации, такие как Kerberos, NTLM, SAML IDP.
VPN поддерживает многофакторную авторизацию, но как видно из скриншота, я не буду настраивать MFA.
Создаем VPN-интерфейс, для этого переходим в раздел “Сеть”, “Интерфейсы”, где по умолчанию уже создан VPN-интерфейс tunnel1, который рекомендовано использовать для Remote access VPN, включаем его.
Приступаем к непосредственной настройке параметров VPN, для этого переходим в раздел “VPN”.
В подразделе “Профили безопасности VPN” уже есть преднастроенный профиль “Remote access VPN profile”, остается открыть его и на вкладке “Общие” изменить общий ключ шифрования (Preshared key). На вкладке “Безопасность” можно выбрать пары алгоритмов аутентификации и шифрования. Алгоритмы используются в порядке, в котором они изображены (сверху вниз) и при установлении соединения используется первая пара, которую поддерживают сервер и клиент. Алгоритмы авторизации и шифрования приведенные в примере подходят для большинства стандартных клиентов VPN. Допускается иметь несколько профилей и использовать их для построения соединений с разными типами клиентов.
Далее переходим в подраздел “Сети VPN”, и либо создаем новую сеть VPN, либо меняем имеющуюся “Remote access VPN network”:
Настроим диапазон IP-адресов, которые будут использованы клиентами. Исключаем из диапазона адреса, которые назначены VPN-интерфейсу, используемые совместно с данной сетью. Также не следует указывать широковещательный адрес.
Можно назначить свои DNS-сервера, которые будут переданы клиенту, или поставить галочку “Использовать системные DNS”, в этом случае клиенту будут назначены DNS-серверы, которые использует UserGate.
На вкладке “Маршруты VPN” указываются маршруты, передаваемые клиенту в виде бесклассовой адресации (CIDR), например, если указать любой, то весь трафик удаленного пользователя будет уходить в туннель, а потом маршрутизироваться как локальный трафик шлюзом. Если же необходимо пускать трафик только в локальную сеть, то указываем здесь эту сеть, а остальной трафик будет идти мимо туннеля.
Создавая серверное правило в подразделе “Серверные правила” мы используем ранее настроенные сеть VPN, интерфейс VPN и профиль VPN, а также выбираем зону “Untrusted”, с которой будут подключаться пользователи VPN, профиль авторизации “User auth profile” и пользователи VPN (у меня это локальная группа “VPN users” и доменный пользователь “test”).
Также если необходимо настроить MFA TOTP (Time-based One-time Password Algorithm), то здесь же производится первоначальная инициализация TOTP-устройства.
Следующим шагом является настройка VPN клиента на пользовательском компьютере. Для Windows 10 настройки показаны на скриншоте внизу, но есть несколько нюансов. Для подключения используется незашифрованный пароль (PAP), соответственно в настройках адаптера указываем данный протокол. Хоть здесь и используется незашифрованный пароль, но передается он по зашифрованному нашим общим ключом каналу. Также для корректной работы в данной системе необходимо изменение параметра реестра HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent в соответствии со статьей.
Для настройки на Linux клиентах, UserGate предлагает установить дополнительные пакеты network-manager-l2tp и network-manager-l2tp-gnome. После этого можно приступить к настройке:
создаем новое подключение VPN выбрав Layer 2 Tunneling Protocol (L2TP).
После этого настраиваем параметры подключения и указываем данные для аутентификации. В настройках PPP оставляем в качестве метода аутентификации PAP и отключаем все виды компрессии. В настройках IPsec указываем Pre-shared key и указываем следующие параметры:
Phase1 algorithms: aes128-sha1-modp1024!
Phase2 algorithm: aes128-sha1!
Веб-портал (SSL VPN)
Веб-портал позволяет предоставить доступ к внутренним веб-ресурсам, терминальным и ssh-серверам компании для удаленных или мобильных пользователей, используя при этом только протокол HTTPS.
Включить веб-портал необходимо в разделе “Настройки” кликнув на соответствующую кнопку.
В открывшемся окне настроек включаем чекбоксом “Включено” портал, задаем имя хоста, указываем порт, который будет использоваться сервисом веб-портала, профиль авторизации, шаблон страницы авторизации, шаблон портала. По желанию можно добавить на странице портала выбор домена AD/LDAP, а также показ CAPTCHA. Если не назначить свой сертификат для создания HTTPS-соединения, то будет использоваться сертификат для роли SSL Captive-портала. Также можно включить авторизацию пользователей по сертификату, но тогда необходимо добавить пользовательский сертификат в список сертификатов UserGate с ролью “Пользовательский сертификат” и сопоставить его с пользователем.
Чтобы разрешить доступ к сервису, нужно для зоны, из которой будут подключаться пользователи поставить, галочку напротив веб-портала.
Собственно теперь, у пользователей есть доступ на портал. Осталось добавить внутренние ресурсы. Для этого необходимо перейти в раздел “Глобальный портал” и в подразделе “Веб-портал” создать записи публикаций внутренних ресурсов.
Нажав кнопку "Добавить" в подразделе "Веб-портал", появляется окно настроек ресурса. Включив ресурс и заполнив название, переходим к полю “URL”, здесь необходимо указывать полный URL, начиная с http://, https://, ftp://, ssh:// или rdp://. Для работы RDP доступа необходимо отключить опцию Network Level Authentication на сервере терминалов. Поле “Домен прямого доступа” не обязательно к заполнению, если указать домен, то пользователь может получить доступ к публикуемому ресурсу, минуя веб-портал. В поле “Иконка” можно выбрать иконку, которая будет отображаться на веб-портале для данной закладки. На вкладке “Вспомогательные URL” указываются URL, необходимые для работы основного URL. На вкладке “Пользователи” выбираем пользователей, у которых будет отображаться ресурс.
Заключение
В данной статье были рассмотрены два метода доступа к ресурсом компании для удаленных пользователей. Также можно предоставить доступ к некоторым ресурсам с помощью DNAT/Порт-форвардинга и Reverse-прокси, но DNAT/Порт-форвардинг уже рассматривался ранее, а Reverse-прокси используется для публикации серверов HTTP/HTTPS только с некоторыми преимуществами (в отличие от DNAT/Порт-форвардинга):
Публикация по HTTPS серверов, работающих по HTTP и наоборот.
Балансировка запросов на ферму веб-серверов.
Возможность ограничения доступа к публикуемым серверам с определенных Useragent.
Возможность подмены доменов и путей публикуемых серверов.
Следует также отметить, что при публикаций внутренних ресурсов с помощью DNAT/Порт-форвардинга, Reverse-прокси и веб-портала порядок применения правил следующий: 1. Правила DNAT. 2. Правила Reverse-прокси. 3. Правила веб-портала.
Следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!