Tryb trap w strongSwan: dlaczego tunel IPsec czeka na ruch

Bezczynny tunel IPsec na żądanie nie pokazuje CHILD SA, dopóki pakiet nie pasuje do jego polityki trap. Przeczytaj stan, sprawdź wyzwalacz i wiedz, kiedy start pasuje.

W wyniku statusu nie pojawia się CHILD SA, tunel wygląda na martwy, a potem ping do odległej podsieci go podnosi. W konfiguracji IPsec na żądanie ta kolejność jest zamierzeniem, nie awarią. Polityka trap instaluje selektor i czeka, a pierwszy pasujący pakiet uruchamia IKE i negocjację CHILD SA.

Część zamieszania to słownictwo: „up” jest używane dla dwóch różnych stanów. Konfiguracja jest załadowana i polityka jądra istnieje, ale asocjacja danych nie. Monitor liczący tylko aktywne SA zgłosi zdrową lokalizację jako niedostępną, dopóki nikt nie wyśle do niej ruchu.

Bezczynny tunel na żądanie nie ma CHILD SA do pokazania

Wpis trap sam niczego nie uwierzytelnia. Prosi jądro o utrzymywanie polityki dla wybranego ruchu i o podniesienie acquisition, gdy pakiet potrzebuje tej polityki. Demon odbiera acquisition, dopasowuje go do definicji child i negocjuje od tego miejsca. Do tego momentu nie ma też IKE SA do pokazania, dlatego obie listy mogą być puste jednocześnie.

Ta kolejność czyni logi czytelnymi. Najpierw przychodzi acquisition, potem IKE_SA_INIT i IKE_AUTH, a potem CHILD SA. Jeśli log kończy się zaraz po acquisition, wyzwalacz zadziałał. Negocjacja nie powiodła się, a następne pytanie dotyczy poświadczeń, propozycji lub osiągalności, nie trapa.

Z backendem jądra Linux możesz zobaczyć politykę, zanim istnieje jakikolwiek SA. Uruchom ip xfrm policy i poszukaj selektora z kierunkiem out oraz szablonem wskazującym połączenie. Ten wpis to stan na żądanie, a jego obecność to pierwsza rzecz do potwierdzenia.

start_action decyduje, czy cokolwiek czeka

Każdy child w swanctl.conf ma start_action. start uruchamia się przy ładowaniu konfiguracji, trap instaluje politykę i czeka, a none zostawia uruchomienie czemuś innemu. Tylko trap daje opisane wyżej zachowanie „ping i podnosi się”.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Dwa selektory ruchu definiują, co liczy się jako interesujące, a pakiet z hosta spoza tych prefiksów nie uruchamia trapa; jest routowany jak zwykle. Rozszerzanie selektorów, by wyzwalacz był chętniejszy, rozszerza też zakres, który tunel twierdzi, że chroni, więc wyprowadzaj je z ruchu, który naprawdę chcesz szyfrować.

Dokumentacja swanctl.conf wymienia akceptowane wartości wraz z osobnymi akcjami close i DPD, które określają, co się dzieje, gdy SA istnieje.

Sprawdź, czy wyzwalacz w ogóle zadziałał

Zacznij od swanctl --list-conns i potwierdź, że child jest załadowany z zamierzoną akcją. Następnie wyślij jeden pakiet z hosta wewnątrz local_ts na adres wewnątrz remote_ts i obserwuj swanctl --list-sas. Jeśli wynik się nie zmienia, żadne acquisition nie dotarło do demona.

Dwa zwykłe powody cichego trapa: pakiet został poddany source-NAT, zanim dotarł do polityki, i nie pasuje już do local_ts, albo połączenie nigdy się nie załadowało z powodu błędu składni lub poświadczeń. Uruchom ponownie swanctl --load-all i przeczytaj wynik, zanim dotkniesz selektorów. Połączenie, które się nie załadowało, nie instaluje polityki, więc ruch nie ma czego uruchomić.

Kierunek też ma znaczenie: trap zainstalowany dla ruchu wychodzącego nie startuje na pakiecie przychodzącym. Jeśli zdalna strona ma podnieść tunel, potrzebuje własnego trapa, albo ta strona potrzebuje start.

Czekanie na pierwszy pakiet nie zawsze jest właściwą wymianą

Sesje interaktywne odczuwają koszt konfiguracji. Pierwsze żądanie płaci za wymianę IKE i negocjację CHILD, a klient z krótkim terminem może się poddać, zanim SA powstanie. Proaktywny start usuwa to opóźnienie pierwszego pakietu. Ale utrzymuje tunel dla ruchu, który może nigdy nie nadejść.

Trzy fakty rozstrzygają wybór: jak często używana jest ścieżka, czy pierwsze żądanie ma ciasny termin i czy peer jest osiągalny przy starcie. Okazjonalny ruch wsadowy i peer, który przy starcie może być offline, oba przemawiają za trap. Klient wrażliwy na opóźnienia i peer zawsze osiągalny przemawiają za start. Jeśli obie strony mogą inicjować, uzgodnijcie, kto posiada wyzwalacz, aby nie było podwójnych negocjacji.

Zainstalowana polityka też nie jest gwarancją szczelności. Jeśli wymóg to fail-closed, zapora musi odrzucać ruch bez SA, a ta reguła żyje poza definicją child.

Zapisz trzy linie, które zakończą następną dyskusję

Zapisz selektory, akcję startową i wynik polecenia pokazujący politykę bez SA. Te trzy linie oddzielają „na żądanie i bezczynny” od „nie ładuje się”, gdy ktoś następnym razem zgłosi tunel jako niedostępny. Ich zapisanie zajmuje minutę. Bez nich to samo śledztwo zaczyna się od zera.

Testuj z hosta, który naprawdę znajduje się wewnątrz selektora. Ping z samego routera często idzie inną drogą i niczego nie dowodzi o polityce chroniącej podsieć za nim.

Powiązane artykuły