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

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

Типы VPN-подключений

UserGate NGFW позволяет создавать VPN-подключения следующих типов:

• VPN для защищенного соединения офисов (Site-to-Site VPN). В этом сценарии один узел выступает в роли VPN-сервера, а другой — в роли VPN-клиента. Подключение сервер-сервер позволяет объединить офисы компании в единую логическую сеть.

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

Варианты организации защищенных VPN-туннелей

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

L2TP/IPsec VPN

При создании VPN с помощью L2TP/IPsec, протокол L2TP (RFC 3931)  создает туннель, в котором пакеты сетевого уровня передаются в кадрах PPP. Поскольку L2TP сам по себе не обеспечивает строгую аутентификацию, конфиденциальность и целостность передаваемых данных, для этих целей используется группа протоколов IPsec (RFC 6071).

L2TP-туннель создается внутри защищенного IPsec-канала и для его установления необходимо сначала создать защищенное IPsec-соединение между узлами. IPsec в данном случае работает в транспортном режиме и использует протокол ESP (Encapsulating Security Payload) для шифрования L2TP-пакетов.

VPN имеет два уровня инкапсуляции — внутреннюю инкапсуляцию L2TP и внешнюю инкапсуляцию IPsec. Внутренний уровень имеет заголовки L2TP и UDP дополнительно к кадру PPP. Внешний уровень добавляет заголовок и трэйлер IPsec ESP. Трейлер проверки подлинности IPsec Auth обеспечивает проверку целостности сообщений и аутентификацию.

Процесс создания VPN состоит из следующих основных этапов:

1. Установление защищенного канала передачи данных.

2. Установление VPN-туннеля.

Установление защищенного канала передачи данных

Для установления защищенного канала передачи данных используется группа протоколов IPsec.

В основе IPsec лежат три протокола:

• Authentication Header (AH).

• Encapsulating security payload (ESP).

• Internet Key Exchange (IKE).

Authentication Header (AH) обеспечивает целостность передаваемых данных, аутентификацию источника информации и защиту от повторной передачи данных. AH не обеспечивает конфиденциальность передаваемых данных, поскольку не осуществляет шифрование. Номер IP-протокола для AH — 51.

Encapsulating security payload (ESP) обеспечивает конфиденциальность передаваемых данных с помощью шифрования, также поддерживается целостность передаваемых данных и аутентификация источника информации. Номер IP-протокола для ESP — 50. 

Internet Key Exchange (IKE) — это протокол обмена служебной информацией для согласования и установления ассоциации безопасности (Security Association — SA). Ассоциация безопасности содержит набор параметров защищенного соединения, которые могут использоваться обеим сторонами соединения для взаимной аутентификации и шифрования передаваемых данных. IKE работает по UDP-порту 500.

IPsec может работать в двух режимах:

• Туннельный режим.

• Транспортный режим.

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

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

В сценарии установления VPN с помощью протоколов L2TP/IPsec туннель между узлами создается протоколом L2TP, при этом IPsec должен обеспечивать безопасность канала. В этом случае IPsec работает в транспортном режиме, а согласование ассоциаций безопасности и установление защищенного канала осуществляется с помощью протокола IKE версии IKEv1 в двух фазах.

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

Согласуемыми параметрами IKE SA являются: 

• Хэш-алгоритмы (MD5, SHA).

• Алгоритмы шифрования (DES, 3DES, AES).

• Параметры времени жизни туннеля.

• Группы Diffie-Hellman.

Для аутентификации узлов канала используется метод общих ключей — pre-shared keys.

Согласование фазы 1 IKEv1 может происходить в двух режимах:

• Основной (Main) режим.

• Агрессивный (Aggressive) режим.

