IKEv2 (strongSwan) на AlmaLinux 9: пошаговая установка

MAATRIX

IKEv2 — единственный из современных VPN-протоколов, который работает «из коробки» на Windows, macOS, iOS и Android без сторонних клиентов, а после разрыва сети переустанавливает туннель за секунду. На Debian и Ubuntu поднять его через strongSwan — вопрос пяти команд apt. На AlmaLinux 9 те же шаги обрастают нюансами: другой пакетный менеджер, другой фаервол и SELinux, который по умолчанию заточен под libreswan, а не под strongSwan из EPEL. Ниже — рабочая последовательность с учётом этих отличий.

Почему IKEv2 и зачем именно strongSwan

IKEv2 — это протокол согласования ключей поверх IPsec, стандартизированный IETF и встроенный нативно в клиенты всех основных ОС. В отличие от WireGuard и OpenVPN, для подключения к IKEv2 на телефоне или ноутбуке не нужно ставить приложение — достаточно системных настроек VPN. Это разница на практике: если вы настраиваете доступ для нетехнических пользователей или корпоративных устройств с ограничениями на установку софта, IKEv2 часто единственный вариант, который просто работает.

На AlmaLinux 9 IPsec-стек по умолчанию — это libreswan из репозиториев BaseOS/AppStream, и его политика SELinux уже встроена в дистрибутив. strongSwan туда не входит и ставится только из EPEL. У него более гибкий конфиг и удобная утилита pki для своего минимального CA — поэтому для ручной настройки его выбирают чаще libreswan, несмотря на то что в системе он «неродной». Расплата за гибкость — то, что SELinux-политика, написанная под пути libreswan, не всегда корректно покрывает файлы strongSwan, о чём подробно ниже.

IKEv2 передаёт данные через два UDP-порта (500 и 4500) поверх IPsec ESP, и в сетях с жёсткой блокировкой протоколов эти пакеты легко распознаются и режутся — в отличие от WireGuard, который маскируется под произвольный UDP-трафик. Если задача — обход блокировок, посмотрите в сторону WireGuard. Если задача — штатный доступ с корпоративных или семейных устройств без установки клиентов, IKEv2 подходит лучше, и дальше речь именно о нём.

Устанавливаем strongSwan через dnf и EPEL

На чистой AlmaLinux 9 сначала подключите репозиторий EPEL — без него пакета strongswan в системе нет:

sudo dnf install -y epel-release
sudo dnf makecache
sudo dnf install -y strongswan

Отличие от Debian-семейства видно уже здесь: в Ubuntu apt install strongswan работает сразу из основных репозиториев, в AlmaLinux вы обязаны сначала явно подключить EPEL — в базовые репозитории попадает только софт с полной поддержкой Red Hat, а strongSwan туда не входит (вместо него в BaseOS есть libreswan).

После установки проверьте имя systemd-юнита — в разных сборках пакета это strongswan или strongswan-starter:

systemctl list-unit-files | grep -i strong

Дальше используется имя strongswan; если у вас другое — подставляйте его в команды systemctl. Включите автозапуск, но пока не стартуйте — сначала нужен конфиг и сертификаты:

sudo systemctl enable strongswan

Включите форвардинг пакетов — без него сервер не будет маршрутизировать трафик клиентов дальше себя:

echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/99-ipsec.conf
sudo sysctl -p /etc/sysctl.d/99-ipsec.conf

Готовим свой мини-CA и сертификаты сервера

Для сертификатной аутентификации сервера (самый совместимый вариант для нативных клиентов) strongSwan идёт со встроенной утилитой pki — отдельный easy-rsa, как в OpenVPN, не нужен. Создайте рабочую директорию и корневой сертификат:

mkdir -p ~/pki/{cacerts,certs,private}
chmod 700 ~/pki

