ipsec.conf или swanctl.conf? Изберете един интерфейс на strongSwan
ipsec.conf и swanctl.conf принадлежат на различни зареждачи на strongSwan. Определете работещата услуга, преди да превеждате стар профил IKEv1.
Работещ профил IKEv1 от по-стар наръчник попада на Ubuntu 24.04 и първият опит се проваля, защото демонът така и не прочете файла. Обичайната реакция е профилът да се редактира отново. Истинският въпрос е кой интерфейс на strongSwan е инсталиран и кой използва работещата услуга. Докато това не е изяснено, всяка редакция е насочена към зареждач, който може да не съществува.
Два файла, два зареждача, един демон
Старата схема starter чете ipsec.conf и предава връзките на charon чрез своята стара интеграция за управление. Нейната оперативна входна точка е командата ipsec.
Схемата swanctl зарежда дефиниции през VICI, чете swanctl.conf и се управлява от командата swanctl. Вграденият в systemd демон charon се интегрира с този подход.
И двете могат да са инсталирани на една и съща машина и точно там започва объркването. Файл в /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
Само една от тези команди принадлежи на вашия хост. Изпълняването и на двете и сравняването на изхода е начин да откриете коя ви лъже, а не метод за диагностика.
Третирайте собствеността на пакетите, зареждането на конфигурацията и съвместимостта на протокола като три отделни въпроса. Файл, валиден за един интерфейс, иначе ще се редактира отново и отново, докато работи друг демон.