ipsec.conf или swanctl.conf? Выберите один интерфейс strongSwan

Рабочий профиль IKEv1 из старого руководства попадает на Ubuntu 24.04, и первая попытка проваливается, потому что демон так и не прочитал файл. Обычная реакция — снова править профиль. Настоящий вопрос в том, какой интерфейс strongSwan установлен и какой использует работающая служба. Пока на это нет ответа, любая правка нацелена на загрузчик, которого может не быть.

Два файла, два загрузчика, один демон

Старая схема starter читает ipsec.conf и передаёт подключения charon через свою прежнюю интеграцию управления. Её рабочая точка входа — команда ipsec.

Схема swanctl загружает определения через VICI, читает swanctl.conf и управляется командой swanctl. Демон charon, встроенный в systemd, интегрируется с этим подходом.

Оба могут быть установлены на одной машине, и именно здесь начинается путаница. Файл в /etc доказывает лишь то, что кто-то его написал, а не то, что работающий процесс его загрузил. Установка всех вариантов, чтобы увидеть, какой работает, создаёт хост с двумя путями управления и без ясного владельца. Выберите одну схему и удалите или отключите другую.

Прочитайте установленные пакеты и unit

Начните в режиме только чтения. Имена пакетов в Ubuntu 24.04 разделены: strongswan-starter, strongswan-swanctl и charon-systemd. Отсутствующий пакет — полезная информация, а не указание его установить.

Перечислите пакеты и unit за один проход:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

Затем изучите активный unit и его команду запуска. Имя unit сообщает, какой демон владеет конфигурацией, а командная строка подтверждает, какие файлы ему было велено читать. Unit, включённый, но неактивный, рассказывает другую историю, чем тот, что работает сейчас.

Если активный unit — strongswan-starter, важен файл ipsec.conf. Если это charon-systemd с swanctl, ipsec.conf — просто украшение.

Используйте соответствующий путь управления

У каждого интерфейса свой взгляд на подключения и ассоциации. swanctl --list-conns показывает загруженные определения, а swanctl --list-sas — активные ассоциации. Старый путь использует ipsec statusall.

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

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

Формат — это не версия IKE

Старый профиль выбирает IKEv1 с помощью keyexchange=ikev1. Подключение swanctl использует настройку версии, где 1 выбирает IKEv1. Это два словаря для одной идеи, а не преобразование.

Адреса партнёра, локальные и удалённые идентичности, источники учётных данных, предложения и селекторы child нужно сопоставлять намеренно. Вставка блока left/right в синтаксис swanctl не делает ничего из этого.

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

Проверьте загрузчик, прежде чем трогать профиль

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

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

swanctl --list-conns
ipsec statusall

Только одна из этих команд относится к вашему хосту. Запуск обеих и сравнение вывода — способ узнать, какая из них лжёт вам, а не метод диагностики.

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