В основном режиме происходит обмен шестью сообщениями. Во время первого обмена (сообщения 1 и 2) происходит согласование алгоритмов шифрования и аутентификации для IKE SA. Второй обмен (сообщения 3 и 4) предназначен для обмена ключами Диффи-Хеллмана (DH). После второго обмена служба IKE на каждом из устройств создаёт основной ключ, который будет использоваться для защиты проверки подлинности. Третий обмен (сообщения 5 и 6) предусматривает аутентификацию инициатора соединения и получателя (проверка подлинности); информация защищена алгоритмом шифрования, установленным ранее.

В агрессивном режиме происходит два обмена сообщениями (всего три сообщения). В первом сообщении инициатор передаёт информацию, соответствующую сообщениям 1 и 3 основного режима, т.е. информацию об алгоритмах шифрования и аутентификации, и ключ DH. Второе сообщение предназначено для передачи получателем информации, соответствующей сообщениям 2 и 4 основного режима, а также аутентификации получателя. Третье сообщение аутентифицирует инициатора и подтверждает обмен.

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

Результатом фазы 1 является согласование двунаправленной ассоциации безопасности IKE SA  и установление защищенного служебного канала. Данный канал будет использоваться в фазе 2 для согласования параметров IPsec SA основного канала передачи данных.

В фазе 2 по защищенному служебному каналу, установленному в фазе 1, происходит согласование IPsec SA для защиты данных, проходящих через канал IPsec.

IKEv1 в фазе 2 имеет один режим, называемый быстрым режимом (Quick mode).

Согласуемыми параметрами IPsec SA являются:

• Алгоритмы шифрования (DES, 3DES, AES).

• Хэш-алгоритмы (MD5, SHA-1, SHA-2).

• Параметры времени жизни SA.

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

После его установления служебный канал, созданный в фазе 1, не пропадает – он используется для обновления SA основного.

IPsec SA завершает работу при выключении VPN с одной из сторон соединения или по истечении времени жизни. Тайм-аут по времени жизни возникает при истечении времени жизни ключа или при достижении установленного порога байт данных, прошедших через канал. Когда SA завершает работу, ключи удаляются. Если для передачи данных требуются дополнительные IPsec SA, выполняется новая фаза согласования IKE.

Установление VPN-туннеля

На этом этапе происходит согласование и установление туннеля L2TP между конечными точками SA. Фактическое согласование параметров происходит по защищенному каналу IPsec SA. Протокол L2TP использует UDP-порт 1701.

Когда процесс установления VPN туннеля завершен, пакеты L2TP между конечными точками инкапсулируются с помощью IPsec. Поскольку сам пакет L2TP скрыт внутри пакета IPsec, исходный IP-адрес источника и назначения зашифрован внутри пакета. Кроме того, нет необходимости открывать UDP-порт 1701 на FW между конечными точками, поскольку внутренние пакеты не обрабатываются до тех пор, пока данные IPsec не будут расшифрованы, что происходит только на конечных точках туннеля.

IKEv2/IPsec VPN

При создании VPN с помощью IKEv2/IPsec защищенный VPN-туннель создается только протоколами группы IPsec с протоколом IKE версии IKEv2 (RFC 7296, RFC 7427).

В этом сценарии IPsec работает в туннельном режиме, исходные IP-пакеты целиком инкапсулируются и шифруются внутри нового пакета, который имеет свой собственный заголовок и трэйлеры.

Подобно IKEv1, IKEv2 также имеет двухэтапный процесс установления защищенного соединения, но при этом происходит меньше обменов сообщениями.

Первый этап известен, как IKE_SA_INIT. В двух сообщениях обмена IKE_SA_INIT между соседними узлами происходит согласование параметров ассоциации безопасности IKE SA и установление защищенного служебного канала. Согласуемые параметры IKE SA:

• Хэш-алгоритмы.

• Алгоритмы шифрования.

• Ключи Diffie-Hellman

Каждый узел генерирует seed-key (SKEYSEED) — ключ, который используется для последующей генерации ключей, используемых в IKE SA. Все будущие ключи IKE создаются с помощью SKEYSEED.

