Zdalna brama restartuje się, wraca w ciągu minuty, a lokalny demon strongSwan nadal działa, podczas gdy tunel pozostaje wyłączony. Zadanie cron, które greppuje ESTABLISHED i restartuje demona, w końcu to zamaskuje, a także przerwie każdy niepowiązany tunel na maszynie, być może pomijając ten, który zawiódł. Odzyskiwanie należy do połączenia, które musi wrócić, wyrażonego w ustawieniach, które przetrwają przeładowanie. Ten runbook przygotowuje to dla jednego połączenia i udowadnia wynik po nazwie.

Zrezygnuj z globalnego restartu, zachowaj jego dowody

Restart demona ma dwie konkretne wady: niszczy stan każdego połączenia i nie mówi nic o tym, które zdarzenie faktycznie zawiodło. Tekst statusu, który greppowałeś, mógł pochodzić z innego połączenia, podczas gdy wymagany child stał bezczynnie, bo nic go nie uruchomiło.

Przeczytaj wczytane połączenia i aktywne asocjacje przed zmianą czegokolwiek, aby mieć obraz przed do porównania po powrocie peera.

swanctl --list-conns
swanctl --list-sas

Umieść inicjowanie i ponowne próby na połączeniu, które wraca

We wdrożeniu z swanctl.conf te ustawienia żyją na poziomie połączenia i child, a nie w globalnej polityce. Poniższy fragment to przykład po stronie inicjatora, który zakłada, że propozycje, uwierzytelnianie i selektory są już poprawne.

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

start_action decyduje, co się dzieje przy wczytywaniu child: start inicjuje natychmiast, a trap instaluje politykę, która uruchamia inicjowanie, gdy pojawi się pasujący ruch. Zapis trap|start wymaga strongSwan 5.9.6 lub nowszego, więc sprawdź wersję przed skopiowaniem linii. dpd_action=restart żąda nowych negocjacji, gdy peer zostanie uznany za martwy, a keyingtries=0 na poziomie połączenia pozwala na dalsze próby aż do sukcesu lub trwałego błędu. W IKEv2 dpd_timeout nie ma żadnego efektu, bo o tym, kiedy peer nie odpowiada, decyduje zwykła retransmisja.

Opóźnienie w tym przykładzie jest punktem wyjścia, a nie uniwersalnym terminem. Wybierz je na podstawie tego, ile trwa restart peera i ile retransmisji jesteś gotów znieść.

Wiedz, z jakiego zdarzenia się odzyskujesz

Trzy awarie wyglądają identycznie na pulpicie i wymagają różnych ustawień. Początkowe połączenie, które nigdy nie wstało, to problem konfiguracji lub osiągalności. Peer, który przestał odpowiadać, to przypadek DPD. Child, który peer jawnie zamknął, to zdarzenie polityki z własnym close_action, którego DPD nigdy nie obserwuje. Czytanie logu wokół przerwy mówi, którą z trzech masz, a odpowiedź zmienia poprawkę.

Nie dodawaj agresywnego ponownego inicjowania do połączenia, które operatorzy celowo zamykają na czas konserwacji, bo tunel pojawi się ponownie w środku okna. W projektach na żądanie wystarczy zachowany trap, bo pasujący ruch odtworzy child bez żadnego timera.

Weryfikuj po nazwie, nie po statusie demona

Przeczytaj połączenie i jego child po nazwie, gdy peer jest jeszcze wyłączony, a potem ponownie, gdy wróci; różnica między tymi dwoma wyjściami jest dowodem.

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

Potem potwierdź usługę, a nie asocjację. Świeża asocjacja bezpieczeństwa child plus udane żądanie do prywatnego celu za nią to ta para faktów, która się liczy, a działający demon ze zdrowym niepowiązanym tunelem nie dowodzi żadnego z nich.

Jeśli child nigdy nie inicjuje, sprawdź, czy ruch testowy dokładnie pasuje do skonfigurowanych selektorów, wraz z protokołem i portem. Jeśli inicjuje i zawodzi, przeczytaj błąd uwierzytelniania lub propozycji zamiast ukrywać go za nieskończoną pętlą, bo keyingtries=0 chętnie powtórzy trwałe odrzucenie na zawsze.

Wczytaj zmianę w oknie konserwacyjnym i przetestuj ponownie

Przeładowanie jest bezpieczniejsze niż restart demona i nadal nie jest darmowe: zastąpienie lub wyładowanie child może zamknąć rozpoczętą asocjację albo zrzucić jego trap.

Wczytuj w oknie konserwacyjnym, zachowaj poprzedni plik i potwierdź, że połączenie pojawia się z zamierzonymi ustawieniami, a nie z domyślnymi.

swanctl --load-conns
swanctl --list-conns

Wycofaj zmianę, przywracając poprzedni plik i wczytując go ponownie, a potem powtórz te same dwie komendy. Tunel, który wraca tylko po restarcie demona, nie został naprawiony, został zresetowany.

Powiązane artykuły