ipsec pki --gen --type rsa --size 4096 --outform pem > ~/pki/private/caKey.pem
ipsec pki --self --ca --lifetime 3650 \
  --in ~/pki/private/caKey.pem --type rsa \
  --dn "CN=VPN Root CA" \
  --outform pem > ~/pki/cacerts/caCert.pem

Теперь ключ и сертификат сервера, подписанный этим CA. --san обязателен — большинство клиентов, включая macOS и iOS, проверяют Subject Alternative Name на совпадение с адресом, на который подключаются:

ipsec pki --gen --type rsa --size 4096 --outform pem > ~/pki/private/serverKey.pem

ipsec pki --pub --in ~/pki/private/serverKey.pem --type rsa \
  | ipsec pki --issue --lifetime 1825 \
      --cacert ~/pki/cacerts/caCert.pem \
      --cakey ~/pki/private/caKey.pem \
      --dn "CN=vpn.example.com" \
      --san "vpn.example.com" \
      --flag serverAuth --flag ikeIntermediate \
      --outform pem > ~/pki/certs/serverCert.pem

Замените vpn.example.com на реальный домен или, если домена нет, на публичный IP (тогда и --san указывайте как IP). Скопируйте файлы в директорию strongSwan и закройте приватный ключ:

sudo cp ~/pki/cacerts/caCert.pem /etc/strongswan/ipsec.d/cacerts/
sudo cp ~/pki/certs/serverCert.pem /etc/strongswan/ipsec.d/certs/
sudo cp ~/pki/private/serverKey.pem /etc/strongswan/ipsec.d/private/
sudo chmod 600 /etc/strongswan/ipsec.d/private/serverKey.pem

Файл caCert.pem вам ещё понадобится отдельно — его нужно будет установить на каждое клиентское устройство как доверенный корневой сертификат.

Настраиваем ipsec.conf и ipsec.secrets

Самый практичный вариант для смешанного парка устройств (Windows, macOS, iOS) — сертификат на сервере плюс логин/пароль на клиенте через EAP-MSCHAPv2. Это позволяет заводить пользователей без выпуска клиентских сертификатов на каждое устройство. Отредактируйте /etc/strongswan/ipsec.conf:

config setup
    charondebug="ike 1, cfg 1"
    uniqueids=no

conn ikev2-vpn
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=@vpn.example.com
    leftcert=serverCert.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightsourceip=10.10.10.0/24
    rightdns=1.1.1.1,8.8.8.8
    eap_identity=%identity

leftid должен совпадать с CN/SAN из сертификата сервера. rightsourceip — подсеть, из которой клиентам будут выдаваться внутренние адреса; выберите диапазон, не пересекающийся с вашей локальной сетью. Учётные данные пользователей и приватный ключ сервера идут в /etc/strongswan/ipsec.secrets:

: RSA serverKey.pem
ivan : EAP "СложныйПароль123"
maria : EAP "ЕщёОдинПароль456"

Каждая строка после ключа сервера — отдельный пользователь. Пароли лежат в открытом виде, поэтому проверьте chmod 600 /etc/strongswan/ipsec.secrets. После правок перезапустите службу и проверьте статус:

sudo systemctl restart strongswan
sudo ipsec statusall

Firewalld вместо ufw: что открыть для IKEv2

Здесь второе крупное отличие от Debian-семейства: там вы работали бы с ufw и открывали порты по номерам, здесь — firewalld с зонами и именованными службами. У firewalld есть готовая служба ipsec, которая сразу открывает всё необходимое для IKEv2 — порты 500 и 4500/udp:

sudo firewall-cmd --permanent --add-service=ipsec
sudo firewall-cmd --permanent --add-masquerade
sudo firewall-cmd --reload

--add-masquerade включает NAT в активной зоне — без него клиенты подключатся к серверу, но не получат доступ в интернет через туннель, потому что их пакеты с внутренним VPN-адресом не смогут выйти наружу с публичного IP сервера. Проверить результат:

sudo firewall-cmd --list-all