Второй этап называется IKE_AUTH. На этом этапе происходит проверка подлинности соседних узлов. Два сообщения обмена IKE_AUTH аутентифицируются и шифруются в рамках ассоциации безопасности IKE SA, созданной в обмене сообщениями этапа IKE_SA_INIT. 

В конце второго этапа согласования через IKE SA создается дочерняя ассоциация безопасности (CHILD SA) для защищенной передачи данных. CHILD SA — это термин IKEv2, подобный IPsec SA для IKEv1. IKEv2 работает через UDP-порты 500 и 4500 (IPsec NAT Traversal).

Дополнительные CHILD SA могут создаваться для организации нового туннеля. Этот обмен называется CREATE_CHILD_SA, в нем могут быть согласованы новые значения групп Diffie-Hellman, новые комбинации алгоритмов шифрования и хэширования.

Аутентификация узлов IPsec туннеля может происходить посредством сертификатов, использующих инфраструктуры открытых ключей (PKI) или с помощью протокола EAP (Extensible Authentication Protocol).

GRE/IPsec VPN

GRE (RFC 2784) — это протокол туннелирования, позволяющий инкапсулировать пакеты протоколов различного типа внутри IP-туннелей, благодаря чему создается виртуальный канал «точка-точка» поверх IP-сети. GRE предназначен для управления процессом передачи многопротокольного и группового IP-трафика между двумя и более площадками, между которыми связь может обеспечиваться только по IP.  При этом GRE не обеспечивает конфиденциальность и целостность передаваемых данных. Для этих целей совместно с GRE используются протоколы группы IPsec.

При совместном использовании GRE и IPsec могут быть созданы 2 типа соединений: IPsec over GRE и GRE over IPsec.

При использовании соединения IPsec over GRE происходит передача шифрованного трафика по незащищённому GRE-туннелю, т.е. сначала происходит инкапсуляция IPsec, а затем инкапсуляция GRE. Недостаток IPsec over GRE заключается в том, что не поддерживается передача многоадресных и широковещательных пакетов.

Соединение GRE over IPsec позволяет использовать преимущества GRE (поддержка многоадресной и широковещательной рассылки) и IPsec (передача трафика в зашифрованном виде). При использовании соединения GRE over IPsec происходит инкапсуляция пакетов в GRE, а затем их передача по зашифрованному каналу связи (инкапсуляция IPsec).

Для настройки GRE over IPsec необходимо выполнить следующие шаги:

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

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

При создании Site-to-Site VPN-туннелей используются протоколы L2TP/IPsec(IKEv1) или IKEv2/IPsec.

Необходимо произвести настройки соответствующих параметров на обoих граничных узлах защищенного соединения — на VPN-сервере, и на VPN-клиенте. 

Алгоритм настройки VPN-сервера

Настройка VPN-сервера на NGFW состоит из следующих основных этапов:

1. Контроль доступа зоны.

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

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

4. Создание профиля безопасности VPN.

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

6. Создание сети VPN.

7. Создание серверного правила VPN.

8. Контроль доступа к ресурсам.

Контроль доступа зоны

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

Это можно сделать в веб-консоли администратора, перейдя в раздел Сеть ➜ Зоны. Далее в настройках контроля доступа для той зоны, c которой будут подключаться VPN-клиенты, нужно разрешить сервис VPN. Как правило, это зона Untrusted. Подробнее о создании и настройках зон смотрите в статье Настройка зон.

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

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

В веб-консоли администратора зона создается в разделе Сеть ➜ Зоны. Эту зону в дальнейшем можно будет использовать в политиках безопасности. Подробнее о создании и настройках зон смотрите в статье Настройка зон.

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

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

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

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

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

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

Создание профиля безопасности VPN

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

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

Для создания профиля безопасности VPN-сервера необходимо перейти в раздел VPN ➜ Серверные профили безопасности, нажать кнопку Добавить и заполнить необходимые поля в свойствах профиля безопасности:

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

