Подкатегории

Настройка VPN (версия 7.5.0 и выше)
 
Общие принципы

С помощью функции VPN-сервера на UserGate NGFW вы можете создавать VPN-подключения следующих типов:

  • Защищенное соединение офисов (site-to-site VPN). Подключение типа сервер-сервер позволяет объединить офисы компании в единую логическую сеть. UserGate NGFW может выступать как в роли узла-инициатора соединения (initiator), так и в роли узла-ответчика (responder).

  • Удаленный доступ клиентов в сеть офиса (remote access VPN). В этом сценарии UserGate NGFW выступает в роли VPN-сервера, а устройства пользователей с установленным VPN-клиентом — в роли конечных устройств. В качестве VPN-клиента на устройствах пользователей может использоваться ПО UserGate Client (клиенты для WindowsLinux и macOS), также поддерживаются встроенные VPN-клиенты большинства известных операционных систем, таких как Windows, Linux, Mac OS X, iOS, Android.

Серверные правила VPN в UserGate NGFW версии 7.5.0 и выше реализованы в виде модульной структуры, состоящей из трех отдельно настраиваемых объектов:

  • правил подключения;

  • правил аутентификации;

  • политик VPN.

С помощью такого подхода обеспечивается гибкость в комбинировании параметров на каждом этапе — от инициации сессии до применения индивидуальных настроек доступа в сеть для отдельных пользователей или групп пользователей. Одному методу подключения может соответствовать несколько способов аутентификации; каждому способу аутентификации может соответствовать один или несколько вариантов сетевых параметров подключения.

Подробнее о настройке VPN-подключений типа site-to-site — в разделе «Настройка VPN для защищенного соединения офисов», о настройке VPN-подключений типа remote access — в разделе «Настройка VPN для удаленного доступа в сеть».

Настройка VPN для защищенного соединения офисов

VPN-подключение, с помощью которого создается защищенное соединение локальных сетей удаленных офисов, называется site-to-site VPN.

При подключении один VPN-сервер выступает в роли инициатора соединения (initiator), а другой — в роли ответчика (responder). После успешного создания туннеля распределение ролей VPN-серверов не оказывает влияния на характеристики соединения — передача данных через туннель осуществляется двунаправленно и симметрично.

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

При создании VPN-туннелей в сценарии site-to-site могут использоваться протоколы L2TP/IPsec(IKEv1), IPsec(IKEv1), IPsec(IKEv2).

Для создания VPN-подключения необходимо выполнить настройки соответствующих параметров на обоих граничных узлах защищенного соединения: узле-инициаторе и узле-ответчике.

Настройка UserGate NGFW в качестве узла-ответчика

Для работы UserGate NGFW в качестве VPN-сервера (ответчика) в сценарии site-to-site VPN необходимо настроить:

Настройка сетевых параметров

На узле UserGate NGFW, исполняющем роль VPN-сервера (ответчика), необходимо выполнить ряд дополнительных настроек сетевых параметров:

  • разрешить доступ к узлу для установления VPN-подключения;

  • создать зону для контроля подключаемых узлов;

  • создать VPN-интерфейс для организации туннеля.

Предоставление доступа для VPN-подключений

Откройте доступ к сервису VPN в свойствах зоны, из которой будут подключаться узлы-инициаторы. Для этого в веб-консоли UserGate NGFW перейдите в раздел Настройки ➜ Сеть ➜ Зоны, затем в параметрах контроля доступа для той зоны, из которой будут подключаться узлы-инициаторы, разрешите сервис VPN. Обычно такой зоной является зона Untrusted. Подробнее о создании и настройках параметров зон — в разделе «Настройка зон».

Создание зоны для VPN-подключений

Создайте зону, с которой будут ассоциированы подключаемые по VPN узлы. Эту зону в дальнейшем можно будет использовать в правилах политики безопасности.

В веб-консоли UserGate NGFW зоны создаются в разделе Настройки ➜ Сеть ➜ Зоны. Подробнее о создании и настройках зон — в разделе «Настройка зон».

Создание VPN-интерфейса

VPN-интерфейс — это виртуальный сетевой адаптер, который будет использоваться для подключения узлов-инициаторов VPN-подключения. Такой тип интерфейса является кластерным — он будет автоматически создаваться на всех узлах UserGate NGFW, входящих в кластер конфигурации. Если настроен кластер отказоустойчивости, узлы-инициаторы будут автоматически переключаться на резервный узел VPN-сервера в случае обнаружения проблем с активным узлом без разрыва существующих VPN-соединений.

В веб-консоли UserGate NGFW VPN-интерфейс создается в разделе Настройки ➜ Сеть ➜ Интерфейсы. Для создания интерфейса нажмите Добавить и выберите Добавить VPN. Подробнее о создании VPN-интерфейса — в разделе «Настройка интерфейсов».

Настройка параметров аутентификации

Порядок взаимной аутентификации узлов, участвующих в организации site-to-site VPN, описывается правилами аутентификации. Для настройки правил аутентификации необходимо предварительно создать ряд артефактов, которые будут применяться в правилах в зависимости от используемого метода аутентификации.

При создании защищенного соединения IPsec возможны следующие методы аутентификация удаленного узла:

  • Аутентификация посредством общего ключа (pre-shared key). Используется с протоколами IKEv1 и IKEv2. Общий ключ задается в настройках правил подключения (для IKEv1) или правил аутентификации (для IKEv2) на VPN-сервере (ответчике) и в настройках параметров подключения на узле-инициаторе. Для успешного подключения ключ должен совпадать в параметрах узла-инициатора и узла-ответчика.

  • Аутентификация посредством сертификатов, использующих инфраструктуру открытых ключей (PKI). Используется с протоколом IKEv2. Необходимо заранее создать сертификаты для VPN-серверов и импортировать их в UserGate NGFW.

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

Для проверки VPN-сервером IP-адреса узла-инициатора сертификат узла-инициатора должен содержать значение IP-адреса, с которого придет запрос на подключение к VPN-серверу, в поле SAN (Subject Alternative Name). Если между узлом-источником и VPN-сервером используется NAT, в поле SAN должен быть указан IP-адрес инициатора соединения после подмены адресов на NAT-сервере. При настройке профиля клиентского сертификата в поле Получать имя пользователя из должно быть выбрано значение Subject altname IPv4 

О примерах создания и использования сертификатов для IKEv2 VPN — в разделе «Приложение». О правилах импорта сертификатов в UserGate NGFW — в разделе «Управление сертификатами». О профилях клиентских сертификатов — в разделе «Профили клиентских сертификатов».

Для организации VPN-туннеля с протоколом L2TP необходимо на стороне VPN-сервера (ответчика) создать учетную запись, которая будет использоваться для аутентификации узла, выполняющего роль инициатора соединения, и профиль аутентификации, который будет определять используемый метод аутентификации.

В веб-консоли UserGate NGFW профили аутентификации создаются в разделе Настройки ➜ Пользователи и устройства ➜ Профили аутентификации. Подробнее о профилях аутентификации — в разделе «Профили аутентификации».

Настройка правил подключения

Правила подключения описывают первый этап установления соединения. Этап начинается с инициации соединения со стороны VPN-клиента (узла-инициатора) и заканчивается ответом VPN-сервера (узла-ответчика) с предложением обмена ключами, либо разрывом соединения. Правила содержат проверки зоны источника, адреса инициатора, адреса назначения, типа протокола и определяют параметры фазы 1 установления защищенного соединения.

Для создания правила подключения в веб-консоли UserGate NGFW:

1. Перейдите в раздел Настройки ➜ VPN-сервер ➜ Правила подключения и нажмите Добавить.

2. Выберите протокол подключения IKE.

3. На вкладке Общие в свойствах протокола IKE:

  • Укажите название и описание правила;

  • Выберите версию протокола IKE:

    • IKEv1PSK. Для этого протокола выберите режим работы IKEv1 (основной или агрессивный) и укажите значение общего ключа (pre-shared key). Ключ должен совпадать на узле-инициаторе и на узле-ответчике.

    • IKEv2.

4. На вкладке Источник укажите зоны и адреса, с которых разрешено принимать подключения к VPN:

  • Укажите зону инициатора подключения;

  • Укажите адрес инициатора подключения:

    • выберите или создайте список IP-адресов;

    • выберите или создайте список доменов;

    • выберите GeoIP.

