L2TP/IPsec через Libreswan: альтернатива strongSwan

MAATRIX

Почти все мануалы по L2TP/IPsec в интернете написаны под strongSwan — он популярнее, у него больше документации и примеров. Но если сервер стоит на RHEL, AlmaLinux, Rocky или CentOS, разумный выбор — Libreswan, а не strongSwan, и не по вкусовым причинам: именно Libreswan там идёт в базовых репозиториях, поддерживается вендором и завязан на системные компоненты вроде NetworkManager. Ниже — чем Libreswan отличается от strongSwan на практике, когда он предпочтительнее, и как выглядит установка L2TP/IPsec на нём.

Почему это вообще выбор, а не деталь

strongSwan и Libreswan — это два независимых, полноценных стека IPsec под Linux, оба поддерживают IKEv1 и IKEv2, оба умеют L2TP/IPsec, оба активно развиваются. С точки зрения протокола разницы для клиента нет — Windows, macOS, iOS и Android подключаются одинаково независимо от того, что стоит на сервере. Разница — в экосистеме вокруг демона: откуда он берётся, кто его тестирует под конкретный дистрибутив и с чем он интегрирован.

Libreswan — это форк более старого проекта Openswan, разрабатывается при заметном участии Red Hat и годами поставляется как часть RHEL. Отсюда и практическое следствие: на RHEL-совместимых системах именно Libreswan лежит в базовых репозиториях (BaseOS), его использует под капотом NetworkManager для собственных IPsec-подключений, и он проходит через тот же цикл тестирования и патчей безопасности, что и вся остальная система. strongSwan на этих дистрибутивах в стандартные репозитории не входит — его приходится собирать самостоятельно или подключать сторонний репозиторий (например, EPEL его тоже не содержит), а значит — самостоятельно следить за обновлениями безопасности вне обычного цикла dnf update.

На Debian и Ubuntu ситуация обратная: там в стандартных репозиториях как раз strongSwan, и городить Libreswan там не имеет смысла — для этих систем есть отдельные мануалы по L2TP/IPsec на Debian 12 и по L2TP/IPsec на Ubuntu 24.04, где используется именно он. Правило простое: на RHEL-семействе — Libreswan, на Debian-семействе — strongSwan, если нет специфической причины ставить иначе.

Чем отличаются конфигурации на практике

Оба демона используют один и тот же формат конфигурации — ipsec.conf с секциями config setup и conn, плюс файл ipsec.secrets с ключами. Это наследие общего происхождения от FreeS/WAN, и для человека, который когда-то настраивал strongSwan, синтаксис Libreswan будет узнаваем почти построчно. Но есть нюансы, которые ловят именно на миграции между ними.

Главное отличие в работе — сам процесс. У strongSwan это charon, у Libreswan — pluto (тоже унаследовано от старого FreeS/WAN, но развивавшееся отдельной веткой). Это значит, что имена процессов в ps aux, обработчики в SELinux-политиках и записи в journalctl -u ipsec будут разными, и мануал под один демон нельзя применить ко второму, просто заменив имя пакета в командах установки — придётся сверять и опции внутри conn.

Ещё одна практическая деталь: у Libreswan есть встроенная команда самодиагностики ipsec verify, которая перед запуском проверяет форвардинг пакетов, права на файлы конфигурации и базовую сетевую готовность — и прямо указывает, что настроено неверно. У strongSwan прямого аналога нет, там обычно смотрят логи через journalctl -u strongswan и swanctl --list-conns.

Установка Libreswan и xl2tpd на RHEL-семействе

Схема одинакова для RHEL 9, AlmaLinux 9, Rocky Linux 9 и CentOS Stream 9 — все они используют один набор репозиториев. Сначала подключите EPEL — он нужен для xl2tpd, реализации L2TP-туннелирования, которой в базовых репозиториях нет:

sudo dnf update -y
sudo dnf install -y epel-release
sudo dnf install -y libreswan xl2tpd ppp
rpm -q libreswan xl2tpd

Обратите внимание: libreswan ставится без стороннего репозитория, прямо из BaseOS, а xl2tpd — из EPEL. strongSwan в этой команде намеренно нет: если бы вы решили ставить его вместо Libreswan на этой же системе, пришлось бы отдельно собирать пакет из исходников или подключать сторонний репозиторий вроде тех, что предлагают сторонние проекты — с соответствующими рисками отставания от апстрима по патчам безопасности.

Конфигурация IPsec под Libreswan

Основные параметры — в /etc/ipsec.conf:

config setup
    protostack=netkey
    nat_traversal=yes
    virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.10.10.0/24
    uniqueids=no

Само соединение L2TP/IPsec вынесите в отдельный файл /etc/ipsec.d/l2tp-psk.conf — это стандартная для Libreswan практика хранить каждое соединение отдельным файлом в ipsec.d, в отличие от strongSwan, где чаще всё держат в одном ipsec.conf:

