Załadowany profil strongSwan to nie aktywny tunel
strongSwan wczytuje definicje, a następnie negocjuje SA IKE i CHILD. To, że profil jest załadowany, nie mówi nic o tym, czy tunel istnieje ani kto go uruchamia.
Wymienienie połączenia w konfiguracji strongSwan dowodzi tylko, że wczytano definicję. Nie oznacza to, że skontaktowano się z peerem, że istnieje SA IKE ani że jakikolwiek ruch jest chroniony. Demon traktuje definicje i żywe asocjacje jako osobne obiekty, a odległość między nimi jest świadomą decyzją projektową. Wiedza o tym, który obiekt sprawdzasz, zamienia niejasną awarię w konkretne następne polecenie.
Ładowanie to nie łączenie
Załadowane połączenie to stwierdzenie, co będzie można wynegocjować później: adresy peera, poświadczenia, propozycje i selektory ruchu. Nic w tym stwierdzeniu nie wymaga, aby demon do kogokolwiek zadzwonił. Brama może czekać na drugą stronę, inicjować przy starcie albo czekać, aż obudzi ją pasujący ruch. Wszystkie trzy są poprawne i wszystkie trzy wyglądają identycznie w pliku konfiguracyjnym, dopóki nie przeczytasz polityki startu.
Operatorzy wpadają w kłopoty, czytając listę definicji jako listę stanów. Profil jest, więc uznaje się, że tunel działa, a następna godzina idzie na debugowanie tras dla asocjacji, która nigdy nie powstała.
Odwrotny błąd jest równie częsty. Brakujący profil wysyła ludzi na poszukiwanie awarii sieci, choć konfiguracja nigdy się nie wczytała. Nazwij obiekt, a potem uruchom polecenie, które go obserwuje.
Trzy obiekty, trzy obserwacje
strongSwan utrzymuje wczytaną definicję, SA IKE i SA CHILD. Pierwsza to konfiguracja, druga to uwierzytelniona relacja sterująca, a trzecia to wynegocjowana ochrona wybranego ruchu. Mają nawet osobne nazwy, więc profil o nazwie hq może mieć child o nazwie hq-lan.
Tabela przypisuje każdej warstwie polecenie, które ją pokazuje. Przeczytaj wiersz, zanim przeczytasz log.
| Layer | What it contains | Command |
|---|---|---|
| Definition | Peer addresses, credentials, proposals, and traffic selectors | swanctl --list-conns |
| IKE SA | One authenticated control channel to the peer | swanctl --list-sas |
| CHILD SA | Keys and selectors for the traffic being protected | Child rows under the IKE SA |
Zażądanie child tworzy najpierw jego nadrzędne SA IKE, gdy żadne nie istnieje. Zażądanie samego SA IKE to inne wywołanie. Kanał sterujący, który poprawnie się uwierzytelnia, nie gwarantuje child, o który prosiłeś.
Ta różnica ma znaczenie przy częściowej awarii. SA IKE może być zdrowe, podczas gdy child zawodzi na niezgodności selektora lub propozycji, której peer nie zaakceptuje. Oba obiekty zawodzą z różnych powodów, więc zasługują na osobne obserwacje.
Wybierz akcję startu świadomie
W swanctl.conf start_action childa decyduje o zachowaniu po załadowaniu. Domyślna wartość none zostawia definicję do ręcznego uruchomienia lub użycia jako responder. start wybiera ją, natomiast trap zostawia politykę, która negocjuje, gdy tylko pojawi się pasujący ruch.
Zatem zarówno „ładowanie nigdy nie uruchamia tunelu”, jak i „ładowanie zawsze go uruchamia” są błędne. Akcja jest częścią profilu i powinna pasować do roli peera. Dwie bramy, które obie czekają na drugą stronę, dają ciszę, a nie tunel.
Przy trap ruch musi pasować do selektorów, więc niepowiązany ping niczego nie obudzi. Przy start adres peera musi być użyteczny, a obie strony muszą się zgodzić co do uwierzytelniania i propozycji. Żadna z akcji nie zastępuje sprawdzenia tych warunków.
Odzyskiwanie to osobna polityka
Start to nie keepalive. Wykrywanie martwego peera, jawne zamknięcie przez peera, wymiana kluczy i restart procesu to różne zdarzenia cyklu życia z własnymi ustawieniami. Skonfiguruj każde z nich świadomie, zamiast oczekiwać, że początkowy start obejmie je wszystkie.
Tunel, który wstaje przy starcie i umiera godzinę później, to kwestia odzyskiwania. Polityka startu zrobiła swoje i przestała mieć znaczenie. Spójrz na ustawienia DPD i wymiany kluczy, zanim obwinisz początkową negocjację.
Zastępowanie wczytanych definicji to osobna operacja. Niestandardowe polityki startu mają udokumentowane działania odwrotne, a przeładowanie jest zmianą operacyjną, a nie założeniem, że każda asocjacja została zaktualizowana na miejscu. Wykonuj przeładowania etapami, tam gdzie ponowne połączenie jest akceptowalne. Zachowaj starą konfigurację, dopóki nowa nie zostanie udowodniona.
Sprawdź, co istnieje, zanim zaczniesz debugować routing
Wykonaj trzy obserwacje po kolei: wczytane definicje, aktywne SA IKE i wpisy child. Każda odpowiedź zawęża następne pytanie. Pomiń krok i skończysz na debugowaniu warstwy, która nigdy nie powstała.
Zacznij od tego, co jest wczytane, i od tego, co jest faktycznie ustanowione:
swanctl --list-conns
swanctl --list-sas
Jeśli childa brakuje, a profil jest poprawny, uruchom go po nazwie i obserwuj, co się dzieje. Wynik zwykle mówi, czy najpierw wstał element nadrzędny.
swanctl --initiate --child hq-lan
Aktywne SA CHILD to nie meta. Reguły przekazywania, trasy i własna autoryzacja aplikacji nadal muszą się zgadzać. Cykl życia odpowiada na to, co wynegocjowano; nie może zdecydować, kto może korzystać z usługi.