ПримечаниеОбработка трафика происходит по следующей логике:
  • условия объединяются по логическому ИЛИ, если указаны несколько списков IP-адресов или доменов;

  • условия объединяются по логическому И, если указаны GeoIP и списки IP-адресов или доменов.

5. На вкладке Назначение выберите или создайте список IP-адресов или доменных имен интерфейса, на который будут приходить запросы на VPN-подключение. Интерфейс должен принадлежать зоне, указанной на этапе контроля доступа зоны.

6. На вкладке Фаза 1 укажите параметры настройки фазы 1 для установления защищенного канала IKE SA:

  • Укажите время жизни ключа. По истечении этого времени происходит повторная аутентификация и согласование настроек фазы 1.

  • Укажите параметры работы механизма Dead Peer Detection (DPD) для проверки работоспособности канала и его своевременного отключения или переподключения при обрыве связи. DPD периодически отправляет сообщения R-U-THERE для проверки доступности IPsec-соседа. Возможны три режима работы механизма:

    • Отключено — механизм отключен. DPD-запросы не отсылаются.

    • Всегда включено — DPD-запросы всегда отсылаются через указанный интервал времени. Если ответ не пришел, последовательно с интервалом 5 сек. отсылаются дополнительные запросы в количестве, указанном в поле Неудачных попыток. Если ответ пришел, работа механизма возвращается к изначальному интервалу отправки DPD запросов. Если ответ не пришел, соединение завершается.

    • При отсутствии трафика — DPD-запросы не отсылаются, пока есть ESP-трафик через созданный канал. Если в течение двойного указанного интервала времени нет ни одного пакета, происходит отсылка DPD-запроса. При ответе новый DPD-запрос будет отправлен через двойной интервал указанного времени. При отсутствии ответа последовательно с интервалом 5 сек. отсылаются дополнительные запросы в количестве, указанном в поле Неудачных попыток. Если нет ни одного ответа, соединение завершается.

  • Выберите группы Диффи-Хеллмана, которые будут использоваться для обмена ключами.

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

О создании правил подключения с помощью команд интерфейса командной строки — в разделе «Настройка серверных правил».

Настройка правил аутентификации

Правила аутентификации описывают второй этап установления соединения. Этап начинается с ответа узла-инициатора на предложение по обмену ключами и заканчивается после аутентификации инициатора. Правила содержат проверки типа аутентификации и определяют параметры фазы 2 установления защищенного соединения.

Для создания правила аутентификации в веб-консоли UserGate NGFW:

1. Перейдите в раздел Настройки ➜ VPN-сервер ➜ Правила аутентификации и нажмите Добавить.

2. Выберите сценарий site-to-site и затем протокол установления защищенного соединения:

  • IPsec only/IKEv1;

  • IKEv2;

  • IPsec/L2TP.

3. На вкладке Общие в свойствах выбранного протокола:

  • Для протокола IPsec only/IKEv1:

    • Укажите название и описание правила;

    • Выберите одно или несколько созданных ранее правил подключения.

  • Для протокола IKEv2:

    • Укажите название и описание правила;

    • Выберите режим аутентификации (PKI или PSK):

    • Укажите параметры взаимной идентификации граничных узлов соединения: инициатора (initiator) и ответчика (responder). В качестве идентификатора можно указать IP-адрес узла или FQDN.

    • Выберите одно или несколько созданных ранее правил подключения.

  • Для протокола IPsec/L2TP:

    • Укажите название и описание правила;

    • Выберите созданный ранее профиль аутентификации для пользователей VPN.

    • Укажите параметры взаимной идентификации граничных узлов соединения: инициатора (initiator) и ответчика (responder). В качестве идентификатора можно указать IP-адрес узла или FQDN.

    • Выберите одно или несколько созданных ранее правил подключения.

4. На вкладке Фаза 2 укажите параметры настройки фазы 2 для установления защищенного канала IPsec SA:

  • Укажите время жизни ключа. По истечении этого времени узлы должны сменить ключ шифрования.

  • Укажите максимальный размер данных, шифруемых одним ключом.

ПримечаниеЕсли заданы оба параметра (время жизни ключа и максимальный размер данных, шифруемых одним ключом), то первый достигнувший предела параметр запустит пересоздание ключей сессии.
  • При необходимости включите параметр NAT keepalive. NAT keepalive применяется в сценариях, когда IPsec-трафик проходит через узел с NAT. Записи в таблице трансляций NAT активны в течение ограниченного времени. Если за этот промежуток времени не было трафика по VPN-туннелю, записи в таблице трансляций на узле с NAT будут удалены и трафик по VPN-туннелю в дальнейшем не сможет проходить. С помощью функции NAT keepalive VPN-сервер, находящийся за шлюзом NAT, периодически отправляет пакеты keepalive в сторону противоположного узла соединения для поддержания сессии NAT активной.

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

  • Для протоколов IPsec only/IKEv1 и IKEv2 в блоке Peer networks укажите адреса локальных и удаленных подсетей. Адреса подсетей используются для определения селекторов трафика при организации защищенного канала передачи данных IPsec. В ходе фазы 2 стороны туннеля обмениваются своими предложениями по селекторам трафика. Для успешного установления туннеля сети в селекторах трафика от обеих сторон соединения должны совпасть или пересечься. Если нет совпадения хотя бы по одной из сторон, фаза 2 завершится ошибкой соединения. Если поставить флажок Не проверять сети инициатора, VPN-сервер не будет проверять подсети инициатора соединения в селекторе трафика при организации защищенного канала передачи данных. Функция удобна для подключения множества клиентов (инициаторов) по одному правилу.

Для протокола IKEv2 можно разрешить работу протоколов динамической маршрутизации через туннель.

О создании правил аутентификации с помощью команд интерфейса командной строки — в разделе «Настройка серверных правил».

Настройка политик VPN

Политики VPN описывают третий этап установления соединения. Этап начинается идентификацией инициатора и завершается выделением сетевых параметров подключения: туннельного интерфейса, пула адресов в VPN-туннеле, маршрутов к сетевым ресурсам через туннель, адресов DNS-серверов.

Для создания политики VPN в веб-консоли UserGate NGFW:

1. Перейдите в раздел Настройки ➜ VPN-сервер ➜ Политики VPN и нажмите Добавить.

2. Выберите сценарий site-to-site и затем протокол установления VPN-туннеля:

  • IPsec;

  • IPsec/L2TP.

3. Для протокола IPsec:

  • На вкладке Общие в свойствах протокола:

    • Укажите название и описание правила.

    • Выберите VPN-адаптер, который будет использоваться для установления подключения.

    • Выберите одно или несколько созданных ранее правил аутентификации.

4. Для протокола IPsec/L2TP:

  • На вкладке Общие в свойствах протокола:

    • Укажите название и описание правила.

    • Выберите одно или несколько созданных ранее правил аутентификации.

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

  • На вкладке Подсети для VPN:

    • Укажите VPN-интерфейс, который будет использоваться для подключения.

    • Укажите диапазон IP-адресов, которые будут использованы узлами-инициаторами подключения. Необходимо исключить из диапазона адрес, который назначен VPN-интерфейсу UserGate NGFW, используемому совместно с этой сетью. Не указывайте адреса сети и широковещательный адрес.

    • Укажите маску сети VPN.

    • Укажите DNS-серверы, которые будут переданы узлу-инициатору подключения, или поставьте флажок Использовать системные DNS, в этом случае узел-инициатор будет использовать системные DNS-серверы.

  • На вкладке Маршруты VPN укажите маршруты, передаваемые узлу-инициатору в виде бесклассовой адресации (CIDR) или заранее созданный список IP-адресов.

О создании политик VPN с помощью команд интерфейса командной строки — в разделе «Настройка серверных правил».

Настройка доступа к ресурсам

При необходимости предоставления доступа пользователям VPN в определенные сегменты сети в веб-консоли UserGate NGFW в разделе Настройки ➜ Политики сети ➜ Межсетевой экран необходимо создать правило межсетевого экрана, разрешающее трафик из зоны для VPN-подключений в требуемые зоны. Подробнее о создании и настройке правил межсетевого экрана — в разделе «Межсетевой экран».

Для примера в веб-консоли создано правило межсетевого экрана VPN for site-to-site to Trusted and Untrusted, разрешающее весь трафик из зоны VPN for site-to-site в зоны Trusted и Untrusted. Правило отключено по умолчанию

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

Настройка UserGate NGFW в качестве узла-инициатора подключения

