. Удаленный доступ¶
11.2. Настройка серверных правил¶
UserGate позволяет создавать VPN-подключения двух типов:
В таком случае нужно уточнить серверные правила. Уточнение возможно сделать по адресу/зоне источника или по адресу назначения.
По адресу источника. Обычно Site-to-Site VPN настраивается между удалёнными офисами, роутеры которых имеют белые статические IP-адреса. Поэтому в серверном правиле для Site-to-Site VPN-подключения во вкладке Источник необходимо добавить IP-адрес стороны, с которой происходит подключение.
Для уточнения списка IP-адресов источника необходимо:
В разделе Библиотеки –> IP-адреса создать группу.
В созданную группу добавить нужные IP-адреса.
Создать список IP-адресов источников также можно при настройке серверных правил во вкладке Источник с использованием кнопки Создать и добавить новый объект.
Т.к. правила выполняются по очереди сверху вниз, то данное правило необходимо поместить выше правил, в которых в качестве источника указана только зона Untrusted. Благодаря такому уточнению UserGate поймет, что VPN-соединения из зоны Untrusted от указанных IP-адресов должно происходить по правилу Site-to-Site VPN, а все другие соединения, например подключения удалённых сотрудников, будут обрабатываться следующим правилом.
Можно сделать и наоборот: указать адреса, с которых будут происходить подключения удалённых пользователей (Remote Access VPN), если они известны.
По зоне источника. Если для выхода во внешнюю сеть используются несколько интерфейсов, то в свойствах интерфейсов в разделе Сеть –> Интерфейсы во вкладке Общие им необходимо назначить разные зоны.
Далее в свойствах серверных правил во вкладке Источник, необходимо выбрать зону, из которой будет происходить подключение.
По адресу назначения. Если на внешнем интерфейсе настроены 2 и более IP-адресов, то возможно уточнение серверных правил по адресу назначения (вкладка Назначение) – указывается один из IP-адресов интерфейса, по которому должно происходить соединение.
Данное правило необходимо поместить наверх списка правил.
11.3. Настройка Site-to-Site VPN между UserGate и Cisco¶
Site-to-Site VPN (Site-to-Site Virtual Private Network) – один из способов реализации технологии VPN, предназначенный для создания защищённого виртуального туннеля между несколькими частными сетями. Site-to-Site VPN часто используется компаниями, имеющими филиалы в разных городах для объединения их в виртуальную частную сеть.
Для создания постоянного безопасного туннеля используется протокол IPsec.
Рассмотрим создание Site-to-Site VPN подключения между и Cisco.
Адреса:
Настройка оборудования Cisco (с использованием crypto-map).
На маршрутизаторе произведены настройки интерфейсов, есть выход в сеть Интернет.
Настроить политику IKE/ISAKMP (Internet Key Exchange/Internet Security Association and Key Management Protocol), использующуюся для обеспечения защищённого взаимодействия в виртуальных частных сетях. При запуске согласования IKE происходит поиск общей политики на узлах.
crypto isakmp policy 10
encr aes
authentication pre-share
Указать pre-shared key (общего ключа), который будет использоваться при аутентификации:
crypto isakmp key cisco address 1.1.1.2
Указать трафик между сетями, который необходимо шифровать и настроить список доступа для разрешения Site-to-Site VPN.
В данном примере должен шифроваться трафик между сетями 10.10.10.0/24 и 10.10.11.0/24.
ip access-list extended map_vpn
permit ip 10.10.10.0 0.0.0.255 10.10.11.0 0.0.0.255
deny ip any any
Произвести настройку политики для защиты передаваемых данных (transform-set):
crypto ipsec transform-set map_set128 esp-aes esp-sha-hmac
Настроить crypto map (объект, в котором находятся наборы правил, относящиеся к разным туннелям IPsec) и её применение на внешнем интерфейсе GigabitEthernet0/0:
crypto map map1 10 ipsec-isakmp
set peer 1.1.1.2
set transform-set map_set128
match address map_vpn
interface GigabitEthernet0/0
ip address 2.2.2.1 255.255.255.0
duplex auto
speed auto
crypto map map1
Настройка UserGate.
В разделе Сеть –> Зоны разрешить доступ по VPN для зоны, из которой будет происходить соединение.
В разделе Сеть –> Интерфейсы создать или использовать созданный по умолчанию интерфейс VPN for Site-to-Site.
Добавить или использовать существующее правило VPN Site-to-Site to Trusted and Untrusted в разделе Политики сети –> Межсетевой экран для разрешения трафика по VPN Site-to-Site. В свойствах правила можно указать пользователей/группу пользователей, которым будет разрешено подключение, сервис, приложения и время.
Далее представлены свойства созданного по умолчанию правила VPN Site-to-Site to Trusted and Untrusted.
Создать или использовать созданные по умолчанию профили безопасности VPN в разделе VPN –> Профили безопасности VPN. В свойствах профиля указать общий ключ (pre-shared key) и во вкладке Безопасность задать тип авторизации и шифрования, заданные на Cisco.
В разделе VPN –> Клиентские правила необходимо создать правило, выбрав профиль безопасности VPN, указав адрес сервера (IP-адрес интерфейса на роутере Cisco, через который происходит соединение) и протокол VPN: IPsec туннель. Далее необходимо указать разрешённые подсети со стороны UserGate и Cisco.
11.5. Создание отказоустойчивого Site-to-Site VPN-соединения через сети 2-х провайдеров¶
Подробную инструкцию по настройке VPN-соединений и виртуальных маршрутизаторов читайте в UserGate 6. Руководство администратора.
Рассмотрим создание отказоустойчивого VPN-соединения между двумя UserGate с использованием сетей двух провайдеров.
Исходные данные. Создано соединение между 2-мя UserGate: UserGate VPN Server – UserGate, за которым подключена локальная сеть офиса c IP-адресом 10.10.6.0/24 и UserGate VPN Client – UserGate, за которым подключена локальная сеть филиала c IP-адресом 10.10.2.0/24.
Между офисом и филиалом подняты VPN-туннели через разных провайдеров с адресами 172.30.251.0/24 и 172.30.252.0/24. На обоих UserGate были произведены сетевые настройки. На каждом UserGate для выхода в сети провайдеров были указаны шлюзы: на UserGate VPN Server – 10.10.9.9 и 10.10.12.12; на UserGate VPN Client – 10.10.7.7 и 10.10.11.11.
Для установки VPN соединения через сети двух провайдеров на UserGate VPN Server были настроены интерфейсы с IP-адресами 172.30.252.1 (для основного подключения) и 172.30.251.1 (для резервного канала); на UserGate VPN Client – 172.30.252.2 (для основного подключения) и 172.30.251.2 (для резервного канала).
На обоих UserGate в разделе Сеть –> Виртуальные маршрутизаторы были настроены статические маршруты.
Маршруты на UserGate VPN Server.
Выход в сеть 10.10.11.0/24 через интерфейс с адресом 10.10.12.12.
Выход в сеть 10.10.7.0/24 через интерфейс с адресом 10.10.9.9.
Маршруты на UserGate VPN Client.
Выход в сеть 10.10.12.0/24 через интерфейс с адресом 10.10.11.11.
Выход в сеть 10.10.9.0/24 через интерфейс с адресом 10.10.7.7.
На каждом из UserGate в разделе Политики сети –> NAT и маршрутизация были настроены правила типа Policy-based routing.
Правила Policy-based routing, предназначенные для основного канала связи, сценариев не используют. Правило, настроенное на UserGate VPN Server и предназначенное для резервного канала связи, настроено на негативный сценарий с проверкой связи до внешнего IP-адреса основного канала UserGate VPN Client.
Правило, настроенное на UserGate VPN Client и предназначенное для резервного канала связи, настроено на негативный сценарий с проверкой связи до внешнего IP-адреса основного канала UserGate VPN Server. Т.к. правило основного канала не использует сценариев, то правило, настроенное для резервного канала, необходимо поставить выше.
Сценарии можно добавить и настроить в разделе Политики безопасности –> Сценарии. Во вкладке Общие указать, что сценарий должен применяться для всех пользователей в течение 2-х минут. Во вкладке Условия выбрать Проверка состояния и указать следующие параметры.
Создание сценария на UserGate VPN Server:
Переход на резервный канал при разрыве соединения в основном происходит за счёт срабатывания негативного сценария в правиле Policy-based routing резервного канала. Срабатывание сценария произойдет при отрицательном результате ping с UserGate VPN Client до внешнего IP-адреса основного канала UserGate VPN Server или с UserGate VPN Server до внешнего IP-адреса основного канала UserGate VPN Client. Таким образом, в результате выполнения сценария будет добавлен маршрут до сети филиала либо офиса с более высоким приоритетом через шлюз запасного VPN.
После восстановления основного канала связи через 2 минуты сценарий отключается и удаляет созданный ранее маршрут. Запросы начинают проходить через основной канал.
11.6. Настройка VPN-соединения между UserGate и FortiGate¶
В данном разделе рассмотрена настройка VPN-соединения между UserGate и FortiGate. Соединение происходит по следующей схеме:
Адреса:
О настройке VPN на продуктах FortiGate читайте в соответствующей документации. При настройке необходимо:
Установить режим, используемый для создания защищенного канала, Aggressive.
Указать группу Диффи — Хеллмана (Diffie-Hellman group, DH group) 1.
Настройка UserGate.
В разделе Сеть –> Зоны разрешить доступ по VPN для зоны, из которой будет происходить соединение.
В разделе Сеть –> Интерфейсы создать или использовать созданный по умолчанию интерфейс VPN for Site-to-Site.
Во вкладке Сеть настроек VPN-адаптера укажите статический IP-адрес туннельного VPN-интерфейса, используемого в правиле VPN; IP-адрес может быть любым при условии, что он не будет пересекаться с адресами других подсетей.
Добавить или использовать существующее правило VPN Site-to-Site to Trusted and Untrusted в разделе Политики сети –> Межсетевой экран для разрешения трафика по VPN Site-to-Site. В свойствах правила можно указать пользователей/группу пользователей, которым будет разрешено подключение, сервис, приложения и время.
Далее представлены свойства созданного по умолчанию правила VPN Site-to-Site to Trusted and Untrusted.
Создать или использовать созданные по умолчанию профили безопасности VPN в разделе VPN –> Профили безопасности VPN. В свойствах профиля указать общий ключ (pre-shared key) и во вкладке Безопасность задать тип авторизации и шифрования, заданные на FortiGate.
В разделе VPN –> Клиентские правила необходимо создать правило, выбрав профиль безопасности VPN, указав адрес сервера (IP-адрес интерфейса FortiGate, через который происходит соединение) и протокол VPN: IPsec туннель. Далее необходимо указать разрешённые подсети со стороны UserGate и FortiGate.
При подключении FortiGate и UserGate версии 6.1.7 и выше:
На FortiGate отключите опцию Perfect Forward Secrecy (PFS).
Согласуйте настройки безопасности между UserGate и Fortinet (режим IKE, DH-группы, алгоритмы авторизации и шифрования).
На UserGate, по умолчанию, создан профиль безопасности Fortinet compatible VPN profile, определяющий следующие настройки:
11.7. Настройка VPN для удалённого доступа клиентов (Remote access VPN) при использовании двух провайдеров¶
Подробнее о настройке VPN читайте в UserGate 6. Руководство администратора.
Необходимо настроить UserGate для предоставления удалённого доступа клиентам из подсетей 172.30.160.0/30, подключённой к UserGate через port1 с адресом 172.30.160.2, и 172.30.160.4/30, подключённой к UserGate через port2 с адресом 172.30.160.6.
В разделе Сеть –> Шлюзы были добавлены шлюзы с IP-адресами 172.30.160.1 и 172.30.160.5. Шлюз с адресом 172.30.160.1 указан как шлюз по умолчанию.
В разделе Сеть –> Зоны создайте зоны, с которых будет разрешено подключение по VPN, например, ISP-1 – зона для провайдера 1; ISP-2 – зона для провайдера 2. Для обеих зон во вкладке Контроль доступа разрешите сервис VPN.
Перейдите в раздел Сеть –> Интерфейсы, выберите интерфейс port1 и назначьте ему соответствующую первому провайдеру зону, созданную на шаге 1 (в данном примере: зону ISP-1).
Выберите интерфейс port2 и назначьте ему соответствующую второму провайдеру зону, созданную на шаге 1 (в данном примере: зону ISP-2).
Создайте VPN-интерфейс в разделе Сеть –> Интерфейсы. Был использован созданный по умолчанию интерфейс tunnel1, который рекомендуется использовать для Remote access VPN.
Перейдите в раздел VPN –> Сети VPN и добавьте сеть VPN, указав необходимые параметры. Можно, как в данном примере, использовать сеть Remote access VPN network, созданную по умолчанию.
Перейдите в раздел Пользователи –> Профили авторизации и создайте профиль авторизации для пользователей VPN. Допускается использовать тот же профиль авторизации, что используется для авторизации пользователей для получения доступа к сети интернет. Следует учесть, что для авторизации VPN нельзя использовать методы прозрачной авторизации, такие как Kerberos, NTLM, SAML IDP.
Создайте профиль безопасности в разделе VPN –> Профили безопасности VPN. По умолчанию в UserGate создан серверный профиль Remote access VPN profile, задающий необходимые настройки. Данный профиль был использован в данном примере.
При использовании данного профиля необходимо изменить общий ключ шифрования.
Создайте серверное правило в разделе VPN –> Серверные правила. Можно, как в данном примере, использовать правило, созданное по умолчанию Remote access VPN rule. Во вкладке Общие укажите:
Отметьте чекбокс Включено.
Название правила.
Описание (опционально).
Профиль безопасности, созадыннй в пункте 6.
Сеть VPN, созданную в пункте 4.
Профиль авторизации, созданный в пункте 5.
Интерфейс, созданный в пункте 3.
Во вкладке Источник укажите зоны или адреса, с которых разрешено подключение (в данном случае – это зоны ISP-1 и ISP-2).
Во вкладке Пользователи укажите пользователей, которым разрешено подключение по VPN.
Список пользователей, подключённых по VPN, доступен во вкладке Диагностика и мониторинг в разделе Мониторинг –> VPN.
В соответствии с данными настройками, если, запрос на подключение будет приходить на UserGate (port1 или port2), то ответ будет отправлен через порт первого провайдера (port1), т.к. первый провайдер указан в качестве шлюза по умолчанию. В таком случае первый провайдер при наличии защиты от антиспуфинга может отбросить пакет, т.к. он ожидает ответ от 172.30.160.2, а получает от 172.30.160.6. Чтобы исключить возникновение такой ситуации, необходимо настроить правила типа Policy-based routing. Т.к. в данном примере один из шлюзов указан в качестве шлюза по умолчанию, то достаточно настроить одно правило PBR. Если шлюз по умолчанию не обозначен, то необходимо настроить соответствующее правило и для другого провайдера.
Настройте правило для провайдера 2. Для этого перейдите в раздел Политики сети –> NAT и маршрутизация и нажмите Добавить. Во вкладке Общие укажите:
Отметьте чекбокс Включено.
Название правила.
Описание (опционально).
Тип: Policy-based routing.
Шлюз: выберите шлюз провайдера 2 (в примере: ISP-2).
Во вкладке Источник на панели Адрес источника необходимо добавить IP-адрес интерфейса, к которому подключён провайдер 2. IP-адрес интерфейса должен быть добавлен в список IP-адресов, который можно создать в разделе Библиотеки –> IP-адреса или при настройке правила (для этого нажмите Создать и добавить новый объект и укажите название списка и адрес).
Проверка. Для проверки использовалась программа-анализатор Wireshark.
Обратный пакет клиент из подсети 192.168.0.0/24 получает от port1 (172.30.160.2).
Клиент из подсети 192.168.1.0/24 получает обратный пакет от port2 с IP-адресом 172.30.160.6.
11.9. Настройка GRE over IPsec с OSPF¶
В данной статье рассматривается настройка маршрутизации между двумя сетями по протоколу OSPF с использованием зашифрованного канала связи (IPsec) при помощи GRE-туннеля.
Адресация на UserGate-сервере:
Выход в интернет настроен через интерфейс port0 с IP-адресом 192.168.57.100.
Локальная сеть подключена через port1 c IP-адресом 10.10.10.1.
Туннельному интерфейсу GRE назначен адрес 12.0.0.1.
IP-адрес VPN-туннеля – 172.30.255.1.
Адресация на UserGate-клиенте:
Выход в интернет настроен через интерфейс port0 с IP-адресом 192.168.57.200.
Локальная сеть подключена через port1 c IP-адресом 11.11.11.1.
Туннельному интерфейсу GRE назначен адрес 12.0.0.2.
IP-адрес VPN-туннеля – 172.30.255.2.
Как видно из схемы, представленной выше, между 2-мя UserGate настроено Site-to-Site VPN-соединение. Подробнее о настройке Site-to-Site VPN читайте в соответствующем разделе UserGate 6. Руководство администратора.
Далее будет рассмотрена настройка туннеля GRE и OSPF; считается, что между устройствами настроено Site-to-Site VPN-соединение; заданы правила межсетевого экрана, разрешающие трафик.
Настройка GRE-туннеля.
Перейдите в раздел Сеть –> Интерфейсы, нажмите Добавить и выберите Добавить туннель.
Во вкладке Общие укажите:
Порядковый номер туннельного интерфейса.
Описание (опционально).
Зону, которой будет относиться интерфейс (Untrusted).
Перейдите во вкладку Сеть и задайте следующие параметры (в качестве локального и удалённого IP-адресов используются IP-адреса VPN-интерфейсов):
MTU: 1400.
Локальный IP: 172.30.255.1.
Удалённый IP: 172.30.255.2.
Режим: GRE.
IP-адрес интерфейса и маску: 12.0.0.1/24.
На UserGate-клиенте настройка туннельного интерфейса производится аналогично; измените локальный (172.30.255.2) и удалённый (172.30.255.1) IP-адреса и IP-адрес интерфейса (12.0.0.2/24).
Настройка OSPF.
В разделе Сеть –> Зоны в свойствах зоны, к которой относится VPN-интерфейс, во вкладке Контроль доступа разрешите сервис OSPF (по умолчанию VPN for Site-to Site).
Перейдите в раздел Сеть –> Виртуальные маршрутизаторы. Можно использовать виртуальный маршрутизатор, созданный по умолчанию, или добавить новый маршрутизатор. Далее необходимо настроить OSPF-роутер.
Во вкладке OSPF-маршрутизатор:
Во вкладке Интерфейсы укажите интерфейсы, на которых будет работать протокол динамической маршрутизации OSPF. Для выбора доступны только интерфейсы, входящие в данный виртуальный маршрутизатор.
Во вкладке Области создайте область OSPF, указав интерфейсы, на которых она будет доступна.
Проверка. Для проверки анонсов маршрутов перейдите во вкладку Диагностика и мониторинг в раздел Мониторинг –> Маршруты веб-интерфейса UserGate. Задайте фильтр, указав просмотр маршрутов OSPF.
На рисунке ниже представлен анализ трафика, из которого видно, что передача происходит по зашифрованному каналу.
11.10. Настройка GRE over IPsec между UserGate и Cisco¶
В данной статье рассматривается настройка между UserGate и Cisco зашифрованного канала связи (IPsec) с использованием GRE-туннеля.
Адресация на UserGate:
Выход в интернет настроен через интерфейс port0 с IP-адресом 192.168.57.243 (шлюз по умолчанию: 192.168.57.1).
Локальная сеть подключена через port1 c IP-адресом 10.10.2.1.
Адресация на Cisco:
Выход в интернет настроен через интерфейс FastEthernet0/0 с IP-адресом 192.168.57.150 (шлюз по умолчанию: 192.168.57.1).
Локальная сеть подключена через FastEthernet1/0 c IP-адресом 10.10.3.1.
Конфигурация IPsec на Cisco.
Настроить интерфейс Loopback0:
interface Loopback0
ip address 11.11.3.1 255.255.255.0
Настроить политику ISAKMP:
crypto isakmp policy 1
encr aes
authentication pre-share
group 2
Определить Pre-Shared ключ (указать вместо <psk>):
crypto isakmp key <psk> address 192.168.57.243
Создать расширенный ACL:
ip access-list extended <list-name>
permit ip 11.11.3.0 0.0.0.255 11.11.2.0 0.0.0.255
Создать набор преобразований (Transform Set):
crypto ipsec transform-set <TS-name> esp-aes esp-sha-hmac
mode tunnel
Создать Crypto Map:
crypto map <CMAP-name> 10 ipsec-isakmp
set peer 192.168.57.243
set transform-set <TS-name>
match address <list-name>
Применить Crypto Map к интерфейсу FastEthernet0/0:
interface FastEthernet0/0
ip address 192.168.57.150 255.255.255.0
duplex full
crypto map <CMAP-name>
Настройка IPsec на UserGate.
В разделе Сеть –> Интерфейсы веб интерфейса UserGate назначить интерфейсу, к которому подключена локальная сеть, второй (secondary) IP-адрес, например, 11.11.2.1/24 – сеть с IP-адресом 11.11.2.0/24 будет доступна со стороны Cisco.
Произвести настройки для VPN-подключение Site-to-Site.
Перейдите в раздел Сеть –> Интерфейсы и активируйте интерфейс tunnel2. Данный интерфейс находится в зоне VPN for Site-to-Site и имеет IP-адрес 172.30.255.1/24.
Далее необходимо произвести настройку профиля безопасности в разделе VPN –> Профили безопасности VPN. Можно создать новый профиль безопасности или использовать созданный по умолчанию (Client VPN profile).
Во вкладке Общие укажите:
Название профиля безопасности VPN.
Описание (опционально).
IKE версия: IKEv1.
Режим IKE: Основной.
Аутентификация с пиром: Общий ключ.
Общий ключ: общий ключ, указанный при настройке оборудования Cisco – <psk>.
Во вкладке Фаза 1:
Diffie-Hellman группы: Группа 2 Prime 1024 бит.
Алгоритмы авторизации и шифрования: SHA1 – AES128.
Во вкладке Фаза 2:
Алгоритмы авторизации и шифрования: SHA1 – AES128.
Перейдите в раздел VPN –> Клиентские правила. Для подключения можно использовать правило, созданное по умолчанию (Client VPN rule) или создать новое. Укажите:
Настройка IPsec туннеля между UserGate и Cisco завершена, далее настройка GRE.
Настройка GRE-туннеля на Cisco.
Создать туннельный интерфейс и назначить ему адрес из сети 172.30.222.0/24; в качестве адреса источника укажите адрес интерфейса Loopback0 Cisco, в качестве адреса назначения – secondary адрес интерфейса UserGate port1:
interface Tunnel0
ip address 172.30.222.2 255.255.255.0
tunnel source 11.11.3.1
tunnel destination 11.11.2.1
Добавить статический маршрут в сеть 10.10.2.0/24 со шлюзом 172.30.222.1:
ip route 10.10.2.0 255.255.255.0 172.30.222.1
Настройка GRE-туннеля на UserGate.
Перейдите в раздел Сеть –> Интерфейсы нажмите Добавить и выберите Добавить туннель.
Во вкладке Общие укажите:
Порядковый номер туннельного интерфейса.
Описание (опционально).
Зону, которой будет относиться интерфейс: VPN for Site-to-Site.
Перейдите во вкладку Сеть и задайте следующие параметры (в качестве локального и удалённого IP-адресов используются IP-адреса VPN-интерфейсов):
MTU.
Локальный IP: 11.11.2.1 – secondary IP-адрес port1, добавленный ранее.
Удалённый IP: 11.11.3.1 – Loopback0.
Режим: GRE.
IP-адрес интерфейса и маску: 172.30.222.1/24.
Перейдите в раздел Сеть –> Виртуальные маршрутизаторы и настройте статический маршрут в сеть с IP-адресом 10.10.3.0/24 и шлюзом 172.30.222.2.
Создайте правило межсетевого экрана, разрешающее трафик из зоны VPN for Site-to-Site в зону Trusted и обратно.
ПРОВЕРКА.
В случае успешного подключения в разделе VPN –> Клиентские правила отобразится индикатор зелёного цвета.
Во вкладке Диагностика и мониторинг в разделе Мониторинг –> Ping возможна проверка сетевой доступности узлов.
Проверка IPsec-туннеля на UserGate:
PING 11.11.3.1 (11.11.3.1) from 11.11.2.1 : 56(84) bytes of data.
64 bytes from 11.11.3.1: icmp_seq=1 ttl=255 time=9.59 ms
64 bytes from 11.11.3.1: icmp_seq=2 ttl=255 time=4.19 ms
64 bytes from 11.11.3.1: icmp_seq=3 ttl=255 time=8.90 ms
64 bytes from 11.11.3.1: icmp_seq=4 ttl=255 time=2.68 ms
64 bytes from 11.11.3.1: icmp_seq=5 ttl=255 time=7.62 ms
64 bytes from 11.11.3.1: icmp_seq=6 ttl=255 time=2.14 ms
— 11.11.3.1 ping statistics —
6 packets transmitted, 6 received, 0% packet loss, time 5006ms
rtt min/avg/max/mdev = 2.140/5.857/9.596/2.974 ms
Проверка IPSec-туннеля на Cisco:
R1#show crypto session
Crypto session current status
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 192.168.57.243 port 500
IKEv1 SA: local 192.168.57.150/500 remote 192.168.57.243/500 Active
IPSEC FLOW: permit ip 11.11.3.0/255.255.255.0 11.11.2.0/255.255.255.0
Active SAs: 2, origin: crypto map
R1#ping 11.11.2.1 source 11.11.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.11.2.1, timeout is 2 seconds:
Packet sent with a source address of 11.11.3.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/14/24 ms
Проверка сетевой доступности туннельного интерфейса на UserGate:
PING 172.30.222.2 (172.30.222.2) from 172.30.222.1 : 56(84) bytes of data.
64 bytes from 172.30.222.2: icmp_seq=1 ttl=255 time=10.6 ms
64 bytes from 172.30.222.2: icmp_seq=2 ttl=255 time=5.04 ms
64 bytes from 172.30.222.2: icmp_seq=3 ttl=255 time=8.96 ms
64 bytes from 172.30.222.2: icmp_seq=4 ttl=255 time=2.65 ms
64 bytes from 172.30.222.2: icmp_seq=5 ttl=255 time=7.08 ms
64 bytes from 172.30.222.2: icmp_seq=6 ttl=255 time=11.2 ms
— 172.30.222.2 ping statistics —
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 2.652/7.611/11.232/3.055 ms
Проверка доступности локальных шлюзов на UserGate:
PING 10.10.3.1 (10.10.3.1) from 10.10.2.1 : 56(84) bytes of data.
64 bytes from 10.10.3.1: icmp_seq=1 ttl=255 time=16.5 ms
64 bytes from 10.10.3.1: icmp_seq=2 ttl=255 time=10.6 ms
64 bytes from 10.10.3.1: icmp_seq=3 ttl=255 time=5.23 ms
64 bytes from 10.10.3.1: icmp_seq=4 ttl=255 time=9.93 ms
64 bytes from 10.10.3.1: icmp_seq=5 ttl=255 time=3.65 ms
64 bytes from 10.10.3.1: icmp_seq=6 ttl=255 time=7.37 ms
— 10.10.3.1 ping statistics —
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 3.656/8.893/16.546/4.197 ms
Проверка доступности конечных узлов:
C:Usersadmin>ping 10.10.3.3 -S 10.10.2.2
Обмен пакетами с 10.10.3.3 по с 10.10.2.2 с 32 байтами данных:
Ответ от 10.10.3.3: число байт=32 время=17мс TTL=62
Ответ от 10.10.3.3: число байт=32 время=20мс TTL=62
Ответ от 10.10.3.3: число байт=32 время=21мс TTL=62
Ответ от 10.10.3.3: число байт=32 время=21мс TTL=62
Статистика Ping для 10.10.3.3:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 17мсек, Максимальное = 21 мсек, Среднее = 19 мсек
11.11. Настройка IPsec over GRE с OSPF¶
В данной статье рассматривается настройка маршрутизации между двумя сетями по протоколу OSPF с использованием GRE-туннеля, в который будут инкапсулированы зашифрованные пакеты (IPsec).
Адресация на UserGate-сервере:
Выход в интернет настроен через интерфейс port0 с IP-адресом 192.168.57.57.
Локальная сеть подключена через port1 c IP-адресом 10.10.10.1.
Туннельному интерфейсу GRE назначен адрес 12.12.12.1.
IP-адрес VPN-туннеля – 172.30.255.1.
Адресация на UserGate-клиенте:
Выход в интернет настроен через интерфейс port0 с IP-адресом 192.168.57.58.
Локальная сеть подключена через port1 c IP-адресом 11.11.11.1.
Туннельному интерфейсу GRE назначен адрес 12.12.12.2.
IP-адрес VPN-туннеля – 172.30.255.2.
Настройка GRE-туннеля.
Перейдите в раздел Сеть –> Интерфейсы нажмите Добавить и выберите Добавить туннель.
Во вкладке Общие укажите:
Порядковый номер туннельного интерфейса.
Описание (опционально).
Зону, которой будет относиться интерфейс (Untrusted).
Перейдите во вкладку Сеть и задайте следующие параметры (в качестве локального и удалённого IP-адресов используются IP-адреса внешних интерфейсов UserGate):
MTU: 1500.
Локальный IP: 192.168.57.57.
Удалённый IP: 192.168.57.58.
Режим: GRE.
IP-адрес интерфейса и маску: 12.12.12.1/24.
На UserGate-клиенте настройка туннельного интерфейса производится аналогично; измените локальный (192.168.57.58) и удалённый (192.168.57.57) IP-адреса и IP-адрес интерфейса (12.12.12.2/24).
Далее необходимо настроить Site-to-Site VPN-соединение между двумя UserGate. Подробнее о настройке читайте в соответствующем разделе UserGate 6. Руководство администратора.
Настройка OSPF.
В разделе Сеть –> Зоны в свойствах зоны, к которой относится VPN-интерфейс, во вкладке Контроль доступа разрешите сервис OSPF (по умолчанию VPN for Site-to Site).
Перейдите в раздел Сеть –> Виртуальные маршрутизаторы. Можно использовать виртуальный маршрутизатор, созданный по умолчанию, или добавить новый маршрутизатор. Далее необходимо настроить OSPF-роутер.
Во вкладке OSPF-маршрутизатор:
Во вкладке Интерфейсы укажите интерфейсы, на которых будет работать протокол динамической маршрутизации OSPF. Интерфейсы должны быть предварительно добавлены в маршрутизатор по умолчанию; интерфейс может принадлежать только одному виртуальному маршрутизатору.
Во вкладке Области создайте область OSPF, указав интерфейсы, на которых она будет доступна.
На этом настройка IPsec over GRE с использованием протокола динамической маршрутизации OSPF окончена.
Авторизация¶
3.1. Авторизация с помощью Kerberos¶
Авторизация Kerberos позволяет прозрачно (без запроса имени пользователя и его пароля) авторизовать пользователей домена Active Directory. При авторизации через Kerberos сервер UserGate работает с контроллерами домена. Контроллеры домена выполняют проверку пользователя, который получает доступ в интернет.
Для настройки авторизации Kerberos необходимо выполнить следующие действия (для настройки авторизации Kerberos предварительно был создан домен test1.net).
Создать DNS-записи для сервера UserGate. Необходимо создавать записи типа A, не создавайте записи типа CNAME. В качестве IP-адреса необходимо указать IP-адрес интерфейса UserGate, подключенного в зону Trusted.
Создать пользователя в домене AD, например kerb@test1.net с параметром учётной записи password never expires (срок действия пароля не ограничен). Установить пароль пользователю, например, kerb.
Создать keytab файл на контроллере домена. Для этого необходимо запустить командную строку от имени администратора и выполнить следующую команду.
ktpass.exe /princ HTTP/auth.test1.net@TEST1.NET /mapuser kerb@TEST1.NET /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass * /out C:utm.keytab
Далее введите пароль пользователя kerb. Keytab файл создан (в корне диска С:).
В данном примере:
После успешного создания keytab файла Имя входа пользователя (Userlogon name) изменилось (можно проверить в свойствах пользователя kerb во вкладке Учётная запись).
Произвести настройку UserGate.
На UserGate-сервере предварительно произведены сетевые настройки, протокол QUIC запрещён (можно запретить, настроив правило межсетевого экрана в разделе Политики сети –> Межсетевой экран), включено правило дешифрования всех неизвестных пользователей (раздел Политики безопасности –> Инспектирование SSL: можно использовать правило, созданное по умолчанию Decrypt all for unknown users). Это необходимо для авторизации пользователей, которые делают свои запросы по зашифрованному протоколу HTTPS.
Вариант 1. В разделе Сеть –> DNS –> Системные DNS-серверы укажите IP-адреса контроллеров домена (в данном примере 10.0.0.20).
Настройте синхронизацию времени с контроллером домена: в разделе UserGate –> Настройки –> Настройка времени сервера необходимо изменить Основной NTP-сервер. Укажите IP-адрес контроллера домена. В качестве запасного – опционально – можно указать IP-адрес другого контроллера домена.
Далее перейдите к пункту 5.
Вариант 2. В разделе Сеть –> DNS –> Системные DNS-серверы укажите IP-адреса DNS-серверов интернета.
В разделе Сеть –> DNS –> DNS-прокси –> Правила DNS нажмите на кнопку Добавить и укажите домен и IP-адреса контроллеров домена.
Настройте синхронизацию времени в разделе UserGate –> Настройки –> Настройка времени сервера. Измените основной и запасной NTP-серверы (поля Основной NTP-сервер и Запасной NTP-сервер).
Перейдите в раздел Сеть –> Зоны и в настройках зоны внутренней подсети организации (по умолчанию, зона Trusted) во вкладке Контроль доступа разрешите сервисы DNS и NTP сервис.
На серверах контроллеров AD укажите UserGate в качестве корневого сервера DNS и основного сервера NTP.
Изменить адрес домена Auth Captive-портала.
В разделе UserGate –> Настройки –> Модули измените названия доменов Auth/Logout Captive-портала и страницы блокировки на доменные имена, созданные в пункте 1.
Создать LDAP – коннектор для получения информации о пользователях и группах Active Directory и загрузить keytab – файл.
Для этого перейдите в раздел Пользователи и устройства –> Серверы авторизации и добавьте LDAP коннектор, нажав на кнопку Добавить и выбрав Добавить LDAP коннектор.
В свойствах коннектора LDAP во вкладке Настройки необходимо указать:
Во вкладке Домены LDAP свойств коннектора добавьте доменное имя LDAP.
Далее загрузите созданный в пункте 3 keytab файл во вкладке Kerberos keytab.
После внесения настроек нажмите на кнопку Проверить соединение. В случае, если настройки внесены верно, то вы увидите следующее сообщение.
Сохраните настройки LDAP коннектора.
Создать профиль авторизации Kerberos.
В разделе Пользователи и устройства –> Профили авторизации создайте профиль авторизации Kerberos и укажите следующие данные.
Во вкладке Общие необходимо указать Название: произвольное название профиля авторизации (допустим kerberos auth).
Во вкладке Методы аутентификации добавьте Аутентификация Kerberos.
Сохраните настройки профиля авторизации, нажав на кнопку Сохранить.
Создать Captive-профиль.
Создайте Captive-профиль во вкладке Пользователи и устройства –> Captive-профили и заполните необходимые данные и сохраните. Во вкладке Общие укажите:
Название Captive — профиля.
Профиль авторизации, созданный ранее.
Создать правило Captive-портала для авторизации Kerberos.
Добавьте правило Captive-портала для авторизации Kerberos в разделе Пользователи и устройства –> Captive-портал. В свойствах правила Captive-портала во вкладке Общие необходимо указать:
Название правила.
Captive-профиль.
Разрешить доступ к сервису HTTP(S) для зоны.
В разделе Сеть –>Зоны на вкладке Контроль доступа разрешите доступ к сервису HTTP(S)-прокси для зоны, к которой подключены пользователи, использующие авторизацию Kerberos.
Произвести настройки на компьютере пользователя.
Войдите в систему под учётной записью доменного пользователя. Для корректной работы с HTTPS-сайтами установите сертификат, используемый для дешифрования трафика, в доверенный сертификаты.
Стандартный режим авторизации Kerberos.
Для работы в стандартном режиме авторизации Kerberos укажите обязательное использование прокси сервера в виде FQDN-имени UserGate. Перейдите Панель управления–> Cеть и Интернет –> Свойства браузера–>Подключения–> Настройка сети–>Прокси-сервер и укажите FQDN и порт интерфейса UserGate, к которому будут подключены пользователи.
Прозрачный режим авторизации Kerberos.
Для работы в прозрачном режиме авторизации перейдите в Панель управления –> Cеть и Интернет –> Свойства браузера –> Безопасность –> Интернет. В разделе Уровень безопасности для этой зоны нажмите кнопку Другой и в параметрах безопасности в разделе Проверка подлинности пользователя –> Вход установите Автоматический вход в сеть с текущим именем пользователя и паролем.
Проверка авторизации Kerberos.
Для проверки работы авторизации Kerberos в браузере пользователя перейдите на сайт, например, ya.ru. Далее на UserGate перейдите во вкладку Журналы и отчёты в раздел Журналы –> Журнал веб-доступа. В журнале видно, что запрос происходит от доменного пользователя.
3.2. Авторизация с помощью NTLM¶
Авторизация NTLM позволяет прозрачно (без запроса имени пользователя и его пароля) авторизовать пользователей домена Active Directory. При авторизации с помощью NTLM сервер UserGate работает с контроллерами домена, выполняющими проверку пользователя, который получает доступ в интернет.
На UserGate-сервере предварительно произведены сетевые настройки, протокол QUIC запрещён (можно запретить, настроив правило межсетевого экрана в разделе Политики сети –> Межсетевой экран), включено правило дешифрования всех неизвестных пользователей (раздел Политики безопасности –> Инспектирование SSL: можно использовать правило, созданное по умолчанию Decrypt all for unknown users). Это необходимо для авторизации пользователей, которые делают свои запросы по зашифрованному протоколу HTTPS.
Для настройки авторизации NTLM необходимо выполнить следующие действия (для настройки авторизации NTLM предварительно был создан домен test1.net).
Создать DNS-записи для сервера UserGate. Необходимо создавать записи типа A, не создавайте записи типа CNAME. В качестве IP-адреса необходимо указать IP-адрес интерфейса UserGate, подключенного в зону Trusted.
Произвести настройку UserGate.
Вариант 1. В разделе Сеть –> DNS –> Системные DNS-серверы укажите IP-адреса контроллеров домена (в данном примере 10.0.0.20).
Настройте синхронизацию времени с контроллером домена: в разделе UserGate –> Настройки –> Настройка времени сервера необходимо изменить Основной NTP-сервер. Укажите IP-адрес контроллера домена. В качестве запасного – опционально – можно указать IP-адрес другого контроллера домена.
Далее перейдите к пункту 3.
Вариант 2. В разделе Сеть –> DNS –> Системные DNS-серверы укажите IP-адреса DNS-серверов интернета.
В разделе Сеть –> DNS –> DNS-прокси –> Правила DNS нажмите на кнопку Добавить и укажите домен и IP-адреса контроллеров домена.
Настройте синхронизацию времени в разделе UserGate –> Настройки –> Настройка времени сервера. Измените основной и запасной NTP-серверы (поля Основной NTP-сервер и Запасной NTP-сервер).
Перейдите в раздел Сеть –> Зоны и в настройках зоны внутренней подсети организации (по умолчанию, зона Trusted) во вкладке Контроль доступа разрешите сервисы DNS и NTP сервис.
На серверах контроллеров AD укажите UserGate в качестве корневого сервера DNS и основного сервера NTP.
Изменить адрес домена Auth Captive-портала.
В разделе UserGate –> Настройки –> Модули измените названия доменов Auth/Logout Captive-портала и страницы блокировки на доменные имена, созданные в пункте 1.
Создать LDAP – коннектор для получения информации о пользователях и группах Active Directory.
Перейдите в раздел Пользователи и устройства –> Серверы авторизации, нажмите кнопку Добавить и выберите Добавить LDAP коннектор.
Настройте коннектор LDAP:
В свойствах коннектора LDAP во вкладке Настройки необходимо указать:
Добавьте доменное имя LDAP во вкладке Домены LDAP.
После внесения настроек нажмем на кнопку Проверить соединение. Если настройки внесены верно, получим сообщение об успехе.
Во вкладке Kerberos keytab можно загрузить keytab-файл. Загрузка keytab-файла не является обязательной, но наличие keytab-файла желательно, т.к. keytab снимает значительную часть нагрузки с AD и ускоряет его работу.
Сохраните настройки LDAP коннектора, нажав на кнопку Сохранить.
Создать NTLM – сервер авторизации.
В разделе Пользователи и устройства –> Серверы авторизации создайте NTLM-сервер (Добавить –> Добавить NTLM-сервер). Укажите следующие данные:
Название сервера авторизации.
Описание (опционально).
IP-адрес контроллера домена.
Домен Windows: укажите IP-адрес контроллера домена.
Сохраните настройки NTLM-сервера нажатием кнопки Сохранить.
Создать профиль авторизации для NTLM-сервера.
Создайте профиль авторизации в разделе Пользователи и устройства –> Профили авторизации.
Укажите:
Название профиля авторизации.
Метод аутентификации в одноимённой вкладке.
Сохраните настройки профиля авторизации.
Создать Captive-профиль.
В разделе Пользователи и устройства –> Captive-профили создайте Captive-профиль. Укажите:
Название captive-профиля.
Профиль авторизации: выберете ранее созданный NTLM профиль.
Сохраните настройки Captive-профиля.
Создать правило Captive-портала для NTLM авторизации.
В разделе Пользователи и устройства –> Captive-портал нажмите кнопку Добавить и укажите:
Название правила captive-портала.
Captive-профиль, созданный ранее.
Произведите настройки на компьютере пользователя.
Настройка прокси-сервера для авторизации в стандартном режиме.
Перейдите Панель управления–> Cеть и Интернет –> Свойства браузера–>Подключения–> Настройка сети–>Прокси-сервер и укажите IP-адрес и порт интерфейса UserGate, к которому будут подключены пользователи.
Настройка авторизации в прозрачном режиме.
Для работы в прозрачном режиме авторизации перейдите в Панель управления –> Cеть и Интернет –> Свойства браузера –> Безопасность –> Интернет. В разделе Уровень безопасности для этой зоны нажмите кнопку Другой и в параметрах безопасности в разделе Проверка подлинности пользователя –> Вход установите Автоматический вход в сеть с текущим именем пользователя и паролем.
Перейдите в Панель управления –> Cеть и Интернет –> Свойства браузера –> Дополнительно. Отметьте чекбокс Разрешить встроенную проверку подлинности Windows.
Проверка авторизации NTLM.
Для проверки работы NTLM-авторизации в браузере пользователя перейдите на сайт, например, ya.ru. Далее на UserGate перейдите во вкладку Журналы и отчёты в раздел Журналы –> Журнал веб-доступа. В журнале видно, что запрос происходит от доменного пользователя.
3.3. Мультифакторная аутентификация с подтверждением через email¶
Для отправки почтового сообщения у каждого пользователя должен быть указан адрес электронной почты в его локальной учетной записи в UserGate или в доменной учетной записи в Active Directory.
Для локального пользователя UserGate необходимо перейти в свойства пользователя в разделе Пользователи и устройства–> Пользователи и указать почтовые адреса в одноимённой вкладке.
Для доменной учетной записи добавить адрес электронной почты необходимо в свойствах пользователя во вкладке Общие.
Создать профиль оповещения по электронной почте.
Для создания профиля оповещения перейдите в раздел Библиотеки –> Профили оповещений и выберите Добавить –> Добавить профиль оповещения SMTP. Далее укажите необходимы данные.
Для проверки нажмите на кнопку Проверить профиль и отправьте проверочное письмо, предварительно заполнив поля Отправитель, Получатель, Тема и Тело письма. Сохраните настройки, если проверочное письмо было получено адресатом.
Использование мультифакторной авторизации с подтверждением через email на примере авторизации пользователей домена AD.
Добавить сервер авторизации.
Перейдите в раздел Пользователи и устройства –> Серверы авторизации и добавьте LDAP коннектор (нажмите Добавить –> Добавить LDAP коннектор).
В свойствах коннектора LDAP укажите необходимые данные.
Во вкладке Настройки:
Во вкладке Домены LDAP укажите доменное имя LDAP.
Во вкладке Kerberos keytab можно загрузить keytab-файл. Загрузка keytab-файла не является обязательной, но наличие keytab-файла желательно, т.к. keytab снимает значительную часть нагрузки с AD и ускоряет его работу.
После внесения настроек нажмите на кнопку Проверитьсоединение. Если настройки внесены верно, то появится следующее сообщение:
Сохраните настройки LDAP коннектора.
Создать профиль для мультифакторной аутентификации.
Перейдите в раздел Пользователи и устройства –> Профили MFA, нажатием на кнопку Добавить –> MFA через email перейдите в свойства профиля MFA и укажите следующую информацию.
Название профиля MFA.
Профиль отправки MFA: ранее созданный профиль оповещения по электронной почте.
От: адрес электронной почты пользователя, указанного в профиле оповещения MFA.
Тема письма.
Содержимое письма.
Сохраните настройки профиля MFA нажатием кнопки Сохранить.
Создать профиль авторизации.
Перейдите в раздел Пользователи и устройства –> Профили авторизации и добавьте профиль авторизации. В свойствах профиля укажите необходимую информацию.
Название профиля авторизации.
Созданный ранее Профиль MFA.
Во вкладке Методы аутентификации укажите ранее созданный LDAP коннектор: Добавить –> Сервер LDAP/Active Directory: AD Connector и сохраните настройки профиля авторизации.
Мультифакторная авторизация возможна только с методами аутентификации, позволяющими ввести пользователю одноразовый пароль, то есть только те, где пользователь явно вводит свои учетные данные в веб-форму страницы авторизации. В связи с этим, мультифакторная авторизация невозможна для методов аутентификации Kerberos и NTLM.
Создать Captive-профиль.
Для создания профиля перейдите в раздел Пользователи и устройства –> Captive-профили, нажмем на кнопку Добавить. Укажите необходимые данные:
Название captive-профиля.
Выберите Шаблон страницы авторизации.
В поле Метод идентификации укажите Запоминать IP-адрес.
Ранее созданный Профиль авторизации.
Если для авторизации пользователей используется LDAP коннектор, то можно активировать функцию «Предлагать выбор домена AD/LDAP на странице авторизации».
Сохраните настройки captive-профиля.
Создать правило Captive-портала.
Для создания правила captive-портала перейдите в раздел Пользователи и устройства –> Captive-портал и нажмите кнопку Добавить. В свойствах правила captive-портала укажите следующую информацию:
Название captive-портала.
Ранее созданный captive-профиль.
Вкладки Источник, Назначение, Категории, URL, Время, можно настраивать для задания дополнительных условий выполнения правила. Правила применяются сверху вниз в том порядке, в котором совпали условия, указанные в правиле. Для срабатывания правила необходимо, чтобы совпали все условия, указанные в параметрах правила.
Настроить DNS для доменов auth.captive и logout.captive.
Служебные доменные имена auth.captive и logout.captive используется UserGate для авторизации пользователей. Если клиенты используют в качестве DNS-сервера сервер UserGate, то ничего делать не надо. В противном случае необходимо прописать в качестве IP-адреса для этих доменов IP-адрес интерфейса сервера UserGate, который подключен в клиентскую сеть.
Проверить работу мультифакторной авторизации.
В браузере пользователя перейдите на сайт, например, ya.ru: отобразится страница авторизации captive-портала:
После ввода логина и пароля появится окно для ввода дополнительного кода аутентификации, который придет на электронную почту, указанную в свойстве профиля пользователя:
Введите полученный код.
После ввода кода в окне авторизации, откроется запрошенный сайт – ya.ru
3.4. Мультифакторная аутентификация с подтверждением через одноразовые временные пароли (TOTP)¶
В данном пункте рассмотрена настройка двухфакторной аутентификации с подтверждением (второй фактор аутентификации) кодом TOTP. В качестве примера будет произведена настройка авторизации пользователей домена Active Directory.
Добавить сервер авторизации.
Перейдите в раздел Пользователи и устройства –> Серверы авторизации и добавьте LDAP коннектор (нажмите Добавить –> Добавить LDAP коннектор).
В свойствах коннектора LDAP укажите необходимые данные.
Во вкладке Настройки:
Во вкладке Домены LDAP укажите доменное имя LDAP.
Во вкладке Kerberos keytab можно загрузить keytab-файл. Загрузка keytab-файла не является обязательной, но наличие keytab-файла желательно, т.к. keytab снимает значительную часть нагрузки с AD и ускоряет его работу.
После внесения настроек нажмите на кнопку Проверитьсоединение. Если настройки внесены верно, то появится следующее сообщение:
Сохраните настройки LDAP коннектора.
Создать профиль для мультифакторной аутентификации.
Для этого перейдите в раздел Пользователи и устройства –> Профили MFA и, нажав кнопку Добавить, выберете MFA через TOTP. Укажите необходимые данные и сохраните профиль.
Название профиля MFA.
Инициализация TOTP:выберите Показать ключ на странице captive-портала.
Показывать QR-код: отметьте чекбокс для возможности сканирования кода.
Создать профиль авторизации.
Для создания профиля авторизации перейдите в раздел Пользователи и устройства –> Профили авторизации. Во вкладке Общие необходимо указать:
Название профиля авторизации.
Созданный ранее Профиль MFA.
Добавьте ранее созданный LDAP коннектор во вкладке Методы аутентификации и сохраните настройки.
Создать профиль для Captive-портала.
Мультифакторная авторизация возможна только с методами аутентификации, позволяющими ввести пользователю одноразовый пароль, то есть только те, где пользователь явно вводит свои учетные данные в веб-форму страницы авторизации. В связи с этим, мультифакторная авторизация невозможна для методов аутентификации kerberos и NTLM.
Для создания captive-профиля перейдите в раздел Пользователи и устройства –> Captive-профили, нажмите на кнопку Добавить и в свойствах captive-профиля укажите следующие данные:
Если для авторизации пользователей используется LDAP коннектор, можно отметить чекбокс «Предлагать выбор домена AD/LDAP на странице авторизации». После внесения необходимых настроек сохраните captive-профиль нажатием на кнопку Сохранить.
Создать правило Captive-портала.
Перейдите в раздел Пользователи и устройства –> Captive-портал и создайте правило captive-портала, указав необходимую данные:
Название правила captive-портала.
Созданный ранее Captive-профиль.
Вкладки Источник, Назначение, Категории, URL, Время можно настраивать для задания дополнительных условий выполнения правила. Правила применяются сверху вниз в том порядке, в котором совпали условия, указанные в правиле. Для срабатывания правила необходимо, чтобы совпали все условия, указанные в параметрах правила.
Сохраните правило captive-портала.
Настроить DNS для доменов auth.captive и logout.captive.
Служебные доменные имена auth.captive и logout.captive используется UserGate для авторизации пользователей. Если клиенты используют в качестве DNS-сервера сервер UserGate, то ничего делать не надо. В противном случае необходимо прописать в качестве IP-адреса для этих доменов IP-адрес интерфейса сервера UserGate, который подключен в клиентскую сеть.
Проверить работу мультифакторной авторизации.
В браузере пользователя перейдем на сайт, например, ya.ru: откроется страница авторизации captive-портала:
После ввода логина и пароля появится окно для ввода дополнительного кода аутентификации:
Для получения кода необходимо установить специальное приложение или расширение в браузер, которое умеет генерировать код на основе алгоритма TOTP. Для примера было установлено расширение Аутентификатор в браузер Google Chrome:
Добавьте в расширение ключ инициализации TOTP:
Расширение браузера Chrome Аутентификатор выдаст временный код для авторизации на портале. Укажите его в поле One Time Password. После его ввода, откроется запрошенный сайт ya.ru
Для повторной авторизации на Captive-портале необходимо снова воспользоваться расширением Аутентификатор, которое сгенерирует новый код TOTP.
3.5. Авторизация пользователей SSL VPN портала по сертификату¶
Дополнительно к авторизации пользователей SSL VPN портала по логину и паролю существует возможность настроить “прозрачную” авторизацию этих пользователей по SSL сертификату.
Для этого, в дополнение к базовой настройке SSL VPN портала, необходимо проделать следующие шаги:
Для каждого пользователя выпустить SSL сертификат, в котором указаны следующие параметры применения ключа – Digital Signature, Key Encipherment и Data Encipherment.
Если для выпуска сертификата используется приложение XCA, то при создании запроса на сертификат достаточно указать шаблон TLS_client (вкладка Первоисточник поле Шаблон для нового сертификата).
Удостоверяющий центр, которым подписан сертификат пользователя не имеет значения. В том числе работают и самоподписанные сертификаты.
Импортировать в браузер каждого пользователя, выписанный для него сертификат вместе с закрытым ключом (обычно, формат файла .p12).
Во вкладке UserGate –> Сертификаты импортировать в UserGate сертификаты всех пользователей (без закрытого ключа, обычно, формат файла .cer).
Для каждого импортированного ключа необходимо указать роль Пользовательский сертификат и пользователя, для которого был создан сертификат (возможно указывать как локальных пользователей, так и пользователей из LDAP).
В настройках SSL VPN портала произвести следующие изменения (UserGate –> Настройки –> Веб-портал):
3.6. Установка и настройка агента терминального сервера UserGate¶
Для пользователей, работающих на операционной системе Windows, существует еще один способ идентификации – использование специального агента авторизации. Агент представляет собой сервис, который передает на сервер UserGate информацию о пользователе, его имя и IP-адрес, соответственно, UserGate будет однозначно определять все сетевые подключения данного пользователя. При использовании агента авторизации идентификация другими методами не требуется.
3.6.1. Дистрибутив агента терминального сервера UserGate¶
Файлы дистрибутива агента терминального сервера UserGate доступны в личном кабинете клиента UserGate по адресу https://my.usergate.com, в разделе Все загрузки.
Перейдите в раздел загрузок и найдите ссылку Скачать агент авторизации для терминального сервера. В скачанном архиве находятся две версии ПО – для 32-битных систем и для 64-битных. Выберите для установки подходящую вам версию дистрибутива.
Программное обеспечение устанавливается в каталог “%ALLUSERSPROFILE%EntensysTerminal Server Agent”.
В каталоге, вы можете найти два исполняемых файла – tsagent.exe и config.exe. Файл tsagent.exe регистрируется в системе, в качестве службы, которую можно наблюдать в оснастке управления службами. В описании службы сказано “UserGate Terminal Server Agent”. Агент не отправляет на устройство UserGate никаких пользовательских данных, кроме информации об имени пользователя, которые ассоциируются на устройстве с сетевыми коммуникациями, производимыми в рамках терминальных сессий.
Используя файл config.exe, можно перенастроить параметры соединения с сервером UserGate, заданные при первоначальной установке ПО, а также параметры периодичности отправки данных.
Конфигурации подключения к серверу UserGate хранятся в файле %ALLUSERSPROFILE%EntensysTerminal Server Agenttsagent.cfg. В этом же каталоге хранится лог файл работы сервиса. При диагностике проблем с работой сервиса рекомендуется сопровождать обращения в техническую поддержку данным файлом, также самостоятельно можно диагностировать возможные причины проблем в работе ПО.
3.6.3. Установка агента терминального сервера UserGate¶
Агентское ПО может быть установлено как в ручном режиме, так и при помощи различных средств автоматизации.
Для установки ПО в ручном режиме, запустите установочный файл, подходящий для вашей системы. Во время установки запустится мастер настройки агента, который предложит ввести настройки подключения к устройству UserGate.
Минимальные достаточные для установки агента данные составляют IP-адрес устройства и пароль для подключения к устройству.
Так как ПО распространяется в виде MSI пакета, его возможно установить и сконфигурировать в автоматическом режиме. Например, ПО можно распространить, применяя групповые политики Microsoft Active Directory.
Так же ПО можно установить и сконфигурировать, запустив утилиту Windows Installer msexec.exe.
Пример команды для скрытой автоматической установки ПО:
msiexec.exe /log install.log -i \file-serverTerminalServerAgent-x64.msi /quiet SERVER_ADDRESS=[ip-address] UTM_PASSWORD=[password]
Ключ /log является опциональным и позволяет создать журнал установки процесса установки ПО и убедиться, что установка прошла корректно.
Ключ /quiet скрывает графический интерфейс установщика ПО. Иными словами установка ПО произойдет в скрытом режиме.
Далее указываются два обязательных параметра конфигурации в формате КЛЮЧ=ЗНАЧЕНИЕ. Таким образом мы сообщаем установщику IP-адрес устройства UserGate и регистрационный пароль.
После успешной установки и регистрации ПО, в административном интерфейсе UserGate появится запись о зарегистрированном агенте. Обратите внимание, агент находится в отключенном состоянии. Необходимо активировать подключение со стороны устройства:
После установки, регистрации и активации клиента, может понадобиться некоторое время (для синхронизации данных), прежде чем в журналах отобразится информация о пользователях, работающих через терминального сервера.
Для версий UserGate 6.1.5 и выше. В разделе Пользователи и устройства –> Терминальные серверы необходимо добавить агентов терминального сервера, указав имя и адрес хоста. После получения данных с указанного в настройках хоста и совпадении пароля авторизация пользователей будет включена автоматически.
При обновлении версии UserGate агенты терминальных серверов, которые ранее отображались в веб-консоли, будут продолжать работать.
3.7. Настройка и проверка аутентификации reverse-прокси по пользовательскому сертификату¶
Reverse proxy (обратный прокси-сервер) – тип прокси сервера, который ретранслирует запросы клиентов из внешней сети на один или не несколько серверов, логически расположенных во внутренней сети. В основном используется администраторами серверов для обеспечения балансировки и высокой доступности.
С настройкой reverse-прокси на UserGate можно ознакомиться в UserGate 6. Руководство администратора.
В UserGate реализована возможность авторизации по сертификату: требование предъявления пользовательского сертификата браузером. Алгоритм генерации сертификатов рассмотрен в разделах Создание сертификата на Linux и Создание сертификата на Windows. После того, как сертификаты сгенерированы необходимо выполнить следующее.
Импортировать файл auth-certiifcates/basefiles/Admin.crt в UserGate и назначить ему статус пользовательского сертификата (инструкцию по импорту сертификата читайте в Usergate 6. Руководство администратора). Сертификат будет назначен пользователю, который может быть добавлен локально или получен из LDAP. Данный сертификат будет использоваться для авторизации пользователей при их доступе к опубликованным ресурсам с помощью правил reverse-прокси.
Далее в разделе Глобальный портал –> Правила reverse-прокси необходимо включить чекбокс Авторизовать по сертификату и во вкладке Пользователи указать пользователей/группу пользователей, у которых есть сертификат.
Импортировать файл сертификата auth-certiifcates/Admin.p12 в хранилище браузера Ваши сертификаты (пароль 1234; можно изменить в файле generate-auth-certificate.sh).
При первом открытии сайта происходит запрос привязки пользователя к сертификату, который был указан в правилах reverse-прокси. Далее, сайт будет открываться c SSL-сертификатом.
3.8. Настройка HTTPS для Captive-портала¶
По умолчанию, согласно UserGate 6. Руководство администратора, для Captive-портала используется самоподписанный сертификат с common name «auth.captive». Этот сертификат не отображается в веб-консоли. Очевидно, что если просто активировать опцию HTTPS для страницы авторизации в настройках captive-профиля, то в результате отобразится предупреждение браузера о недоверенном сертификате и будет нарушена работа авторизации.
Чтобы использовать HTTPS для страницы авторизации пользователей, необходимо выполнить следующие действия.
Указать служебный домен Auth captive-портала.
Перейдите во вкладку Настройки и в разделе UserGate –> Настройки –> Модули укажите Домен Auth captive-портала, который используется UserGate при авторизации пользователей через captive-портал.
Создать новый CSR.
В главной консоли перейдите в раздел UserGate –> Сертификаты, нажмите Создать и выберите Новый CSR. Укажите необходимые данные, а в поле Common name укажите имя домена Auth captive-портала, настроенного в пункте 1.
Скачать файл.
Для этого выделите созданный CSR и нажмите Экспорт –> Экспорт CSR.
Подписать сертификат.
Для подписания сертификата используется веб-интерфейс центра сертификации Active Directory.
Выберите Request a certificate –> submit an advanced certificate request. Скопируйте содержимое CSR-файла в поле Base-64-encoded certificate request. В качестве шаблона сертификата (Certificate Template) укажите Web Server и нажмите Submit.
Скачать сертификат и цепочку сертификатов в формате Base 64.
Импортировать файлы в UserGate.
Во вкладке UserGate –> Сертификаты откройте созданный в пункте 2 CSR-запрос. Загрузите файлы сертификата и цепочки сертификатов и укажите роль сертификата SSL captive-портала.
Включить HTTPS для страницы авторизации.
Перейдите в раздел Пользователи и устройства –> Captive-профили. В свойствах профиля captive-портала во вкладке Общие отметьте чекбокс HTTPS для страницы авторизации.
Проверка.
Браузер без проблем переходит на страницу авторизации и не возникает ошибок доверия к SSL-сертификату.
Для настройки доверия, необходимо перейти по адресу about:config и включить опцию security.enterprise_roots.enabled.
В результате Firefox также без проблем переходит на страницу авторизации и не возникает ошибок доверия к SSL-сертификату.