1. Версия протокола IKE (Internet Key Exchange). Возможны следующие варианты выбора поля:​​​​​

• ​​IKEv1.

• KEv2.

2. Режим работы IKE (доступно только для IKEv1). Возможны следующие варианты выбора поля:

• Основной.

• Агрессивный.

3. Тип идентификации (параметр IKE local ID). Необходим для идентификации соседнего узла при установлении VPN-соединения с оборудованием некоторых производителей. Возможные значения выбора поля:

• Отсутствует — значение поля по умолчанию. Используется в случае, когда для установления VPN-соединения не требуется использовать параметр IKE local ID. Например, для установления VPN-соединения между двумя узлами UserGate.

• IPv4 — IP-адрес узла.

• FQDN — адрес узла в формате полностью определенного доменного имени (FQDN).

• CIDR — адрес узла в формате бесклассовой адресации (CIDR).

• Значение идентификации — значение параметра IKE local ID в формате выбранного ранее типа.

4. Тип аутентификация удаленного узла при установлении защищенного соединения.

• При выборе протокола IKEv1 используется аутентификация с общим ключом (Pre-shared key). Необходимо задать общий ключ. Строка должна совпадать на VPN-сервере и VPN-клиенте для успешного подключения.

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

Далее необходимо задать криптографические параметры первой и второй фаз согласования защищенного соединения.

Во время первой фазы происходит согласование и установление IKE SA. Необходимо указать следующие параметры:

5. Время жизни ключа — по истечению данного времени происходят повторные аутентификация и согласование настроек первой фазы. 

6. Режим работы механизма Dead peer detection (DPD) — для проверки работоспособности канала и его своевременного отключения/переподключения при обрыве связи. DPD периодически отправляет сообщения R-U-THERE для проверки доступности IPsec-соседа. Возможны 3 режима работы механизма:

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

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

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

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

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

Во второй фазе осуществляется выбор способа защиты передаваемых данных в IPsec подключении. Необходимо указать следующие параметры:

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

10. Максимальный размер данных, шифруемых одним ключом — время жизни ключа может быть задано в байтах. Если заданы оба значения (Время жизни ключа и Максимальный размер данных, шифруемых одним ключом), то счётчик, первый достигнувший лимита, запустит пересоздание ключей сессии.

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

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

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

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

VPN-интерфейс в веб-консоли администратора создается в разделе Сеть ➜ Интерфейсы. Необходимо нажать кнопку Добавить и выбрать Добавить VPN, далее в настройках VPN-адаптера задать необходимые параметры: 

1. Включено — включение/отключение интерфейса.

2. Название — название интерфейса, должно быть в виде tunnelN, где N — это порядковый номер VPN-интерфейса. 

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

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

5. Алиас/Псевдоним интерфейса. Опциональный параметр.

6. Режим — тип присвоения IP-адреса. Возможные опции выбора — без адреса, статический IP-адрес или динамический IP-адрес, полученный по DHCP. Если интерфейс предполагается использовать для приема VPN-подключений (Site-2-Site VPN или Remote access VPN), то необходимо использовать статический IP-адрес.

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

8. Поле добавления IP-адреса VPN-интерфейса в случае, если выбран статический режим присвоения адреса.

Создание сети VPN

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

Сеть VPN в веб-консоли администратора создается в разделе VPN ➜ Сети VPN, Необходимо нажать кнопку Добавить и заполнить необходимые поля в свойствах VPN-сети:

1. Название сети VPN.

2. Описание сети VP. Опциональный параметр. 

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

4. Маска сети VPN.

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

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

Вкладка Маршруты для UserGate client не используется в сценарии настройки VPN для защищенного соединения офисов (Site-to-Site VPN). Она предназначена для настройки маршрутов, передаваемых UserGate Client в сценарии удаленного доступа в сеть.

Создание серверного правила VPN

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

1. Включено — включение/отключение правила VPN.