Для работы UserGate NGFW в качестве инициатора VPN-соединения в сценарии site-to-site VPN необходимо настроить:

Настройка сетевых параметров

На узле UserGate NGFW, исполняющем роль инициатора VPN-соединения, необходимо выполнить ряд дополнительных настроек сетевых параметров:

  • создать зону для контроля VPN-подключений;

  • создать VPN-интерфейс для организации туннеля.

Создание зоны для VPN-подключений

Необходимо создать зону, с которой будут ассоциированы интерфейсы, используемые для подключения по VPN. В веб-консоли UserGate NGFW зоны создаются в разделе Настройки ➜ Сеть ➜ Зоны. Подробнее о создании и настройках зон — в статье «Настройка зон».

Создание VPN-интерфейса

VPN-интерфейс — это виртуальный сетевой адаптер, который будет использоваться для подключения по VPN.

В веб-консоли UserGate NGFW VPN-интерфейс создается в разделе Настройки ➜ Сеть ➜ Интерфейсы. Для создания интерфейса нажмите Добавить и выберите Добавить VPN, далее в настройках VPN-адаптера задайте необходимые параметры. Подробнее о создании VPN-интерфейса — в разделе «Настройка интерфейсов».

Контроль доступа к сетевым ресурсам

Чтобы трафик передавался на VPN-сервер из нужной зоны узла-источника через VPN-туннель, создайте правило межсетевого экрана, разрешающее трафик между зоной для VPN-подключений и зонами назначения. Подробнее о создании и настройке правил межсетевого экрана — в разделе «Межсетевой экран».

Настройка параметров аутентификации

При создании защищенного соединения IPsec с протоколом IKEv2 может использоваться аутентификация посредством сертификатов (PKI). Создайте заранее сертификат и импортируйте его на узле, исполняющем роль VPN-клиента (источника соединения), в разделе веб-интерфейса Настройки ➜ Консоль администратора ➜ Сертификаты.

Для проверки VPN-сервером IP-адреса узла-инициатора сертификат узла-инициатора должен содержать значение IP-адреса, с которого придет запрос на подключение к VPN-серверу, в поле SAN (Subject Alternative Name). Если между узлом-источником и VPN-сервером используется NAT, в поле SAN должен быть указан IP-адрес инициатора соединения после подмены адресов на NAT-сервере.

О примерах создания и использования сертификатов для IKEv2 VPN — в разделе «Приложение».

Настройка параметров подключения

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

Для настройки параметров подключения узла-инициатора в веб-консоли UserGate NGFW:

1. Перейдите в раздел Настройки ➜ VPN site-to-site клиент ➜ Подключение клиента и нажмите Добавить.

2. Выберите протокол установления защищенного соединения:

  • IPsec only/IKEv1;

  • IKEv2;

  • IPsec/L2TP.

3. На вкладке Общие в свойствах выбранного протокола:

  • Для протокола IPsec only/IKEv1:

    • Укажите название и описание подключения;

    • Выберите режим работы IKE (основной или агрессивный);

    • Укажите общий ключ (pre-shared key). Ключ должен совпадать на узле-инициаторе и на узле-ответчике.

  • Для протокола IKEv2:

    • Укажите название и описание подключения;

    • Флажок Проверять IP на VPN-сервере определяет, будет ли узел-инициатор соединения запрашивать проверку IP-адреса у VPN-сервера. VPN-сервер может принять предложенный IP-адрес или назначить другой. Если флажок поставлен, узел-инициатор соединения добавляет параметр Payload Configuration в сообщение IKE_AUTH и передает в поле INTERNAL_IP4_ADDRESS значение, зависящее от типа туннельного интерфейса:

      • Для туннельного интерфейса с динамическим назначением IP-адреса в поле INTERNAL_IP4_ADDRESS передается значение 0.0.0.0/0, что является запросом на динамическое выделение IP-адреса. VPN-сервер, получив значение 0.0.0.0/0, выделяет IP-адрес из собственного пула, заданного в параметрах соединения на сервере.

      • Для туннельного интерфейса со статическим IP-адресом в поле INTERNAL_IP4_ADDRESS передается его IP-адрес. VPN-сервер использует это значение для проверки соответствия политике подключения.

Если флажок не поставлен, механизм согласования сетевых параметров для проверки IP-адреса туннельного интерфейса на VPN-сервере не применяется. Значение IP-адреса определяется настройками туннельного интерфейса на узле-инициаторе.

  • Выберите режим аутентификации (PKI или PSK):

    • Для аутентификации с помощью сертификатов (PKI) укажите сертификат узла-инициатора;

    • Для аутентификации с общим ключом (PSK) укажите общий ключ. Ключ должен совпадать на узле-инициаторе и на узле-ответчике.

  • Укажите параметр идентификации узла-инициатора. В качестве идентификатора можно указать IP-адрес узла или FQDN.

  • Для протокола IPsec/L2TP:

    • Укажите название и описание подключения;

    • Выберите режим работы IKE (основной или агрессивный);

    • Укажите общий ключ (pre-shared key). Ключ должен совпадать на узле-инициаторе и на узле-ответчике.

    • Укажите параметры взаимной идентификации граничных узлов соединения: инициатора (Initiator) и ответчика (Responder). В качестве идентификатора можно указать IP-адрес узла или FQDN.

    • Укажите параметры аутентификации (логин и пароль) узла-инициатора на узле-ответчике. Параметры аутентификации должны соответствовать параметрам учетной записи, созданной при настройке узла-ответчика.

4. На вкладке Фаза 1 укажите параметры настройки фазы 1 для установления защищенного канала IKE SA:

  • Укажите время жизни ключа. По истечении этого времени происходит повторная аутентификация и согласование настроек фазы 1.

  • Укажите параметры работы механизма Dead Peer Detection (DPD) для проверки работоспособности канала и его своевременного отключения или переподключения при обрыве связи. DPD периодически отправляет сообщения R-U-THERE для проверки доступности IPsec-соседа. Возможны три режима работы механизма:

    • Отключено — механизм отключен. DPD-запросы не отсылаются.

    • Всегда включено — DPD-запросы всегда отсылаются через указанный интервал времени. Если ответ не пришел, последовательно с интервалом 5 сек. отсылаются дополнительные запросы в количестве, указанном в поле Неудачных попыток. Если ответ пришел, работа механизма возвращается к изначальному интервалу отправки DPD запросов, если нет ни одного ответа, соединение завершается.

    • При отсутствии трафика — DPD-запросы не отсылаются, пока есть ESP-трафик через созданные SA. Если в течение двойного указанного интервала времени нет ни одного пакета, происходит отсылка DPD-запроса. При ответе новый DPD-запрос будет отправлен через двойной интервал указанного времени. При отсутствии ответа последовательно с интервалом 5 сек. отсылаются дополнительные запросы в количестве, указанном в поле Неудачных попыток. Если нет ни одного ответа, соединение завершается.

  • Выберите группы Диффи-Хеллмана, которые будут использоваться для обмена ключами.

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

5. На вкладке Фаза 2 укажите параметры настройки фазы 2 для установления защищенного канала IPsec SA:

  • Укажите время жизни ключа. По истечении этого времени узлы должны сменить ключ шифрования.

  • Укажите максимальный размер данных, шифруемых одним ключом.

ПримечаниеЕсли заданы оба значения (время жизни ключа и максимальный размер данных, шифруемых одним ключом), то первый достигнувший предела параметр запустит пересоздание ключей сессии.
  • Выберите алгоритмы аутентификации и шифрования в блоке Безопасность. Алгоритмы используются в порядке, в котором они отображены. Для изменения порядка переместите нужную пару алгоритмов вверх или вниз.

  • Для протоколов IPsec only/IKEv1 и IKEv2 в блоке Peer networks укажите адреса локальных и удаленных подсетей. Адреса подсетей используются для определения селекторов трафика при организации защищенного канала передачи данных IPsec. В ходе фазы 2 стороны туннеля обмениваются своими предложениями по селекторам трафика. Для успешного установления туннеля сети в селекторах трафика от обеих сторон соединения должны совпасть или пересечься. Если нет совпадения хотя бы по одной из сторон, фаза 2 завершится ошибкой соединения.

Для протокола IKEv2 можно разрешить работу протоколов динамической маршрутизации через туннель.

О настройках параметров подключения узла-инициатора с помощью команд интерфейса командной строки — в разделе «Настройка клиентских правил».

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

