Skrócenie timera DPD nie przyspieszy przełączania VPN

Tunele padają, odzyskiwanie trwa dziewięćdziesiąt sekund, a timer martwego peera jest ustawiony na dziesięć, więc obwinia się timer. To rozumowanie pomija trzy etapy, które następują po wykryciu i zwykle zajmują większość czasu. Wykrywanie żywotności zauważa ciszę; potem wybór peera, uwierzytelnianie, instalacja trasy i ponowne połączenie aplikacji biorą każdy swoją kolej. Skrócenie pierwszego etapu nie może skrócić pozostałych, a może dodać zamieszania systemowi, który już sobie nie radził.

Cztery etapy, z których jeden możesz zmierzyć

Zapisz odzyskiwanie jako cztery zdarzenia ze znacznikami czasu. Awaria staje się obserwowalna: ostatni użyteczny chroniony ruch i pierwsze nieudane żądanie. Odpowiedzialny mechanizm reaguje: wykrywanie żywotności, monitor trasy lub inny udokumentowany wyzwalacz. Alternatywa staje się użyteczna: wybór peera, uwierzytelnianie, nowa asocjacja i trasa, która faktycznie niesie zamierzony ruch. Aplikacja się odzyskuje: nowa operacja się udaje, a to, co było w toku, ma określony wynik.

Reguły żywotności IKEv2 opisują dowody dotyczące peera i jego wymian, a nie mówią nic o bazie danych ani usłudze plików za tym peerem. Odczytanie limitu czasu żywotności jako kontroli stanu całej ścieżki to błąd, który rozpoczyna polowanie na timer.

Dlaczego timer jest najmniej ciekawą liczbą

Skonfigurowane wartości nie są wymiennymi jednostkami. Niektóre są interwałami ponowień, inne górnymi granicami próby, a jeszcze inne działają równocześnie z innymi. Ich dodanie daje liczbę, która wygląda jak prognoza, a zachowuje się jak plotka. Przeczytaj dokumentację pola, którego zaraz dotkniesz, i zanotuj, który to z trzech rodzajów.

Inne etapy wcale nie są timerami. Opóźnienie ponownego połączenia, interaktywne żądanie uwierzytelnienia lub klient, który ponownie ocenia swoją konfigurację tylko przy restarcie, mogą każde zdominować awarię, podczas gdy każdy timer protokołu stoi wygodnie nisko.

Zmierz etap, który naprawdę jest wolny

Przechwyć awarię raz, ze znacznikami czasu po obu stronach, a następnie porównaj cztery zdarzenia, a nie własne liczniki protokołu. Jedno dobrze wykonane okno obserwacji jest lepsze niż miesiąc strojenia.

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

Jeśli alternatywny punkt końcowy nigdy nie odpowiada, żadna zmiana timera nie pomoże, bo nieosiągalność nie jest problemem wykrywania. Jeśli nowy stan zabezpieczeń powstaje szybko, ale trasa nadal wskazuje martwą ścieżkę, problemem jest instalacja trasy, a kolejna korekta żywotności tylko dodaje zamieszania.

Alternatywa musi być już użyteczna

Kopia zapasowa zdefiniowana w konfiguracji nie jest kopią zapasową, która działa. Musi być osiągalna z bieżącej sieci klienta, umieć uwierzytelnić tę samą tożsamość i mieć pozwolenie na przenoszenie tego samego ruchu w ramach tej samej polityki. Jeśli podczas awarii odkryjesz którąkolwiek z tych trzech luk, dyskusja o timerze staje się nieistotna. Przetestuj alternatywę, gdy primary jest zdrowy, bo to jedyny moment, w którym możesz czytać oba logi obok siebie.

Zapewnij alternatywę z wyprzedzeniem, przetestuj ją celowo, gdy primary jest zdrowy, i zapisz, który z czterech etapów zajmuje czas. To właśnie ten zapis czyni następną zmianę pomiarem, a nie domysłem.

Zamieszanie przy powrocie i ścieżka zarządzania

Przywrócenie primary to osobna decyzja. Agresywny powrót może przerwać pracę, która już odzyskała sprawność na kopii zapasowej, a migocząca ścieżka może wyglądać jak niestabilny tunel, gdy prawdziwą usterką jest trasa oscylująca między dwiema równymi opcjami.

Dwie trasy o równym koszcie bez preferencji są zwykłym źródłem widocznego migotania, bo każdy monitor reaguje na wybór drugiego. Zdecyduj, która trasa jest preferowana w normalnych warunkach, i uczyń tę preferencję jawną w konfiguracji, zamiast zostawiać ją kolejności tras. Zdefiniuj z góry pożądane zachowanie powrotu i to, kto jest jego właścicielem. Zachowaj poprzednie ustawienia i niezależną ścieżkę zarządzania, bo zmiana, która odbiera ci własny dostęp podczas awarii, zamienia incydent sieciowy w wizytę na miejscu.

Następnie powtórz to samo obciążenie i porównaj te same cztery znaczniki czasu. Krótsze odzyskiwanie, które nadal zostawia aplikację czekającą na tę samą brakującą trasę lub logowanie, nie jest postępem, to inna liczba na tym samym wykresie.