Keepalive to nie ponowne połączenie: wybierz według usterki, którą masz

Keepalive i ponowne połączenia konfiguruje się jednym tchem, ale rozwiązują różne problemy, dlatego dostrojenie jednego rzadko naprawia drugie. Keepalive wysyła mały ruch, aby utrzymać wpis stanu przy życiu lub zauważyć, że partner przestał odpowiadać. Ponowne połączenie burzy to, co zepsute, i buduje relację od nowa, wraz z kluczami, adresami i trasami. Wybierz mechanizm pasujący do usterki, a nie ten, którego pokrętło już znasz. Dwa pytania to rozstrzygają: czy ścieżka jest martwa, czy coś między partnerami o niej zapomina?

Gdy problemem jest mapowanie

Tunel, który umiera dopiero po minutach ciszy, zwykle traci wpis tłumaczenia, a nie partnera. W WireGuardzie PersistentKeepalive istnieje dla stanu NAT i zapory, a własne notatki projektu opisują go właśnie tak, nie jako kontrolę zdrowia. Interwał kilkudziesięciu sekund utrzymuje wpis ciepłym, natomiast pakiet co sekundę jest decyzją o baterii, a nie o niezawodności. OpenVPN dochodzi do tego samego miejsca przez ping i ping-restart , które najpierw zauważają ciszę, a potem na nią reagują.

Te ustawienia nie są też wymienne między protokołami. Zasada martwego partnera w IKEv2, timer ping w OpenVPN i keepalive w WireGuardzie odpowiadają na to samo pytanie trzema różnymi składniami i trzema różnymi wartościami domyślnymi, więc kopiowanie liczby między nimi to zgadywanie przebrane za strojenie.

Gdy relacji już nie ma

Jeśli partner zmieni adres, poświadczenie wygaśnie albo drugi koniec się zrestartuje, małe pakiety nie są naprawą. Ponowne połączenie musi odbudować stan : uzyskać adres, ponownie zainstalować trasy, ponownie wynegocjować klucze i w niektórych wdrożeniach ponownie uwierzytelnić użytkownika.

Klienci, którzy łączą się ponownie bez nadzoru, trzymają certyfikat albo zapisany sekret. Klient, który zapytałby człowieka, zawodzi dokładnie wtedy, gdy nikogo nie ma, a to scenariusz, w którym ponowne połączenie miało znaczenie. To decyzja projektowa podjęta miesiące wcześniej, a nie ustawienie, które można zmienić w trakcie awarii.

Czego nie dowodzi żadne z nich

Tunel może być ponownie połączony, z kluczami i trasami, podczas gdy usługa za nim nie działa, a keepalive może trzymać mapowanie otwarte dla sesji, której serwer zniknął godzinami temu. Oba mechanizmy mogą raportować sukces, gdy to, na czym naprawdę ci zależy, jest niedostępne.

Dlatego test kończy się prawdziwym żądaniem. Wyślij coś przez tunel po interwale, który cię interesuje, a następnie osobno wywołaj usterkę, pod którą projektowałeś: okres bezczynności w przypadku mapowania, restart lub zmianę adresu w przypadku ponownego połączenia.

Blokowanie ruchu bezpośredniego to osobna decyzja

Pętla ponownego łączenia może być całkowicie zdrowa, podczas gdy aplikacja po cichu korzysta ze zwykłej trasy, a to wyciek, nie usterka. Jeśli wymaganiem jest, aby nic nie wychodziło poza tunel, powiedz to wprost w konfiguracji klienta i udowodnij, opuszczając tunel i patrząc, co nadal się łączy. Żaden z mechanizmów tego nie zakłada i żadna dyscyplina ponowień tego nie ustanawia.

Zapisz, który mechanizm zadziałał i czy potem udało się nowe żądanie. Te dwa fakty są tym, czego potrzebuje następny inżynier, i żaden nie jest widoczny w ikonie stanu. Wiersz logu mówiący, że klient połączył się ponownie, to nie to samo co żądanie, które zadziałało.

Napisz politykę, nie tylko liczbę

Ujmij parę w jedno zdanie: interwał bezczynności, próg żywotności, co wywołuje odbudowę , i co robi klient, gdy ponawia. Bez tego zdania każdy przyszły incydent otwiera ten sam spór, czy keepalive jest za krótki, czy ponowne połączenie za wolne.

Notatki WireGuarda o ograniczeniach są użytecznym przypomnieniem, że keepalive jest obejściem dla middleboxów, a nie ogólnym projektem żywotności. Przeczytaj to ograniczenie, zanim podniesiesz częstotliwość w odpowiedzi na problem, którego nie potrafi rozwiązać.