Клиентское правило в сценарии site-to-site VPN будет инициировать подключение к VPN-серверу (узлу-ответчику).

Для настройки клиентского правила в веб-консоли UserGate NGFW:

1. Перейдите в раздел Настройки ➜ VPN site-to-site клиент ➜ Клиентские правила и нажмите Добавить.

2. Укажите название и описание клиентского правила.

3. Выберите одно из созданных ранее подключений клиента.

4. Выберите ранее созданный VPN-интерфейс.

5. Укажите адрес VPN-сервера (ответчика) в формате IP-адреса или FQDN.

О настройках клиентских правил с помощью команд интерфейса командной строки — в разделе «Настройка клиентских правил».

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

Если VPN-соединение не установилось, в разделе клиентского правила в поле Последняя ошибка отобразится описание ошибки установления соединения.

События работы VPN-сервера (изменения параметров правил, установление соединений, ошибки установления соединений) записываются в системном журнале событий (Event log). Подробнее — в разделе «Журналирование событий VPN-сервера».

Настройка VPN для удаленного доступа в сеть

​VPN-подключение, с помощью которого пользователи могут получить защищенный доступ к сети компании через интернет, называется remote access VPN.

В этом типе подключения UserGate NGFW выступает в роли VPN-сервера, а устройства пользователей — в роли конечных устройств. В качестве клиентского ПО на устройствах пользователей может использоваться UserGate Client, также поддерживаются встроенные клиенты большинства известных операционных систем, таких как Windows, Linux, Mac OS X, iOS, Android.

Для организации защищенного подключения могут использоваться протоколы:

  • L2TP/IPSec(IKEv1);

  • IPSec(IKEv2);

  • DTLS.

Для создания VPN-подключения необходимо произвести настройку соответствующих параметров на VPN-сервере, а затем настроить и подключить VPN-клиент на конечном устройстве.

Настройка VPN-сервера на UserGate NGFW

Для работы UserGate NGFW в качестве VPN-сервера в сценарии remote access VPN необходимо настроить:

Настройка сетевых параметров

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

  • разрешить доступ к узлу для установления VPN-подключений;

  • создать зону для контроля подключаемых конечных устройств;

  • создать VPN-интерфейс для организации туннеля.

Предоставление доступа для VPN-подключений

Откройте доступ к сервисам VPN в свойствах зоны, из которой будут подключаться конечные устройства. Для этого в веб-консоли UserGate NGFW перейдите в раздел Настройки ➜ Сеть ➜ Зоны, затем в параметрах контроля доступа той зоны, из которой будут подключаться конечные устройства, разрешите сервисы VPN и Подключение конечных устройств. Обычно такой зоной является зона Untrusted. Подробнее о создании и настройках параметров зон — в разделе «Настройка зон».

Создание зоны для VPN-подключений

Создайте зону, с которой будут ассоциированы подключаемые по VPN конечные устройства. Эту зону в дальнейшем можно будет использовать в правилах политик безопасности.

В веб-консоли UserGate NGFW зоны создаются в разделе Настройки ➜ Сеть ➜ Зоны. Подробнее о создании и настройках зон — в разделе «Настройка зон».

Создание VPN-интерфейса

VPN-интерфейс — это виртуальный сетевой адаптер, который будет использоваться для подключения конечных устройств. Такой тип интерфейса является кластерным — он будет автоматически создаваться на всех узлах UserGate NGFW, входящих в кластер конфигурации. Если настроен кластер отказоустойчивости, конечные устройства будут автоматически переключаться на резервный узел в случае обнаружения проблем с активным узлом без разрыва существующих VPN-соединений.

В веб-консоли UserGate NGFW VPN-интерфейс создается в разделе Настройки ➜ Сеть ➜ Интерфейсы. Для создания интерфейса нажмите Добавить и выберите Добавить VPN. Подробнее о создании VPN-интерфейса — в разделе «Настройка интерфейсов».

Настройка параметров аутентификации

Порядок аутентификации в сценарии remote access VPN описывается правилами аутентификации. Для настройки правил аутентификации необходимо предварительно создать ряд артефактов, которые будут применяться в правилах в зависимости от используемого метода аутентификации.

1. При создании защищенного соединения IPsec возможны следующие методы аутентификации узлов:

  • Аутентификация посредством общего ключа (pre-shared key). Используется при выборе протокола IKEv1 для организации защищенного соединения cо встроенными VPN-клиентами операционных систем. Общий ключ задается в настройках правил подключения на VPN-сервере и в настройках VPN-клиента на конечном устройстве. Для успешного подключения ключ должен совпадать.

  • Аутентификация посредством сертификатов, использующих инфраструктуру открытых ключей (PKI). Используется при выборе протокола IKEv2 для организации защищенного соединения. Необходимо заранее создать сертификаты VPN-сервера и конечных устройств и импортировать их в UserGate NGFW и на конечные устройства. Сертификаты корневых и промежуточных удостоверяющих центров, которые участвовали в выдаче сертификатов конечных устройств, используется на UserGate NGFW при создании профилей клиентских сертификатов. Профили клиентских сертификатов предназначены для получения имени пользователя из соответствующего атрибута в сертификате клиента, проверки иерархии доверия и подлинности сертификата по спискам отозванных сертификатов.

О примерах создания и использования сертификатов для IKEv2 VPN — в разделе «Приложение». О правилах импорта сертификатов в UserGate NGFW — в разделе «Управление сертификатами». О профилях клиентских сертификатов — в разделе «Профили клиентских сертификатов».

2. Для аутентификации пользователей VPN нужно создать соответствующий профиль аутентификации. Профили аутентификации создаются в разделе Настройки ➜ Пользователи и устройства ➜ Профили аутентификации. Допускается использовать тот же профиль, что используется для аутентификации пользователей с целью получения доступа к сети интернет. Следует учесть, что для аутентификации VPN нельзя использовать методы прозрачной аутентификации, такие как Kerberos, NTLM, SAML IDP. Подробнее о профилях аутентификации — в разделе «Профили аутентификации».

ПримечаниеЕсли авторизация пользователей происходит в различных поддоменах, на вкладке «Домены LDAP» в настройках LDAP-коннектора необходимо указывать все варианты таких поддоменов. Подробнее о настройке LDAP-коннектора читайте в разделе «Серверы аутентификации».

Для аутентификации пользователей VPN вы можете использовать метод многофакторной аутентификации. Значение второго фактора аутентификации может быть получено через одноразовые коды TOTP. VPN с TOTP работает для клиента UserGate Client с протоколом IKEv2 (код вводится в отдельном окне), для других клиентов — только с протоколом IKEv1 (код вводится в пароле через двоеточие: пароль_пользователя:totp_code).

ПримечаниеПри установлении L2TP\IPsec VPN-соединения c аутентификацией пользователей через Multifactor RADIUS Adapter повторное переподключение к VPN-серверу в течении 30-секундного тайм-аута с момента предыдущего успешного подключения произойдет без обращением к RADIUS-серверу. Если переподключение будет выполняться за пределами 30-секундного тайм-аута, обращение к RADIUS-серверу произойдет.

Настройка правил подключения

Правила подключения описывают первый этап установления соединения. Этап начинается с инициации соединения со стороны VPN-клиента и заканчивается ответом VPN-сервера с предложением обмена ключами, либо разрывом соединения. Правила содержат проверки зоны источника, адреса инициатора, адреса назначения, типа протокола и определяют параметры фазы 1 установления защищенного соединения.

Для создания правила подключения в веб-консоли UserGate NGFW:

1. Перейдите в раздел Настройки ➜ VPN-сервер ➜ Правила подключения и нажмите Добавить.

2. Выберите протокол подключения (IKE или DTLS).

3. На вкладке Общие в свойствах выбранного протокола укажите:

  • Для протокола IKE:

    • Укажите название и описание правила;

    • Выберите версию протокола IKE:

      • IKEv1PSK. Укажите режим работы IKEv1 (основной или агрессивный) и значение общего ключа (pre-shared key). Ключ должен совпадать на VPN-сервере и на VPN-клиенте;

      • IKEv2.

  • Для протокола DTLS укажите название и описание правила.

4. На вкладке Источник укажите зоны и адреса, с которых разрешено принимать подключения к VPN:

  • Укажите зону инициатора подключения;

  • Укажите адрес инициатора подключения:

    • выберите или создайте список IP-адресов;

    • выберите или создайте список доменов;

    • выберите GeoIP.