2. Название серверного правила VPN.

3. Описание серверного правила VPN. Опциональный параметр.

4. Профиль безопасности VPN — профиль безопасности, созданный ранее.

5. Сеть VPN — сеть, созданная ранее на этапе создания сети VPN.

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

7. Интерфейс — созданный ранее VPN-интерфейс.

8. Источник — зоны и адреса, с которых разрешено принимать подключения к VPN. Как правило, клиенты находятся в сети интернет, следовательно, следует указать зону Untrusted.

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

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

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

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

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

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

Алгоритм настройки VPN-клиента

Настройка VPN-клиента на NGFW состоит из следующих основных этапов:

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

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

3. Контроль доступа к ресурсам.

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

5. Создание профиля безопасности VPN.

6. Создание клиентского правила VPN.

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

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

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

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

VPN-интерфейс в веб-консоли администратора создается в разделе Сеть ➜ Интерфейсы. Необходимо нажать кнопку Добавить и выбрать Добавить VPN, далее в настройках VPN-адаптера задать необходимые параметры:

1. Включено — включение/отключение интерфейса.

2. Название — название интерфейса, должно быть в виде tunnelN, где N — это порядковый номер VPN-интерфейса. Расположенное ниже поле Описание является опциональным.

3. Зона, к которой будет относится данный интерфейс. В этом поле указывается зона, созданная ранее на этапе создания зоны для VPN подключений.

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

5. Алиас/Псевдоним интерфейса. Опциональный параметр.

6. Режим — тип присвоения IP-адреса. Возможные опции выбора — без адреса, статический IP-адрес или динамический IP-адрес, полученный по DHCP.  Для использования интерфейса в качестве клиентского VPN, необходимо использовать режим получения адреса — Динамический. При установлении соединения интерфейсу будет присвоен IP-адрес из диапазона сети VPN, сконфигурированной в настройках VPN-сервера на этапе создания сети VPN. 

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

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

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

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

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

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

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

Создание профиля безопасности VPN

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

Для создания профиля безопасности VPN-клиента необходимо перейти в раздел VPN ➜ Клиентские профили безопасности, нажать кнопку Добавить и заполнить необходимые поля в свойствах клиентского профиля безопасности:

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

1. Название клиентского профиля безопасности.

2. Описание клиентского профиля безопасности. Опциональный параметр.

3. Протокол — протокол установления VPN канала между двумя сетями. Возможны следующие варианты выбора поля:

• IPsec L2TP — для создания защищенного VPN канала с использованием L2TP и IPsec/IKEv1.  

• IPsec — для создания защищенного VPN канала с VPN-сервером с использованием IPsec/IKEv1.

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

4. Режим работы IKE. Возможны следующие варианты выбора поля:

• Основной.

• Агрессивный.

5. Тип идентификации (параметр IKE local ID). Необходим для идентификации соседнего узла при установлении VPN-соединения с оборудованием некоторых производителей. Возможные значения выбора поля:

• Отсутствует — значение поля по умолчанию. Используется в случае, когда для установления VPN-соединения не требуется использовать параметр IKE local ID. Например, для установления VPN-соединения между двумя узлами UserGate.

• IPv4 — IP-адрес узла.

• FQDN — адрес узла в формате полностью определенного доменного имени (FQDN).

• CIDR — адрес узла в формате бесклассовой адресации (CIDR).

• Значение идентификации — значение параметра IKE local ID в формате выбранного ранее типа.

6. Тип аутентификация удаленного узла при установлении защищенного соединения.

• При выборе протокола IPsec/L2TP и IPsec используется аутентификация с общим ключом (Pre-shared key). Необходимо задать общий ключ. Строка должна совпадать на VPN-сервере и VPN-клиенте для успешного подключения.

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

7. Аутентификация — логин и пароль локальной учетной записи, созданной на VPN-сервере для аутентификации узла, выступающего в роли VPN-клиента при установлении L2TP туннеля. 

