Połączenie działa godzinę, a potem pada, a klient nie zgłasza nic użyteczniejszego niż disconnected. Właśnie ten okres jest wskazówką, bo coś w wymianie odnowienia różni się od początkowego uzgadniania. Licznik tylko decyduje, kiedy go spotkasz. Zachowaj komunikaty z tej wymiany zamiast końcowej etykiety.

Czytaj etap, a nie etykietę

W IKEv2 asocjacja IKE i asocjacja CHILD są odnawiane według odrębnych harmonogramów. Propozycja akceptowalna dla pierwszych negocjacji nie jest automatycznie akceptowalna dla drugich. Jedna może się zakończyć, podczas gdy druga jest odrzucana, co daje tunel istniejący w połowie. Zapisz wymianę narzędziem, które nią zarządza, a nie linią logu klienta:

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

W przypadku OpenVPN równoważnym zdarzeniem jest renegocjacja sterowana wersją i ustawieniami wdrożenia. Jego zachowanie uwierzytelniania ma własne tryby awarii. Komunikat, który ma znaczenie, nazywa nieudany etap, i należy go zapisać dosłownie, zamiast parafrazować w zgłoszeniu.

Zapisz też znaczniki czasu. Awaria w stałym odstępie po ostatnich udanych negocjacjach to zupełnie inne ustalenie niż ta, która przychodzi losowo podczas użytkowania, a odstęp jest często jedynym dowodem, który przetrwa.

Porównaj propozycję, która zawodzi

Odrzucona propozycja daje wyraźny komunikat po stronie odpowiadającego. Zwykłą przyczyną jest różnica między końcami w algorytmie, długości klucza, grupie lub czasie życia. Początkowe negocjacje CHILD mogły się udać, bo zainicjowała je druga strona, czyli użyto listy propozycji drugiej strony. Spójrz na oba końce, zanim cokolwiek zmienisz.

Niezgodności czasu życia zasługują na szczególną uwagę, bo wartość, która po jednej stronie wyglądała hojnie, może skłonić drugą stronę do rozpoczęcia odnowienia, którego nie potrafi dokończyć. Dokumentacja zachowania przy wymianie kluczy opisuje, jak wyzwalane jest odnowienie asocjacji i jak oba końce mogą różnić się w oczekiwaniach czasowych. Porównaj, co każdy koniec deklaruje jako obsługiwane, a nie co sugeruje plik konfiguracyjny.

Stary profil lub szablon dostawcy może przypiąć propozycję, której bieżące wydanie już nie oferuje. Niezgodność ujawnia się dopiero, gdy wymuszone zostaną nowe negocjacje.

Oddziel problem danych uwierzytelniających od nieosiągalnego peera

Odnowienie, które zawodzi na uwierzytelnianiu, wygląda podobnie w kliencie i zupełnie inaczej na serwerze. Jeśli dane uwierzytelniające są ponownie sprawdzane przy renegocjacji, wygasły certyfikat, unieważnione konto lub zmienione hasło spowodują awarię dokładnie w odstępie odnowienia, podczas gdy każde wcześniejsze połączenie się udawało. Nieosiągalny peer to trzecia możliwość i nie daje żadnego odrzucenia: pakiety wychodzą i nic nie odpowiada. Ten przypadek zwykle podąża za zmianą sieci, a nie za licznikiem, więc sprawdź, czy awaria następuje po roamingu, okresie bezczynności lub zmianie trasy.

Rozróżnij trzy przypadki po tym, co zalogował drugi koniec. Odrzucenie z powodem, błąd uwierzytelniania i cisza to trzy różne poprawki. Restart klienta skleja je w jedną bezużyteczną obserwację.

Sprawdź daty certyfikatu i stan konta, zanim obwinisz sieć. Oba są tanie do sprawdzenia i oba są niewidoczne w komunikacie samego klienta.

Wymuś jedno odnowienie i odczytaj wynik

Wymuś jedno odnowienie metodą wspieraną przez operatora, zamiast czekać godzinę na następne. Zachowaj wymaganą politykę awarii nietkniętą, robiąc to. Wyłączenie weryfikacji lub rozciągnięcie czasów życia do jednego dnia sprawia, że objaw znika z logów, nie poprawiając niczego. Zostawia też dłuższą awarię następnej osobie.

Gdy poprawka jest na miejscu, sprawdź odnowiony tunel, a potem wyślij nowe żądanie z aplikacji. Sesja aplikacji, która żyła w chwili zmiany asocjacji, może wymagać własnego odzyskania, nawet jeśli tunel znów jest zdrowy. Użytkownicy zgłoszą to jako wciąż zepsuty VPN.

Zapisz wersje wydania, wynegocjowane liczniki i etap, który zawiódł. Następne wystąpienie będzie można wtedy porównać z tym, zamiast opisywać je ponownie z pamięci.

Powiązane artykuły