ПримечаниеОбработка трафика происходит по следующей логике:
  • условия объединяются по логическому ИЛИ, если указаны несколько списков IP-адресов или доменов;

  • условия объединяются по логическому И, если указаны GeoIP и списки IP-адресов или доменов.

5. На вкладке Назначение выберите или создайте список IP-адресов или доменных имен интерфейса, на который будут приходить запросы на VPN-подключения от конечных устройств. Интерфейс должен принадлежать зоне, указанной на этапе контроля доступа зоны.

6. На вкладке Фаза 1 укажите криптографические параметры фазы 1 согласования защищенного соединения:

  • Укажите время жизни ключа. По истечении этого времени происходит повторная аутентификация и согласование настроек фазы 1.

  • Укажите параметры работы механизма Dead Peer Detection (DPD) для проверки работоспособности канала и его своевременного отключения или переподключения при обрыве связи. DPD периодически отправляет сообщения R-U-THERE для проверки доступности IPsec-соседа. Возможны три режима работы механизма:

    • Отключено — механизм отключен. DPD-запросы не отсылаются.

    • Всегда включено — DPD-запросы всегда отсылаются через указанный интервал времени. Если ответ не пришел, последовательно с интервалом 5 сек. отсылаются дополнительные запросы в количестве, указанном в поле Неудачных попыток. Если ответ пришел, работа механизма возвращается к изначальному интервалу отправки DPD-запросов. Если ответ не пришел, соединение завершается.

    • При отсутствии трафика — DPD-запросы не отсылаются, пока есть ESP-трафик через созданные SA. Если в течение двойного указанного интервала времени нет ни одного пакета, происходит отсылка DPD-запроса. При ответе новый DPD-запрос будет отправлен через двойной интервал указанного времени. При отсутствии ответа последовательно с интервалом 5 сек. отсылаются дополнительные запросы в количестве, указанном в поле Неудачных попыток. Если нет ни одного ответа, соединение завершается.

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

  • Для протокола IKE выберите группы Диффи-Хеллмана, которые будут использоваться для обмена ключами.

О создании правил подключения с помощью команд интерфейса командной строки — в разделе «Настройка серверных правил».

Настройка правил аутентификации

Правила аутентификации описывают второй этап установления соединения. Этап начинается с ответа конечного устройства на предложение по обмену ключами и заканчивается после аутентификации конечного устройства. Правила содержат проверки типа аутентификации и определяются параметры фазы 2 установления защищенного соединения.

Для создания правила аутентификации в веб-консоли UserGate NGFW:

1. Перейдите в раздел Настройки ➜ VPN-сервер ➜ Правила аутентификации и нажмите Добавить.

2. Выберите сценарий Удаленный доступ и затем протокол установления защищенного соединения:

  • IPsec/L2TP;

  • IKEv2;

  • DTLS.

3. На вкладке Общие в свойствах выбранного протокола укажите:

  • Для протокола IPsec/L2TP:

  • Для протоколов IKEv2 и DTLS:

    • Укажите название и описание правила;

    • Укажите импортированный ранее сертификат сервера и созданный ранее профиль аутентификации;

    • Выберите режим аутентификации (AAA, PKI или любой):

      • Для аутентификации с помощью ключей (PKI) укажите профиль клиентских сертификатов.

      • В режиме аутентификации с помощью методов EAP, PEAP (AAA) VPN-клиент обменивается с VPN-сервером EAP-пакетами. VPN-сервер транслирует пакеты на внешний доменный RADIUS-сервер, который принимает решение об авторизации. После получения разрешения от RADIUS-сервера, VPN-сервер по полученному логину запрашивает у сервера домена информацию о пользователе, после чего принимает решение о подключении пользователя к VPN.

    • Выберите одно или несколько созданных ранее правил подключения.

4. На вкладке Фаза 2 укажите криптографические параметры фазы 2 согласования защищенного соединения:

  • Укажите максимальный размер данных, шифруемых одним ключом.

  • При необходимости включите параметр NAT keepalive. NAT keepalive применяется в сценариях, когда IPsec-трафик проходит через узел с NAT. Записи в таблице трансляций NAT активны в течение ограниченного времени. Если за этот промежуток времени не было трафика по VPN-туннелю, записи в таблице трансляций на узле с NAT будут удалены и трафик по VPN-туннелю в дальнейшем не сможет проходить. С помощью функции NAT keepalive VPN-сервер, находящийся за шлюзом NAT, периодически отправляет пакеты keepalive в сторону VPN-клиента для поддержания сессии NAT активной.

  • Дополнительно для протоколов IKEv2 и IKEv1/L2TP:

    • Укажите время жизни ключа. По истечению этого времени узлы должны сменить ключ шифрования.

ПримечаниеЕсли заданы значения обоих параметров (время жизни ключа и максимальный размер данных, шифруемых одним ключом), то первый достигнувший предела счетчик запустит пересоздание ключей сессии.
  • Выберите алгоритмы аутентификации и шифрования. Алгоритмы используются в порядке, в котором они отображены. Для изменения порядка переместите нужную пару алгоритмов вверх или вниз.

О создании правил аутентификации с помощью команд интерфейса командной строки — в разделе «Настройка серверных правил».

Настройка политик VPN

Политики VPN описывают третий этап установления соединения. Этап начинается идентификацией клиента и завершается выделением сетевых параметров подключения: туннельного интерфейса, адресов в VPN-туннеле, маршрутов к сетевым ресурсам через туннель, адресов DNS-серверов.

Для создания политики VPN в веб-консоли UserGate NGFW:

1. Перейдите в раздел Настройки ➜ VPN-сервер ➜ Политики VPN и нажмите Добавить.

2. Выберите сценарий Удаленный доступ и затем тип VPN-клиента:

  • Clients — для встроенных VPN-клиентов известных операционных систем;

  • UserGate Client — для VPN-клиента UserGate Client.

3. На вкладке Общие в свойствах удаленного доступа:

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

5. На вкладке Подсети для VPN:

  • Укажите VPN-интерфейс, который будет использоваться для подключения.

  • Укажите диапазон IP-адресов, которые будут использованы для подключения. Необходимо исключить из диапазона адрес, который назначен VPN-интерфейсу UserGate NGFW, используемому совместно с данной сетью. Не указывайте здесь адреса сети и широковещательный адрес.

  • Укажите маску сети VPN.

  • Укажите DNS-серверы, которые будут переданы VPN-клиенту, или поставьте флажок Использовать системные DNS, в этом случае клиенту будут назначены локальные DNS-серверы, которые использует UserGate NGFW.

6. Для встроенных VPN-клиентов операционных систем на вкладке Маршруты VPN укажите маршруты, передаваемые конечному устройству в виде бесклассовой адресации (CIDR) или заранее созданного списка IP-адресов.

7. Для UserGate Client укажите параметры настройки функции раздельного туннелирования (split tunneling). Подробнее — в разделе «Настройка раздельного туннелирования для UserGate Client».

О создании политик VPN с помощью команд интерфейса командной строки — в разделе «Настройка серверных правил».

Настройка доступа к ресурсам

Клиенты подключаются к VPN с использованием протокола Point-to-Point. Чтобы трафик мог ходить из созданной ранее зоны для VPN-подключений, создайте правило NAT из этой зоны во все необходимые зоны. Правило создается в разделе Настройки ➜ Политики сети ➜ NAT и маршрутизация. Подробнее о правилах NAT — в разделе «NAT и маршрутизация». Для примера в веб-консоли UserGate NGFW создано правило NAT from VPN for remote access to Trusted and Untrusted, разрешающее подмену IP-адресов из зоны VPN for remote access в зоны Trusted и Untrusted.

При необходимости предоставления доступа пользователям VPN в определенные сегменты сети в веб-консоли UserGate NGFW в разделе Настройки ➜ Политики сети ➜ Межсетевой экран создайте правило межсетевого экрана, разрешающее трафик из зоны для VPN-подключений в требуемые зоны. Подробнее о создании и настройке правил межсетевого экрана — в разделе «Межсетевой экран».

Для примера в веб-консоли UserGate NGFW создано правило межсетевого экрана VPN for remote access to Trusted and Untrusted, разрешающее весь трафик из зоны VPN for remote access в зоны Trusted и Untrusted. Правило отключено по умолчанию

Настройка параметров VPN-клиента

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

Настройка параметров VPN-клиента зависит от типа клиента и протокола установления VPN-подключения.

Настройка параметров VPN-подключения UserGate Client