conn l2tp-psk
    authby=secret
    pfs=no
    auto=add
    keyingtries=3
    rekey=no
    ikelifetime=8h
    keylife=1h
    type=transport
    left=%defaultroute
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
    dpddelay=30
    dpdtimeout=120
    dpdaction=clear

type=transport здесь принципиален: шифруется только сам L2TP-трафик поверх уже установленного соединения, без создания отдельной туннельной IP-сети на уровне IPsec — именно эту комбинацию ожидает связка Libreswan + xl2tpd. PSK-ключ пропишите в /etc/ipsec.secrets:

%any %any: PSK "ваш-длинный-случайный-ключ"

Сгенерировать ключ: openssl rand -base64 24. Перед запуском включите форвардинг и отключите параметры ядра, которые типично мешают L2TP/IPsec на VPS с несколькими интерфейсами:

cat <<'EOF' | sudo tee /etc/sysctl.d/99-ipsec.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
EOF
sudo sysctl -p /etc/sysctl.d/99-ipsec.conf

Запустите службу и сразу прогоните встроенную диагностику — то самое преимущество Libreswan, о котором говорилось выше:

sudo systemctl enable --now ipsec
sudo ipsec verify

Если ipsec verify жалуется на форвардинг или права доступа — это значит, что предыдущие шаги нужно перепроверить, прежде чем идти дальше.

xl2tpd, firewalld и SELinux — общая часть для любого IPsec-стека

Дальше настройка практически не зависит от того, что стоит под IPsec — Libreswan или strongSwan: xl2tpd, chap-secrets, порты 500/4500/1701 и SELinux-политики работают с обоими одинаково, потому что xl2tpd — отдельный от IPsec процесс, взаимодействующий с ним только через loopback-интерфейс. Конфиг /etc/xl2tpd/xl2tpd.conf:

[global]
port = 1701

[lns default]
ip range = 10.10.10.10-10.10.10.20
local ip = 10.10.10.1
refuse chap = yes
refuse pap = yes
require authentication = yes
name = L2TPServer
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

Порты в firewalld:

sudo firewall-cmd --permanent --add-port=500/udp
sudo firewall-cmd --permanent --add-port=4500/udp
sudo firewall-cmd --permanent --zone=trusted --add-interface=lo
sudo firewall-cmd --permanent --add-masquerade
sudo firewall-cmd --reload

--zone=trusted --add-interface=lo — частая причина, по которой IKE проходит, PSK принимается, а сама L2TP-сессия не поднимается: xl2tpd получает расшифрованный трафик через loopback, и если он не в доверенной зоне, firewalld фильтрует его так же, как внешний. Порт 1701/udp наружу открывать не нужно — извне на него никто не обращается.

По SELinux разница между демонами более заметна: политики для процесса pluto (Libreswan) идут в комплекте с самим пакетом и покрывают стандартные порты и пути без доп. настройки. Для strongSwan на RHEL-семействе, если вы всё же ставите его вместо Libreswan, готовых политик может не быть вообще — SELinux-модуль для charon не входит в типовую сборку, и придётся либо писать локальную политику через audit2allow, либо (что хуже) переводить SELinux в permissive. Это ещё один практический аргумент в пользу Libreswan на RHEL-семействе — там всё интегрировано с самого начала. Подробный разбор установки этой же схемы шаг за шагом — в статье про L2TP/IPsec на AlmaLinux 9, там же — таблица типичных ошибок SELinux и точечные команды semanage/audit2allow.

Когда всё же стоит взять strongSwan вместо Libreswan

Libreswan — не универсально лучший выбор, а лучший выбор именно для RHEL-семейства. Если у вас Debian или Ubuntu, картина обратная — там штатно доступен strongSwan, и разворачивать на этих системах Libreswan — то же самое, что ставить strongSwan на AlmaLinux: без штатной интеграции, с ручным подключением репозитория.

Есть и более специфичные случаи в пользу strongSwan даже на RHEL-семействе: если вам нужна сложная IKEv2-инфраструктура с сертификатами, EAP-аутентификацией через RADIUS или множеством одновременных site-to-site туннелей с разной топологией — у strongSwan богаче экосистема готовых интеграций и обширнее документация именно по таким сценариям, накопленная за счёт большей популярности в enterprise-окружениях за пределами RHEL. Для простого личного L2TP/IPsec-сервера с PSK и парой пользователей эта разница не имеет значения — обе реализации справляются одинаково хорошо, а на AlmaLinux/Rocky Libreswan будет ещё и меньше головной боли с обновлениями.

Если протокол вообще не принципиален и вы выбираете VPN с нуля, а не подключаетесь к корпоративному стандарту — сравните L2TP/IPsec с более современными вариантами в статье WireGuard или OpenVPN: что выбрать для сервера. L2TP/IPsec имеет смысл конкретно тогда, когда нужна нативная поддержка ОС без стороннего клиента — иначе WireGuard почти всегда быстрее и проще в обслуживании.

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