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

Лише одна з цих команд належить вашому хосту. Запуск обох і порівняння виводу — це спосіб дізнатися, яка з них вам бреше, а не метод діагностики.

Розглядайте належність пакетів, завантаження конфігурації та сумісність протоколу як три окремі питання. Файл, чинний для одного інтерфейсу, інакше редагуватиметься знову і знову, поки працює інший демон.