О настройках VPN-подключений с помощью UserGate Client для Windows — в разделе «Установка VPN-соединения с помощью UserGate Client для Windows».

О настройках VPN-подключений с помощью UserGate Client для Linux — в разделе «Настройка VPN-соединения на устройстве пользователя с помощью UserGate Client для Linux».

О настройках VPN-подключений с помощью UserGate Client для macOS — в разделе «Настройка VPN-соединения на устройстве пользователя с помощью UserGate Client для macOS».

Настройка параметров VPN-подключения встроенных VPN-клиентов

О настройках VPN-подключений с помощью встроенных VPN-клиентов операционных систем — в разделе «VPN для удаленного доступа клиентов (remote access VPN)».

Журналирование событий VPN-сервера

Записи о работе VPN-сервера UserGate NGFW сохраняются в системном журнале событий (Event log).

Записи содержат информацию:

  • об изменениях параметров правил VPN;

  • статусе VPN-подключений;

  • ошибках VPN-подключений.

В веб-консоли UserGate NGFW в разделе Журналы и отчеты ➜ Журналы ➜ Журнал событий записи событий VPN-сервера можно отфильтровать, выбрав в меню журнала компонент «VPN» и нужные типы событий.

Также записи событий можно отфильтровать с помощью запросов в строке расширенного поиска.

ПримечаниеСобытия VPN-сервера не реплицируются на другой узел кластера.

Ошибки подключений на VPN-сервере

Ошибки, связанные с неудачными попытками подключения к VPN-серверу или с разрывом существующих VPN-соединений, записываются в журнал событий UserGate NGFW.

Вы можете отсортировать ошибки подключений в журнале событий по компоненту «VPN», типу события «Ошибка сервера», времени возникновения ошибки, названию клиентского правила или IP-адресу VPN-клиента.

В таблице приведены варианты сообщений об ошибках VPN-подключений, отображаемые в журнале событий веб-интерфейса UserGate NGFW, и возможные причины их возникновения.

Детали события

Event details

Возможная причина ошибки

Клиент не отвечает

No response from client

При согласовании параметров безопасности фазы 1 защищенного соединения не получен ответ от VPN-клиента в установленный промежуток времени. Возможные причины:

  • Произошла потеря пакетов.

  • VPN-клиент выключен.

  • VPN-клиент инициировал новое подключение

Настройки параметров безопасности фазы 1 на сервере несовместимы с настройками на клиенте

The server's Phase 1 security settings are incompatible with the client's settings

На этапе согласования параметров безопасности фазы 1 защищенного соединения не найдены совпадения в параметрах:

  • групп Диффи-Хеллмана;

  • алгоритмов шифрования;

  • алгоритмов аутентификации

Ошибка подключения VPN-клиента: неверный общий ключ

VPN client connection error: incorrect pre-shared key

На этапе установления фазы 1 защищенного соединения VPN-сервер не может расшифровать сообщение от VPN-клиента или подтвердить его подлинность.

Возможная причина ошибки: несовпадение значения общего ключа в настройках параметров VPN-сервера и VPN-клиента

Настройки параметров безопасности фазы 2 на сервере несовместимы с настройками на клиенте

The server's Phase 2 security settings are incompatible with the client's settings

На этапе согласования параметров безопасности фазы 2 защищенного соединения не найдены совпадения:

  • алгоритмов шифрования;

  • алгоритмов аутентификации

Для клиента не был найден свободный IP-адрес, подключение отклонено

No Available IP Address Found for the Client, Connection Rejected

Диапазон адресов, предназначенный для VPN-клиентов, слишком мал для имеющегося количества одновременных подключений

Не получен код двухфакторной аутентификации

MFA code not received

На этапе аутентификации не получен код второго фактора аутентификации от VPN-клиента

Неверный код двухфакторной аутентификации

MFA verification failed

На этапе аутентификации получен неверный код второго фактора аутентификации от VPN-клиента.

Возможные причины получения неверного кода:

  • Рассинхронизация времени между сервером и клиентом.

  • Неверно введенный пользователем код.

  • Устаревший код

Цифровая подпись в сертификате клиента не соответствует подписи, вычисленной VPN-сервером

The digital signature in the client certificate does not match the signature computed by the VPN сервер

Ошибка аутентификации на этапе IKE_AUTH в IKEv2. VPN-сервер использует открытый ключ из сертификата клиента для проверки цифровой подписи, которую клиент создал своим закрытым ключом. Если подписи не совпадают, сервер немедленно разрывает соединение, так как не может подтвердить подлинность клиента.

Возможные причины:

  • Несоответствие пары ключей.

  • Повреждение данных или неправильный расчет хеш-суммы.

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

В сертификате отсутствует альтернативное имя (SAN) или оно указано неверно

Certificate SAN empty or certificate SAN mismatch

Ошибка при установлении VPN-подключения в сценарии Site-to-Site с аутентификацией посредством сертификатов.

Возможной причиной ошибки является некорректный сертификат клиента, в котором либо отсутствует расширение Subject Alternative Name (SAN), либо в нем указан некорректный IP-адрес или FQDN клиента

Несовпадение подсетей клиента и VPN-сервера

Client and server VPN subnets do not match

В сценарии Site-to-site c протоколом IPsec/IKEv2 в ходе фазы 2 стороны туннеля обмениваются своими предложениями по селекторам трафика. Для успешного установления туннеля сети в селекторах трафика от обеих сторон соединения должны совпасть или пересечься. Если нет ни одного совпадения в адресах локальных и удаленных подсетей, соединение разрывается и выдается сообщение об ошибке

Клиент не поддерживает NAT-T

Client does not support NAT-T

При установлении VPN-подключения с протоколом IPsec IKEv1 VPN-сервер не находит в сообщении от клиента идентификатор Vendor ID

Отсутствует KE-пакет, обмен ключами DH невозможен

Missing KE payload, DH key exchange not possible

Критическая ошибка в процессе обмена ключами при установлении VPN-подключения.

Возможные причины:

  • Ошибки в конфигурации DH-групп на одной из сторон соединения.

  • Устаревшая версия VPN-клиента.

  • Блокировки IKE-пакетов на сети

Сбой согласования IKE: не получен nonce (Ni payload) от клиента

IKE negotiation failed: the initiator's nonce was not received

Ошибка в процессе обмена ключами при установлении VPN-подключения.

Возможные причины:

  • Потери пакетов или фрагментация пакетов.

  • Блокировки IKE-пакетов на сети.

  • Ошибки конфигурации: разные версии IKE на клиенте и сервере.

  • Рассинхронизация времени между клиентом и сервером

Сбой аутентификации клиента: хеш-код HASH_I не получен.

Client authentication failed: HASH_I not received

Ошибка аутентификации клиента в процессе установления IKE-соединения.

Возможные причины:

  • Некорректные учетные данные (неправильный общий ключ, недействительный сертификат).

  • Несовместимость алгоритмов шифрования или аутентификации на клиенте и сервере.

  • Рассинхронизация времени между клиентом и сервером

Соединение разорвано по алгоритму DPD

VPN connection closed by Dead Peer Detection algorithm

Разрыв VPN-подключения по причине неактивности противоположной стороны соединения в пределах установленного интервала.

Причинами отсутствия ответа противоположной стороны соединения могут быть:

  • Проблемы с сетевой связностью.

  • Высокая загрузка сети или сторон соединения.

  • Слишком агрессивные настройки параметров протокола DPD

VPN-туннель закрыт по причине срабатывания защиты от перехвата

VPN tunnel closed due to anti-replay protection trigger

Срабатывание защиты от перехвата и повторной передачи VPN-пакетов. Нарушение последовательности или повторяемость номеров (sequence number) получаемых пакетов.

Возможные причины:

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

  • Перегрузка VPN-сервера или клиента.

  • Рассинхронизация времени между клиентом и сервером

Следующие ошибки VPN-подключений не фиксируются в журнале событий UserGate NGFW:

  • Несовпадение параметров первого пакета. Если параметры инициирующего пакета от VPN-клиента не соответствуют ни одному из настроенных на VPN-сервере правил подключения.

  • Отсутствие активной VPN-политики. Если параметры инициирующего пакета VPN-клиента соответствует условиям одного из правил подключения, но это правило не связано ни с одной из активных политик VPN.

  • Промежуточные этапы IKEv2. Отдельные итерации в процессе согласования группы Диффи-Хеллмана по протоколу IKEv2, если в итоге соединение устанавливается успешно.