8. Подсети для VPN:

• Локальная подсеть — IP-адрес разрешенной локальной подсети.

• Удаленная подсеть — IP-адрес разрешенной подсети со стороны удаленного VPN-сервера.

Далее необходимо задать криптографические параметры первой и второй фаз согласования защищенного соединения.

Во время первой фазы происходит согласование и установление IKE SA. Необходимо указать следующие параметры:

9. Время жизни ключа — по истечению данного времени происходят повторные аутентификация и согласование настроек первой фазы. 

10. Режим работы механизма Dead peer detection (DPD) — для проверки работоспособности канала и его своевременного отключения/переподключения при обрыве связи. DPD периодически отправляет сообщения R-U-THERE для проверки доступности IPsec-соседа. Возможны 3 режима работы механизма:

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

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

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

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

12. Безопасность — выбор алгоритмов аутентификации и шифрования. Для изменения порядка переместите необходимую пару вверх/вниз или используйте кнопки Выше/Ниже. 

Во второй фазе осуществляется выбор способа защиты передаваемых данных в IPsec подключении. Необходимо указать следующие параметры:

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

14. Максимальный размер данных, шифруемых одним ключом — время жизни ключа может быть задано в байтах. Если заданы оба значения (Время жизни ключа и Максимальный размер данных, шифруемых одним ключом), то счётчик, первый достигнувший лимита, запустит пересоздание ключей сессии.  

15. Безопасность — выбор алгоритмов аутентификации и шифрования. Для изменения порядка переместите необходимую пару вверх/вниз или используйте кнопки Выше/Ниже.

Создание клиентского правила VPN

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

1. Включено — включение/отключение данного правила.

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

3. Описание клиентского правила. Опциональный параметр.

4. Профиль безопасности VPN — созданный ранее клиентский профиль безопасности VPN.

5. Интерфейс — созданный ранее VPN-интерфейс.

6. Адрес сервера — адрес VPN-сервера (IP-адрес, FQDN), куда подключается данный VPN-клиент.

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

Remote Access VPN (Virtual Private Network) – виртуальная частная сеть с удаленным доступом, позволяет пользователям получать доступ к корпоративной сети своей компании. Реализует защищенное взаимодействие между сегментом корпоративной сети и одиночным пользователем, который подключается к корпоративным ресурсам через Интернет. 

UserGate Client – это программное обеспечение для организации безопасного удаленного доступа к корпоративной сети через VPN-канал. Он обеспечивает шифрование данных и защищает передачу информации между удаленным устройством и корпоративной инфраструктурой. Совместим с операционной системой Windows. Аутентификация пользователей возможна с помощью логин/пароль, двухфакторную аутентификацию (2FA) и сертификаты, что гарантирует, что только авторизованные лица получат доступ. Централизованное управление UserGate Client осуществляется через UGMC, что позволяет администраторам настраивать политики доступа, определять, какие ресурсы доступны пользователям и группам пользователей, и контролировать уровни доступа. Подробнее о UserGate Client можно узнать в статье Конечные устройства UserGate Client.

UserGate Client IPsec L2TP

В данном случае NGFW выступает в качестве VPN сервера, а пользователь с установленным ПО UserGate Client выступают в качестве клиента VPN. При создании VPN с помощью L2TP/IPsec(IKEv1), протокол L2TP создает туннель, в котором передаются пакеты сетевого уровня в кадрах PPP.  IPsec обеспечивает шифрование, аутентификацию и проверку целостности передаваемых данных.
Для этого необходимо выполнить следующие шаги:

Настройка VPN для удаленного доступа с помощью интерфейса cli

​ Шаг 1. Разрешить сервис VPN на зоне, к которой будут подключаться VPN-клиенты. 

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

Admin@UGOS# set network zone <parameters>

Подробнее о командах и параметрах для создания/редактирования зон в cli смотрите в статье Зоны.

