Keepalive nie je opätovné pripojenie: vyberte podľa poruchy, ktorú máte

Keepalive a opätovné pripojenie sa nastavujú jedným dychom, ale riešia rôzne problémy, preto ladenie jedného málokedy opraví druhé. Keepalive posiela malý prenos, aby udržal stavový záznam živý alebo aby si všimol, že partner prestal odpovedať. Opätovné pripojenie zbúra to, čo je pokazené, a znovu postaví vzťah vrátane kľúčov, adries a trás. Vyberte mechanizmus, ktorý zodpovedá poruche, nie ten, ktorého gombík už poznáte. Rozhodujú o tom dve otázky: je cesta mŕtva, alebo na ňu niečo medzi partnermi zabúda?

Keď je problém v mapovaní

Tunel, ktorý umiera až po minútach ticha, zvyčajne stráca prekladový záznam, nie partnera. Vo WireGuarde PersistentKeepalive existuje pre stav NAT a firewallu, a vlastné poznámky projektu ho opisujú práve tak, nie ako kontrolu zdravia. Interval niekoľkých desiatok sekúnd udržiava záznam teplý, kým paket každú sekundu je rozhodnutie o batérii, nie o spoľahlivosti. OpenVPN sa dostáva na to isté miesto cez ping a ping-restart , ktoré najprv zaznamenajú ticho a potom naň reagujú.

Tieto nastavenia nie sú ani zameniteľné medzi protokolmi. Pravidlo mŕtveho partnera v IKEv2, časovač ping v OpenVPN a keepalive vo WireGuarde odpovedajú na tú istú otázku tromi rôznymi syntaxami a tromi rôznymi predvolenými hodnotami, takže kopírovanie čísla medzi nimi je hádanie oblečené ako ladenie.

Keď vzťah zmizol

Ak partner zmení adresu, poverenie vyprší alebo sa vzdialená strana restartuje, malé pakety nie sú opravou. Opätovné pripojenie musí obnoviť stav : získať adresu, znova nainštalovať trasy, znova vyjednať kľúče a v niektorých nasadeniach znova overiť používateľa.

Klienti, ktorí sa pripájajú bez dohľadu, držia certifikát alebo uložené tajomstvo. Klient, ktorý by sa spýtal človeka, zlyhá presne vtedy, keď nikto nie je prítomný, a to je scenár, v ktorom na opätovnom pripojení záležalo. Je to dizajnové rozhodnutie prijaté mesiace predtým, nie nastavenie, ktoré môžete zmeniť počas výpadku.

Čo ani jedno nepreukazuje

Tunel môže byť znovu pripojený, s kľúčmi a trasami, kým služba za ním je mimo prevádzky, a keepalive môže držať mapovanie otvorené pre reláciu, ktorej server zmizol pred hodinami. Oba mechanizmy môžu hlásiť úspech, kým to, na čom vám naozaj záleží, nie je dostupné.

Preto test končí skutočnou požiadavkou. Pošlite niečo tunelom po intervale, na ktorom vám záleží, a potom samostatne vyvolajte poruchu, pre ktorú ste navrhovali: obdobie nečinnosti v prípade mapovania, reštart alebo zmenu adresy v prípade opätovného pripojenia.

Blokovanie priamej premávky je samostatné rozhodnutie

Slučka opätovného pripájania môže byť úplne zdravá, kým aplikácia potichu používa bežnú trasu, a to je únik, nie porucha. Ak je požiadavkou, aby nič nevychádzalo mimo tunela, povedzte to výslovne v konfigurácii klienta a dokážte to tak, že tunel položíte a pozriete sa, čo sa ešte pripája. Ani jeden mechanizmus toto správanie neznamená a žiadna disciplína opakovania ho nezavádza.

Zaznamenajte, ktorý mechanizmus bežal a či potom uspela nová požiadavka. Tieto dva fakty potrebuje ďalší inženier a ani jeden nie je viditeľný v ikone stavu. Riadok v logu, že sa klient znova pripojil, nie je to isté ako požiadavka, ktorá fungovala.

Napíšte zásadu, nie len číslo

Zložte dvojicu do jednej vety: interval nečinnosti, prah živosti, čo spúšťa obnovu , a čo klient robí, kým to opakuje. Bez tej vety každý budúci incident znova otvára ten istý spor, či je keepalive príliš krátky alebo opätovné pripojenie príliš pomalé.

Poznámky WireGuardu k obmedzeniam sú užitočnou pripomienkou, že keepalive je obchádzka pre medziľahlé zariadenia, nie všeobecný návrh živosti. Prečítajte si to obmedzenie, kým zvýšite frekvenciu v reakcii na problém, ktorý vyriešiť nedokáže.