ipsec.conf ці swanctl.conf? Выберыце адзін інтэрфейс strongSwan

Працоўны профіль IKEv1 са старога кіраўніцтва трапляе на Ubuntu 24.04, і першая спроба правальваецца, бо дэман так і не прачытаў файл. Звычайная рэакцыя — зноў рэдагаваць профіль. Сапраўднае пытанне: які інтэрфейс strongSwan усталяваны і які выкарыстоўвае працуючы сэрвіс. Пакуль на гэта не адказана, кожная праўка накіравана на загрузчык, якога можа не існаваць.

Два файлы, два загрузчыкі, адзін дэман

Старая схема starter чытае ipsec.conf і перадае злучэнні charon праз сваю старую інтэграцыю кіравання. Яе працоўная кропка ўваходу — каманда ipsec.

Схема swanctl загружае азначэнні праз VICI, чытае swanctl.conf і кіруецца камандай swanctl. Дэман charon, убудаваны ў systemd, інтэгруецца з гэтым падыходам.

Абодва могуць быць усталяваны на адной машыне, і менавіта тут пачынаецца блытаніна. Файл у /etc даказвае толькі тое, што хтосьці яго напісаў, а не тое, што працуючы працэс яго загрузіў. Усталяванне ўсіх варыянтаў, каб пабачыць, які працуе, стварае хост з двума шляхамі кіравання і без яснага гаспадара. Абярыце адну схему і выдаліце або адключыце другую.

Прачытайце ўсталяваныя пакеты і юніты

Пачніце з рэжыму толькі чытання. Назвы пакетаў у Ubuntu 24.04 асобныя: strongswan-starter, strongswan-swanctl і charon-systemd. Адсутны пакет — гэта карысная інфармацыя, а не ўказанне яго ўсталёўваць.

Пералічыце пакеты і юніты за адзін праход:

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

Затым агледзьце актыўны юніт і яго каманду запуску. Назва юніта паказвае, які дэман валодае канфігурацыяй, а камандны радок пацвярджае, якія файлы яму было загадана чытаць. Юніт, уключаны, але неактыўны, расказвае іншую гісторыю, чым той, што працуе зараз.

Калі актыўны юніт — 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

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

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