ipsec.conf czy swanctl.conf? Wybierz jeden frontend strongSwan

Działający profil IKEv1 ze starszego poradnika trafia na Ubuntu 24.04 i pierwsza próba kończy się niepowodzeniem, bo demon nigdy nie odczytał pliku. Zwykłą reakcją jest ponowne edytowanie profilu. Prawdziwe pytanie brzmi, który frontend strongSwan jest zainstalowany i którego używa działająca usługa. Dopóki nie ma na to odpowiedzi, każda zmiana trafia w loader, którego może nie być.

Dwa pliki, dwa loadery, jeden demon

Stary układ starter czyta ipsec.conf i przekazuje połączenia do charona przez swoją starą integrację zarządzania. Jego punktem wejścia jest polecenie ipsec.

Układ swanctl ładuje definicje przez VICI, czyta swanctl.conf i jest sterowany poleceniem swanctl. Demon charon natywny dla systemd integruje się z tym podejściem.

Oba mogą być zainstalowane na tej samej maszynie i właśnie tam zaczyna się zamieszanie. Plik pod /etc dowodzi tylko, że ktoś go napisał, a nie że działający proces go wczytał. Instalowanie każdej alternatywy, aby zobaczyć, która działa, tworzy host z dwiema ścieżkami zarządzania i bez jasnego właściciela. Wybierz jeden układ i usuń lub wyłącz drugi.

Odczytaj zainstalowane pakiety i unity

Zacznij w trybie tylko do odczytu. Nazwy pakietów w Ubuntu 24.04 są osobne: strongswan-starter, strongswan-swanctl i charon-systemd. Brakujący pakiet to użyteczna informacja, a nie polecenie jego instalacji.

Zinwentaryzuj pakiety i unity w jednym przejściu:

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

Następnie sprawdź aktywny unit i jego polecenie uruchamiania. Nazwa unitu mówi, który demon posiada konfigurację, a wiersz poleceń potwierdza, które pliki miał odczytać. Unit włączony, ale nieaktywny, opowiada inną historię niż ten, który działa teraz.

Jeśli aktywnym unitem jest strongswan-starter, liczy się plik ipsec.conf. Jeśli to charon-systemd z swanctl, ipsec.conf jest tylko ozdobą.

Użyj odpowiedniej ścieżki sterowania

Każdy frontend ma własny widok połączeń i asocjacji. swanctl --list-conns pokazuje wczytane definicje, a swanctl --list-sas aktywne asocjacje. Stara ścieżka używa ipsec statusall.

Mieszanie ich daje mylące błędy. Brakujące gniazdo VICI lub odrzucone żądanie sterowania to problem ścieżki zarządzania, a nie dowód, że druga strona odrzuciła uwierzytelnienie.

Odczytaj widok, który należy do działającego demona, a następnie zinterpretuj wynik. Jeśli połączenia nie ma w tym widoku, problem leży we wczytywaniu, a nie w negocjacji.

Format to nie wersja IKE

Stary profil wybiera IKEv1 przez keyexchange=ikev1. Połączenie swanctl używa ustawienia wersji, w którym 1 wybiera IKEv1. To dwa słowniki dla tego samego pomysłu, a nie konwersja.

Adresy drugiej strony, tożsamości lokalne i zdalne, źródła poświadczeń, propozycje i selektory child trzeba mapować świadomie. Wklejenie bloku left/right do składni swanctl nie robi niczego z tego.

Zmiana tylko wersji protokołu to najczęstsza połowiczna migracja. Daje plik, który się wczytuje, a potem nie przechodzi uwierzytelnienia z powodów niezwiązanych z wersją. Sam IKEv1 jest przestarzały zgodnie z RFC 9395, więc istniejący partner, który nadal go wymaga, zasługuje na udokumentowane ograniczenie zgodności i ścieżkę migracji, a nie nową wartość domyślną.

Sprawdź loader, zanim dotkniesz profilu

Najpierw uruchom kontrolę loadera, potem wczytaj zamierzone połączenie, następnie oceń negocjację, a na końcu ścieżkę chronionego ruchu. Każdy etap ma inny podpis awarii.

Obie ścieżki sterowania odpowiadają wprost na pytanie o wczytywanie:

swanctl --list-conns
ipsec statusall

Tylko jedno z tych poleceń należy do twojego hosta. Uruchomienie obu i porównanie wyniku to sposób na odkrycie, które ci kłamie, a nie metoda diagnostyczna.

Traktuj własność pakietów, wczytywanie konfiguracji i zgodność protokołu jako trzy osobne pytania. Plik ważny dla jednego frontendu będzie inaczej edytowany raz za razem, podczas gdy działa inny demon.