Keepalive není opětovné připojení: vybírejte podle poruchy, kterou máte

Keepalive a opětovné připojení se nastavují jedním dechem, ale řeší různé problémy, a proto ladění jednoho málokdy opraví druhé. Keepalive posílá malý provoz, aby udržel záznam stavu živý nebo aby si všiml, že protějšek přestal odpovídat. Opětovné připojení bourá to, co je rozbité, a znovu staví vztah včetně klíčů, adres a tras. Vyberte mechanismus, který odpovídá poruše, ne ten, jehož knoflík už znáte. Rozhodují o tom dvě otázky: je cesta mrtvá, nebo na ni něco mezi protějšky zapomíná?

Když je problém v mapování

Tunel, který umírá až po minutách ticha, obvykle ztrácí překladový záznam, a ne protějšek. Volba PersistentKeepalive existuje pro stav NAT a firewallu a vlastní poznámky projektu jej tak i popisují, ne jako kontrolu zdraví. Interval několika desítek sekund udržuje záznam teplý, kdežto paket každou sekundu je rozhodnutí o baterii, ne o spolehlivosti. OpenVPN dochází ke stejnému závěru přes ping a ping-restart , které nejprve zaznamenají ticho a pak na něj reagují.

Tato nastavení také nejsou mezi protokoly zaměnitelná. Politika mrtvého protějšku u IKEv2, časovač ping u OpenVPN a keepalive u WireGuard odpovídají na stejnou otázku třemi různými syntaxemi a třemi různými výchozími hodnotami, takže kopírování čísla mezi nimi je hádání oblečené jako ladění.

Když vztah zmizel

Pokud protějšek změní adresu, pověření vyprší nebo se vzdálená strana restartuje, malé pakety nejsou oprava. Opětovné připojení musí obnovit stav : získat adresu, znovu nainstalovat trasy, znovu vyjednat klíče a v některých nasazeních znovu ověřit uživatele.

Klienti, kteří se připojují bez dohledu, drží certifikát nebo uložené tajemství. Klient, který by se zeptal člověka, selže právě tehdy, když nikdo není přítomen, a to je scénář, ve kterém na opětovném připojení záleželo. To je designové rozhodnutí učiněné měsíce předem, ne nastavení, které lze změnit během výpadku.

Co ani jedno neprokazuje

Tunel může být znovu připojený, s klíči a trasami, zatímco služba za ním je mimo provoz, a keepalive může držet mapování otevřené pro relaci, jejíž server zmizel před hodinami. Oba mechanismy mohou hlásit úspěch, zatímco to, na čem vám opravdu záleží, není dostupné.

Proto test končí skutečným požadavkem. Pošlete něco tunelem po intervalu, na kterém vám záleží, a pak samostatně vyvolejte poruchu, pro kterou jste navrhovali: období nečinnosti pro případ mapování, restart nebo změnu adresy pro případ opětovného připojení.

Blokování přímého provozu je samostatné rozhodnutí

Smyčka opětovného připojení může být naprosto zdravá, zatímco aplikace tiše používá běžnou trasu, a to je únik, ne porucha. Pokud je požadavkem, aby nic nevycházelo mimo tunel, řekněte to výslovně v konfiguraci klienta a dokažte to tak, že tunel položíte a podíváte se, co se ještě připojuje. Žádný mechanismus toto chování neznamená a žádná disciplína opakování ho nezavádí.

Zaznamenejte, který mechanismus běžel a zda potom uspěl nový požadavek. Tyto dva údaje potřebuje další inženýr a ani jeden není vidět v ikoně stavu. Řádek v logu, že se klient znovu připojil, není totéž jako požadavek, který fungoval.

Napište zásadu, ne jen číslo

Shoďte dvojici do jedné věty: interval nečinnosti, prahová hodnota živosti, co spustí obnovu , a co klient dělá, zatímco to opakuje. Bez té věty každý budoucí incident znovu otevírá stejnou hádku, zda je keepalive příliš krátký, nebo opětovné připojení příliš pomalé.

Poznámky WireGuardu k omezením jsou užitečnou připomínkou, že keepalive je obchvat pro prostřední zařízení, ne obecný návrh živosti. Přečtěte si to omezení, než zvýšíte frekvenci v reakci na problém, který vyřešit nedokáže.