Пример редактирования зоны Untrusted с целью разрешить сервис VPN в этой зоне:

Admin@UGOS# set network zone Untrusted enabled-services [ VPN ]

Шаг 2. Создать зону, в которую будут помещены подключаемые по VPN серверы. 

Для создания зон используется следующая команда:

Admin@UGOS# create network zone <parameters>

Подробнее о командах и параметрах для создания/редактирования зон в cli смотрите в статье Зоны.

Пример создания зоны RA_VPN:

Admin@UGOS# create network zone name RA_VPN enabled-services [ VPN ]

Шаг 3. Создать правило NAT для созданной зоны. 

Правила NAT создаются с помощью синтаксиса UPL командой:

Admin@UGOS# create network-policy nat-routing <position> upl-rule <parameters>

Подробнее о порядке настройки правил межсетевого экрана в cli смотрите в статье Настройка правил NAT и маршрутизации.

Пример создания правила NAT из зоны RA_VPN в зону Zone1:

# create network-policy nat-routing 1 upl-rule PASS \
...src.zone = RA_VPN \
...dst.zone = Zone1 \
...nat \
...rule_log(session) \
...name("RA NAT rule") \
...enabled true

Шаг 4. При необходимости создать разрешающее правило межсетевого экрана для разрешения трафика из созданной зоны в нужный сегмент сети.

Правила межсетевого экрана создаются с помощью синтаксиса UPL командой:

Admin@UGOS# create network-policy firewall <position> upl-rule <commands>

Подробнее о порядке настройки правил межсетевого экрана в cli смотрите в статье Настройка правил межсетевого экрана.

Пример создания разрешающих правил межсетевого экрана для разрешения трафика из зоны RA_VPN в зону Zone1. 

Admin@UGOS# create network-policy firewall 2 upl-rule PASS \
...src.zone = RA_VPN \
...dst.zone = Zone1 \
...rule_log(session) \
...name("RA_VPN to Zone1") \
...enabled(true)

Шаг 5. Создать профиль аутентификации для пользователей VPN. 

Подробнее о порядке создания профилей аутентификации для пользователей в cli смотрите в статье Настройка профилей аутентификации.

Пример создания сервера аутентификации LDAP с названием New ldap server для домена testd.local и профиля аутентификации с названием New profile:

Admin@UGOS# create users auth-server ldap name "New ldap server" address 192.168.1.2 domains [ test.local ] bind-dn test@test.local password 12345 enabled on

Admin@UGOS# create users auth-profile name "New profile" auth-methods ldap [ "New ldap server" ]

Шаг 6. Создать профиль безопасности VPN-сервера. 

Для создания профиля безопасности VPN-сервера используется следующая команда:

Admin@UGOS# create vpn server-security-profiles <parameters>

Подробнее о порядке создания профилей безопасности VPN в cli смотрите в статье Настройка профилей безопасности VPN.

Пример создания профиля безопасности VPN-сервера с названием "VPN-server profile 2" для L2TP/IPsec VPN: 

Admin@UGOS# create vpn server-security-profiles name "VPN-server profile 2" ike-version 1 ike-mode main psk 12345 dh-groups [ "Group 2 Prime 1024 bit" "Group 14 Prime 2048 bit" ] phase1-security [ SHA1/AES256 SHA256/AES256 ] phase2-security [ SHA1/AES256 SHA256/AES256 ]
Repeat preshared key:
Admin@UGOS#

Шаг 7. Создать VPN-интерфейс. 

Для создания VPN-интерфейса используется следующая команда:

Admin@UGOS# create network interface vpn <parameters>

Подробнее о порядке создания VPN-интерфейса в cli смотрите в статье Интерфейсы.

Пример создания VPN-интерфейса tunnel1, входящего в зону RA_VPN: 

Admin@UGOS# create network interface vpn interface-name 1 zone RA_VPN ip-addresses [ 172.30.252.1/24 ] enabled on

Шаг 8. Создать сеть VPN. 