Ошибки подключений на VPN-сервере (инициаторе соединения)

В сценарии Site-to-site VPN UserGate NGFW может выступать в роли инициатора VPN-соединения. При неудачной попытке установления соединения с удаленным VPN-сервером или при разрыве установленного соединения в журнал событий будут записываться сообщения об ошибках VPN-подключения.

В журнале событий веб-интерфейса вы можете отсортировать ошибки подключений по компоненту «VPN», типу события «Ошибка клиента» или времени возникновения ошибки.

Последняя ошибка подключения по активному правилу также отображается в разделе клиентских правил веб-интерфейса (Настройки ➜ VPN Site-to-Site клиент ➜ Клиентские правила) в поле Последняя ошибка VPN.

В таблице приведены варианты сообщений об ошибках, отображаемые в веб-интерфейсе UserGate NGFW (инициатора соединения), и возможные причины их возникновения.

Детали события

Event details

Возможная причина ошибки

Сервер не отвечает

No response from server

1. Инициатор VPN-соединения отправляет запрос на подключение к VPN-серверу и не получает ответ в течение настроенного времени ожидания.

Возможные причины:

  • Некорректный IP-адрес VPN-сервера в настройках клиентских правил на инициаторе соединения.

  • Неверный адрес VPN-сервера определяется на DNS-сервере.

  • На VPN-сервере не открыты порты 500, 4500.

  • На VPN-сервере не найдено активное правило подключения, подходящее по параметрам:

    • протокол;

    • режим IKE;

    • IP-адрес источника или назначения;

    • пользователь.

  • Высокая загрузка VPN-сервера.

  • Произошла перезагрузка VPN-сервера без сохранения состояния IKE_SA.

  • Потеря пакетов из-за перегрузки сети

2. После истечения таймера механизма DPD система отправляет первоначальный DPD-запрос. В случае отсутствия ответа и исчерпания всех попыток проверки клиент фиксирует недоступность VPN-сервера.

Возможные причины:

  • На VPN-сервере не открыты порты 500, 4500.

  • Высокая загрузка VPN-сервера.

  • Произошла перезагрузка VPN-сервера без сохранения состояния IKE_SA.

  • Потеря пакетов из-за перегрузки сети.

3. Ошибка в процессе пересоздания ключей (rekeying) для IKE- или ESP-туннеля: VPN-сервер не ответил на запрос.

Возможные причины:

  • Потеря сетевой связности.

  • Высокая загрузка VPN-сервера.

  • Произошла перезагрузка VPN-сервера без сохранения состояния IKE_SA.

  • Потеря пакетов из-за перегрузки сети

Ошибка подключения: некорректное имя сервера

Invalid server name

Доменное имя VPN-сервера, указанное в параметрах подключения инициатора VPN-соединения, не определяется DNS-сервером.

Вероятные причины:

  • Неверно указано доменное имя VPN-сервера в параметрах подключения на узле-инициаторе соединения.

  • На DNS-сервере не определено доменное имя VPN-сервера

Ошибка подключения: некорректные параметры аутентификации клиента

VPN client connection error — wrong client auth

Ошибка подключения по IKEv2.

Узел-инициатор соединения не прошел аутентификацию на VPN-сервере.

Возможные причины:

  • неверно указан общий ключ (PSK) в настройках подключения;

  • VPN-сервер сопоставил идентификатор клиента с другой политикой, где задан другой общий ключ

Тайм-аут фазы 1. Используется неверный общий ключ

Phase 1 timeout. Incorrect shared key

Ошибка установления IPsec-соединения с использованием протоколов IPsec/L2TP

Возможные причины:

  • В параметрах VPN-подключения указано неверное значение общего ключа.

  • Не совпадают параметры фазы 1 IKE

Ошибка подключения по протоколу IPsec/L2TP: неверный пароль 

VPN client connection error IPsec/L2TP: incorrect password

Ошибка при установлении соединения с протоколами IPsec/L2TP.

Возможные причины:

  • На VPN-сервере создана, но не включена учетная запись для аутентификации узла-инициатора соединения.

  • Учетная запись для аутентификации узла-инициатора соединения на VPN-сервере не связана с политикой VPN.

  • На VPN-сервере не настроен профиль аутентификации с локальным пользователем для аутентификации узла-инициатора соединения .

  • Несовпадение пароля учетной записи на VPN-сервера и в параметрах соединения на узле-инициаторе.

  • На VPN-сервере нет свободного IP-адреса для клиента

Настройки безопасности VPN-клиента несовместимы с настройками сервера

VPN client and VPN server security settings are not compatible

Ошибка при установлении соединения с протоколами IKEv2 и IPsec/L2TP.

Возможные причины:

  • Несоответствие параметров соединения на VPN-сервере и узле-инициаторе соединения:

    • Группы Диффи-Хеллмана не совпадают.

    • Настройки безопасности первой фазы не совпадают.

    • Настройки безопасности второй фазы не совпадают

Ошибка подключения VPN-клиента — некорректные параметры аутентификации сервера

VPN client connection error — wrong server auth

Ошибка при установлении соединения с протоколами IKEv2. 

Неуспешная проверка цифровой подписи VPN-сервера в сообщении IKE_AUTH, в результате чего подлинность сервера не подтверждена

Аутентификация клиента невозможна: не получен HASH_I

Client authentication failed: HASH_I not received

Ошибка при установлении соединения по протоколу IKEv1.

Значение HASH_DATA, полученное от VPN-сервера, не совпадает со значением, вычисленным на стороне инициатора соединения.

Возможные причины:

  • повреждение пакета при передаче;

  • потеря предыдущего сообщения, влияющего на вычисление HASH_DATA;

  • использование некорректного значения общего ключа;

  • попытка подмены или иного вмешательства в процесс обмена сообщениями

Отсутствие ключевой информации в ответе сервера. Вероятно не совпадает общий ключ

Missing key exchange in server response. Highly likely incorrect shared key

Ошибка при установлении соединения по протоколу IKEv2.

В сообщении, полученном от VPN-сервера, отсутствует обязательный payload Key Exchange (KE)

Ошибка декодирования сообщения сервера, хэш неверный

Error decoding server message, hash is invalid

Ошибка при установлении соединения по протоколу IKEv2.

Инициатор соединения выполняет проверку целостности сообщения, полученного от VPN-сервера, путем вычисления значения Integrity Check Value (ICV) и сравнения его с полученным значением. При несовпадении значений проверка целостности завершается неуспешно, и соединение не устанавливается.

Возможные причины:

  • повреждение или потеря пакетов при передаче (в том числе при фрагментации);

  • потеря предыдущего сообщения, влияющего на состояние обмена

Настройки безопасности VPN-клиента несовместимы с настройками сервера

VPN client and VPN server security settings are not compatible

Ошибка при установлении соединения по протоколу IKEv1.

Параметры защищаемых подсетей (local/remote networks), настроенные на VPN-сервере и узле-инициаторе соединения, не совпадают, в результате чего не удается согласовать параметры IPsec-туннеля

Несовпадение идентификаторов

Incompatible identifiers

Ошибка при установлении соединения по протоколу IKEv2.

На этапе согласования IPsec SA клиент отправляет сообщение IKE_AUTH с селекторами трафика (TSi/TSr). VPN-cервер сверяет полученные TSi/TSr с настройками локальных подсетей. Если ни одна подсеть не может быть согласована, VPN-сервер отправляет сообщение INFORMATIONAL со значением Notify payload TS_UNACCEPTABLE, и соединение не устанавливается.

Причина: Подсети, настроенные на узле-инициаторе соединения и VPN-сервере, не совпадают

Отсутствие идентификатора в ответе сервера

Missing identifier in server response

Ошибка при установлении соединения по протоколу IKEv1.

Узел-инициатор соединения не получил обязательный идентификатор VPN-сервера (IDr) в ответном пакете IKE. В результате невозможна проверка подлинности VPN-сервера, и соединение не устанавливается.

Возможные причины:

  • повреждение или потеря пакетов при передаче;

  • несоответствие режима IKE в параметрах соединения на узле-инициаторе и на VPN-сервере;

  • неправильное значение общего ключа в параметрах подключения

Ошибка выделения IP-адреса на сервере

Error allocating IP address from VPN server

Не удалось получить IP-адрес от VPN-сервера.