В выводе должны быть служба ipsec и masquerade: yes. Если сервер стоит за NAT провайдера или в облаке с отдельным сетевым фаерволом (security group), откройте те же 500/udp и 4500/udp и там — firewalld на сервере не отменяет правил на уровне облачной инфраструктуры. Подробный разбор зон, permanent/runtime и rich rules — в статье про настройку фаервола на AlmaLinux 9.

SELinux и IPsec: где спотыкается strongSwan из EPEL

Именно из-за этого пункта связка strongSwan + AlmaLinux чаще всего и ломается. SELinux-политика для IPsec в RHEL-семействе исторически писалась под libreswan — его пути (/etc/ipsec.d, /etc/ipsec.conf) промаркированы штатными типами вроде ipsec_conf_file_t и ipsec_key_file_t, а демон работает в домене ipsec_t. strongSwan из EPEL использует свой набор путей (/etc/strongswan/...), и хотя пакет расставляет метки при установке, после ручного копирования сертификатов командой cp они часто слетают — файл наследует контекст родительской директории пользователя, а не целевой.

Если после systemctl restart strongswan туннель не поднимается, а конфиг выглядит правильным, первым делом смотрите отказы SELinux, а не сам strongSwan:

sudo ausearch -m avc -ts recent | grep denied

Если денаилы есть — самое надёжное решение восстановить корректные метки на файлы strongSwan, а не сочинять исключения вручную:

sudo restorecon -Rv /etc/strongswan/

Если после restorecon денаилы продолжаются и относятся к конкретной булевой политике, посмотрите, какие булевы флаги, связанные с IPsec, вообще есть в вашей системе — их набор зависит от версии selinux-policy, поэтому называть конкретное имя без проверки на месте смысла нет:

sudo semanage boolean -l | grep -i ipsec

Найденный релевантный флаг включается через setsebool -P <имя> on (флаг -P делает изменение постоянным). Проверить, действительно ли причина в SELinux, можно временным переключением в permissive-режим — если туннель после этого поднимается, дело в политике, и дальше её нужно точечно донастроить, а не оставлять систему в permissive насовсем:

sudo setenforce 0
# проверяете, поднимается ли туннель
sudo setenforce 1

Постоянно отключать SELinux ради одного сервиса — плохая практика: вы теряете защиту всей остальной системы ради удобства настройки одного демона. Базовые принципы работы с SELinux на AlmaLinux 9 разобраны в статье про базовую защиту от взлома.

Подключаем клиентов: Windows, macOS, iOS и Android

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

Windows. Импортируйте caCert.pem в хранилище «Доверенные корневые центры сертификации» (двойной клик по файлу → certmgr.msc), затем создайте подключение через PowerShell:

Add-VpnConnection -Name "IKEv2-VPN" -ServerAddress "vpn.example.com" `
  -TunnelType IKEv2 -AuthenticationMethod EAP -EncryptionLevel Required `
  -RememberCredential

При первом подключении Windows запросит логин и пароль — те же, что в ipsec.secrets.

macOS. Дважды кликните по caCert.pem, добавьте его в связку ключей и вручную отметьте доверие для IP Security. Затем «Системные настройки → Сеть → добавить VPN → тип IKEv2», укажите адрес сервера, удалённый ID (vpn.example.com) и учётные данные пользователя.

iOS. Удобнее всего собрать .mobileconfig-профиль с адресом сервера и корневым сертификатом и раздать его пользователям — не придётся вводить всё вручную на каждом устройстве. Вручную: «Настройки → VPN → Добавить конфигурацию → IKEv2», без клиентского сертификата, только логин/пароль, плюс заранее установленный caCert.pem.

Android. Нативная поддержка IKEv2 ограничена, нормально работает только приложение strongSwan из Google Play: импортируете caCert.pem, указываете сервер, тип аутентификации EAP и учётные данные.

Проверить на сервере, что клиент подключён, можно командой sudo ipsec statusall — в выводе появится активное security association с его IP из подсети rightsourceip.

Частые вопросы