Варианты конфигурации и сценарии настройки strongSwan

Рекомендуемый способ настройки strongSwan – через мощный интерфейс управления vici и утилиту командной строки swanctl. Файл конфигурации swanctl.conf, используемый swanctl, хранится вместе с сертификатами и соответствующими закрытыми ключами в каталоге swanctl.

Глобальные параметры strongSwan, а также настройки отдельных плагинов заданы в файле strongswan.conf.

В качестве альтернативы можно использовать унаследованный интерфейс управления stroke и утилиту командной строки ipsec с устаревшими файлами конфигурации ipsec.conf и ipsec.secrets.

Конфигурацию можно также загрузить из базы данных SQL или предоставляться пользовательскими (кастомными) плагинами. При использовании варианта демона charon-nm управление VPN-подключениями может выполняться через NetworkManager.

Процесс установки strongSwan описан в отдельном документе.

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

ПО strongSwan обычно управляют с помощью команды swanctl, тогда как демон IKE charon контролируется через systemd на современных дистрибутивах. В устаревших установках strongSwan управляется командой ipsec, где ipsec start запускает демон starter, который в свою очередь запускает и настраивает демон управления ключами charon.

IKE-соединения и CHILD_SA, определённые в swanctl.conf, можно запускать тремя способами:

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

Поскольку такие клиенты, скорее всего, подключаются с неизвестных IP-адресов, шлюз использует параметр remote_addrs = %any, чтобы принимать подключения буквально откуда угодно. Для упрощения направления трафика обратно к клиентам, а также потому, что клиенты-roadwarrior часто пользуются одним или несколькими устройствами с преобразованием сетевых адресов (Network Address Translation, или NAT-устройствами), необходимо пользоваться виртуальными IP-адресами.

Виртуальные IP-адреса могут быть получены от определенной подсети или даже от подсети за шлюзом с помощью плагина farp или, при желании, плагина dhcp.

Также важно решить, будут ли клиенты-roadwarrior отправлять весь трафик через шлюз или использовать раздельное туннелирование (split-tunneling), т.е. отправлять через туннель трафик только к определённым адресам получателя. Подробнее это объясняется в разделе «Перенаправление трафика и раздельное туннелирование», где также описывается, каким образом трафик направляется к хостам за шлюзом.

Приведенные ниже три конфигурации шлюза strongSwan для клиентов Windows могут также использоваться всеми клиентами IKEv2:

Во всех трёх случаях шлюз аутентифицируется с помощью сертификата, а клиенты подтвержают свою подлинность либо с помощью сертификатов (варианты 1 и 2), либо комбинацией «имя пользователя/пароль» (вариант 3). Общий сценарий EAP (3) включает в себя сценарий EAP-TLS (2), поэтому на VPN-шлюзе strongSwan необходимо применить только две конфигурации (1 и 3), оставляя выбор конкретного метода аутентификации из данных трех за VPN-клиентами.

С помощью плагина eap-radius аутентификация пользователей может делегироваться серверу RADIUS (например, контроллеру домена службы активных каталогов Active Directory Domain Controller, или AD DC).

Оба клиентских приложения strongSwan VPN Client for Android и NetworkManager работают с любой конфигурацией VPN-шлюза strongSwan. Как вариант, командная строка charon-cmd предоставляет простой способ установления подключений типа roadwarrior.

Наше приложение для macOS поддерживает протокол IKEv2 и простую аутентификацию типа EAP. Протокол IKEv2 поддерживается в клиентах Apple, начиная с внедрения операционных систем iOS 8 и macOS 10.10. Графический интерфейс для настройки таких подключений в настоящее время отсутствует, поэтому необходимо создавать (или генерировать) пользовательские профили конфигурации.

Мы приводим следующие примеры конфигураций site-to-site.

Главное отличие от сценария удалённого доступа заключается в том, что инициатор соединения не запрашивает виртуальный IP-адрес, а использует параметр local_ts для туннелирования трафика от одной или нескольких локальных подсетей. В рамках протокола IKEv2 (в нотации CIDR) в параметры local_ts/remote_ts можно добавить несколько подсетей, разделив их запятыми. Если Вы используете протокол IKEv1, необходимо добавить отдельный подраздел children.<child> для каждой комбинации локальной и удалённой подсети, так как будет использоваться только первая подсеть в local_ts/remote_ts.

Новых пользователей IPsec часто дезориентирует то обстоятельство, что при тестировании сценария net-to-net с любого из двух шлюзов часто необходимо точно указывать исходный адрес (например, с помощью ping -I), так как внешний IP-адрес любого из двух шлюзов может не определяться туннелируемыми подсетями. Если возникнет такая необходимость, добавьте внешние IP-адреса в список подсетей в параметрах local_ts/remote_ts или создайте отдельную конфигурацию host-to-host.

Подключения host-to-host настроить очень просто. Необходимо лишь указать переменную remote_addrs как имя хоста или IP-адрес удалённого узла и настроить требуемый метод аутентификации. Прямая настройка селекторов трафика local_ts и remote_ts не требуется.

На нашем сайте также представлены практические примеры конфигураций host-to-host.

Следующая страница: Анализ производительности и варианты оптимизации strongSwan.