Узел-инициатор соединения не получил свободный IP-адрес от VPN-сервера, поэтому соединение не может быть установлено. Проверьте параметры подключения на VPN-сервере и наличие свободных IP-адресов в пуле

VPN в режиме полного туннелирования

VPN в режиме полного туннелирования (full tunnel) — это способ подключения, при котором весь сетевой трафик со стороны VPN-клиента, включая обращения к корпоративным системам и к внешним интернет-ресурсам, передается через защищенный VPN-туннель и обрабатывается на VPN-сервере. В отличие от режима раздельного туннелирования (split tunnel), при таком подходе трафик не разделяется на корпоративный и интернет-трафик — весь поток данных проходит через VPN.

В UserGate NGFW режим полного туннелирования может применяться в сценариях site-to-site VPN с использованием протокола IPsec/IKEv2.

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

Основные преимущества режима полного туннелирования:

  • простота интеграции филиалов компании;

  • полный контроль трафика;

  • единая политика безопасности;

  • централизованное журналирование.

К недостаткам сценария можно отнести повышенную нагрузку на VPN-сервер головного офиса и возможное увеличение сетевых задержек.

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

На этапе согласования защищенного канала удаленный шлюз (VPN-клиент) запрашивает для селектора трафика VPN-сервера (TSr) значение 0.0.0.0/0, которое принимается VPN-сервером. На удаленном шлюзе изменяется таблица маршрутизации: маршрут по умолчанию назначается через VPN-интерфейс, и весь трафик от удаленного шлюза направляется через корпоративный VPN-сервер. При этом доступ к самому VPN-серверу сохраняется по прямому маршруту вне туннеля.

При разрыве VPN-соединения — по инициативе пользователя, по команде сервера или по иной причине — шлюз завершает VPN-сессию и восстанавливает исходный маршрут по умолчанию.

Настройка режима полного туннелирования на UserGate NGFW

Для создания VPN-подключения необходимо выполнить настройку обоих граничных узлов защищенного соединения: удаленного шлюза (VPN-клиента) и VPN-сервера.

Настройка VPN-сервера

Настройку VPN-сервера выполните по алгоритму, описанному в разделе «Настройка UserGate NGFW в качестве узла-ответчика».

Особенности настройки для режима полного туннелирования:

  • На VPN-сервере должны быть настроены маршруты в корпоративные сети, сети филиалов и в интернет.

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

  • Для подключаемых шлюзов настроено правило подключения с протоколом IKEv2 с ограничением по IP-адресам. Разрешена соответствующая зона источника.

  • Для всех подключаемых шлюзов создано правило аутентификации S2S IKEv2, в котором:

    • TSr (Local subnets) = 0.0.0.0/0 — VPN-сервер принимает весь трафик по умолчанию от удаленных шлюзов, использующих такую политику.

    • Для удаленных сетей может быть активирована опция «Не проверять сети инициатора», при которой VPN-сервер принимает любые TSi (Remote subnets). Это упрощает конфигурацию. Если опция отключена, администратор должен явно указать подсети, которые VPN-сервер будет проверять при получении трафика от удаленного шлюза. В этом случае VPN-сервер согласует только те подсети, которые полностью совпадают с объявленными шлюзом.

Настройка удаленного шлюза

Настройку удаленного шлюза выполните по алгоритму, описанному в разделе «Настройка UserGate NGFW в качестве узла-инициатора подключения».

Особенности настройки для режима полного туннелирования:

  • До установления VPN-соединения VPN-сервер должен быть доступен согласно текущей таблице маршрутизации (через шлюз по умолчанию, другой L3-шлюз или по L2 — в зависимости от выбранного варианта).

  • Должно быть создано правило подключения с протоколом IKEv2 со следующими параметрами:

    • Remote subnets (TSr): 0.0.0.0/0;

    • Local subnets (TSi): указываются только те подсети, которые разрешены на VPN-сервере согласно действующей политике.

  • VPN-клиент выполняет роль шлюза по умолчанию для всех локальных подсетей.

Раздельное туннелирование для UserGate Client

Режим раздельного туннелирования (split tunnel) — это способ удаленного подключения, при котором трафик VPN-клиента разделяется на два потока:

  • Часть трафика идет через VPN-туннель (например, доступ к корпоративным ресурсам).

  • Остальной трафик идет напрямую через обычное интернет-соединение, минуя VPN.

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

Таблица маршрутизации компьютера пользователя с установленным ПО UserGate Client модифицируется при установлении VPN-соединения в соответствии с настроенными на VPN-сервере UserGate NGFW параметрами маршрутизации клиента. После завершения VPN-сессии локальные настройки маршрутизации на компьютере пользователя возвращаются в исходные.

При установлении VPN-соединения в таблицу маршрутов клиента добавляются два новых маршрута. Они необходимы для сохранения подключения к VPN-серверу во всех сценариях:

  • Маршрут к шлюзу локальной сети. Добавляется через IP-адрес локального интерфейса в качестве шлюза.

  • Маршрут к VPN-серверу.

    • Добавляется через IP-адрес локального интерфейса в качестве шлюза, если адрес VPN-сервера находится в адресном пространстве локальной сети.

    • Добавляется через IP-адрес шлюза локальной сети в качестве шлюза в случае если адрес VPN-сервера не находится в адресном пространстве локальной сети.

Локальные маршруты в обход VPN, изначально прописанные на компьютере пользователя, удаляются на время работы VPN. После отключения VPN-соединения эти маршруты возвращаются.

Настройка режима раздельного туннелирования на UserGate NGFW

В веб-консоли UserGate NGFW вы можете настроить различные сценарии работы режима раздельного туннелирования. Для этого перейдите в раздел Настройки ➜ VPN-сервер ➜ Политики VPN. В свойствах политики удаленного доступа для UserGate Client выберите вкладку Маршруты для UserGate Client.    

Рассмотрим подробнее возможные сценарии настроек раздельного туннелирования.

a) Если поставлен флажок Все маршруты, в таблицу маршрутизации клиента будет добавлен маршрут по умолчанию (default route) вида 0.0.0.0/0 ➜ VPN-шлюз. Имеющийся ранее маршрут по умолчанию будет удален из таблицы.

b) Если в поле Включить маршруты добавлены IP-адреса или списки IP-адресов, то для каждого включенного адреса добавляется маршрут вида n.n.n.n/c ➜ VPN-шлюз с гарантированно минимальной метрикой 2. 

c) Если в поле Исключить маршруты добавлены IP-адреса или списки IP-адресов, то в таблицу маршрутизации клиента будет добавлен маршрут по умолчанию вида 0.0.0.0/0 ➜ VPN-шлюз. Имеющийся ранее маршрут по умолчанию будет удален из таблицы. Для каждого исключаемого адреса добавляется свой маршрут через интерфейс с лучшей метрикой в обход VPN. 

d) Если в обоих полях Включить маршруты и Исключить маршруты добавлены IP-адреса или списки IP-адресов, то для каждого включенного адреса добавляется маршрут вида n.n.n.n/c ➜ VPN-шлюз с гарантированно минимальной метрикой 2. Для каждого исключаемого адреса добавляется свой маршрут через интерфейс с лучшей метрикой в обход VPN. 

 

e) Если во вкладке нет никаких настроек, то в таблицу маршрутизации клиента добавляется VPN-маршрут вида 0.0.0.0/0 ➜ VPN-шлюз с метрикой больше, чем у имеющегося маршрута по умолчанию. Имеющийся маршрут по умолчанию при этом не удаляются и маршруты для UserGate MC, UserGate NGFW, VPN-сервера не создаются.

f) Если поставлен флажок Ограничить доступ к локальной сети, то для каждой подсети локального интерфейса создается копия маршрута через VPN-шлюз с гарантированно минимальной метрикой 2. Такие же копии маршрутов создаются для всех адресов, которые имеют тип local interface.

В зависимости от сценариев настроек метрики для VPN-маршрутов broadcast- и multicast-адресов получают следующие значения:

  • Лучшая метрика среди соответствующих адресов — для сценариев a) и с);

  • Гарантированно худшая метрика 10 000 — для сценариев b) и d).

В зависимости от режима работы компьютер с установленным ПО UserGate Client осуществляет коммуникацию либо с UserGate MC, либо с UserGate NGFW. С этой целью создается отдельный маршрут для соответствующего IP-адреса в обход VPN. Такой маршрут не создается для сценария e) и в случае, когда VPN-клиент и UserGate MC или UserGate NGFW находятся в одной сети.