Для создания сети VPN используется следующая команда:

Admin@UGOS# create vpn networks <parameters>

Подробнее о порядке создания сети VPN в cli смотрите в статье Настройка сетей VPN.

Пример создания сети VPN с названием "VPN network 2":

Admin@UGOS# create vpn networks name "VPN network 2" ip-range 172.30.252.2-172.30.252.254 mask 255.255.255.0 use-system-dns on routes-ip-list [ "Int net address" ]

Шаг 9. Создать серверное правило VPN. 

Правила для VPN-сервера создаются с помощью синтаксиса UPL командой:

Admin@UGOS# create vpn server-rules <position> upl-rule <commands>

Подробнее о порядке настройки серверных правил VPN в cli смотрите в статье Настройка серверных правил.

Пример создания серверного правила VPN с названием "VPN-server rule 2", в котором используются ранее созданные: профиль безопасности VPN-сервера "VPN-server profile 2", сеть VPN "VPN network 2", профиль аутентификации пользователей "New profile", VPN-интерфейс tunnel1 и список с внешним IP-адресом VPN-сервера "Ext VPN address":

Admin@UGOS# create vpn server-rules 2 upl-rule OK \
...name("VPN-server rule 2") \
...profile("VPN-server profile 2") \
...vpn_network("VPN network 2") \
...auth_profile("New profile") \
...interface(tunnel1) \
...src.zone = Untrusted
...dst.ip = lib.network("Ext VPN address")
...enabled(true)

UserGate Client IKEv2 c cертификатом

Для подключения VPN-клиентов к корпоративной сети необходимо настроить NGFW для выполнения роли VPN-сервера,  а пользователь с установленным ПО UserGate Client выступают в качестве клиента VPN. При создании VPN с помощью IKEv2/IPsec, протокол IKEv2 обменивается ключами, устанавливает и управляет защищенным соединением. Перед установкой туннеля IKEv2 IPsec, устройства должны аутентифицироваться друг перед другом, обеспечивая уверенность в том, что они являются легитимными.  Это  включает в себя использование предварительно согласованных сертификатов. Проверка сертификатов осуществляется:  

• По шифрованному каналу vpn-клиент присылает пользовательский сертификат и зашифрованные данные, подписанные приватным ключом.

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

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

• VPN-сервер осуществляет проверку отозванных сертификатов.

• VPN-сервер осуществляет проверку UPN атрибутов пользователя указанного в профиле аутентификации с атрибутами в сертификате CN и\или SAN:principal name. 

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

• Если все проверки пройдены, VPN-сервер со своей стороны отправляет свой сертификат и зашифрованные данные, подписанные своим приватным ключом, а также наличие второго фактора (если указано).

• Клиент проверяет подлиность подписи сервера и соответствие subjectAlternativeName тому адресу, куда он подключился.

Выполните следующие шаги:

UserGate Client IKEv2 аутентификации через Radius по логину-паролю 

При инициализации VPN туннеля используя протокол IKEv2/IPsec аутентификация пользователя по логину и паролю через Radius.  Для подключения VPN-клиентов к корпоративной сети необходимо настроить NGFW для выполнения роли VPN-сервера,  а пользователь с установленным ПО UserGate Client выступают в качестве клиента VPN.

VPN-клиент инициируют процесс установления VPN-туннеля с VPN-сервером, отправляя сообщении IKE_AUTH, сервер отвечает клиенту, что требуется авторизация через EAP-MSCHAPv2 . Клиент обменивается с сервером несколькими EAP-пакетами. VPN-сервер  транслирует EAP-пакетами по radius на доменный радиус-сервер, который принимает решение об аутентификации.  Далее, после того как получено положительный ответ от Radius-сервера, VPN-сервер по полученному логину запрашиваем домен на предмет этого пользователя и спрашиваем все его группы, далее принимается решение, можно ли данному пользователю подключаться к VPN-серверу.