Keepalive nije ponovno povezivanje: birajte prema kvaru koji imate

Keepalive i ponovno povezivanje konfiguriraju se u istom dahu, a rješavaju različite probleme, zato podešavanje jednog rijetko popravlja drugo. Keepalive šalje mali promet da održi stavku stanja živom ili da primijeti da je partner prestao odgovarati. Ponovno povezivanje ruši ono što je pokvareno i ponovo gradi odnos, uključujući ključeve, adrese i rute. Odaberite mehanizam koji odgovara kvaru, a ne onaj čiju polugu već poznajete. Dva pitanja to odlučuju: je li put mrtav ili nešto između partnera to zaboravlja?

Kada je problem u mapiranju

Tunel koji umre tek nakon minuta tišine obično gubi stavku prijevoda, a ne partnera. WireGuardov PersistentKeepalive postoji za stanje NAT-a i vatrozida, a vlastite bilješke projekta opisuju ga upravo tako, a ne kao provjeru zdravlja. Interval od nekoliko desetina sekundi održava stavku toplom, dok je paket svake sekunde odluka o bateriji, a ne o pouzdanosti. OpenVPN dolazi na isto mjesto preko ping i ping-restart , koji prvo primijete tišinu i zatim djeluju.

Te postavke nisu zamjenjive ni među protokolima. IKEv2 pravilo za mrtvog partnera, OpenVPN ping timer i WireGuard keepalive odgovaraju na isto pitanje s tri različite sintakse i tri različita zadana stanja, pa je kopiranje broja među njima nagađanje prerušeno u podešavanje.

Kada odnosa nema

Ako partner promijeni adresu, vjerodajnica istekne ili se druga strana restarta, mali paketi nisu popravak. Ponovno povezivanje mora obnoviti stanje : dobiti adresu, ponovo instalirati rute, ponovo pregovarati ključeve i u nekim postavkama ponovo autentificirati korisnika.

Klijenti koji se povezuju bez nadzora drže certifikat ili pohranjenu tajnu. Klijent koji bi pitao čovjeka pada upravo kada nikoga nema, a to je scenarij u kojem je ponovno povezivanje bilo važno. To je dizajnerska odluka donesena mjesecima ranije, a ne postavka koju možete promijeniti tijekom ispada.

Što nijedno od njih ne dokazuje

Tunel može biti ponovo povezan, s ključevima i rutama, dok je usluga iza njega nedostupna, a keepalive može držati mapiranje otvorenim za sesiju čiji je poslužitelj nestao prije sati. Oba mehanizma mogu prijaviti uspjeh dok je ono do čega vam je stvarno stalo nedostupno.

Zato test završava stvarnim zahtjevom. Pošaljite nešto kroz tunel nakon intervala do kojeg vam je stalo, pa zasebno izazovite kvar za koji ste projektirali: razdoblje mirovanja za slučaj mapiranja, restart ili promjenu adrese za slučaj ponovnog povezivanja.

Blokiranje izravnog prometa zasebna je odluka

Petlja ponovnog povezivanja može biti potpuno zdrava dok aplikacija tiho koristi uobičajenu rutu, a to je curenje, a ne kvar. Ako je zahtjev da ništa ne izlazi izvan tunela, recite to izričito u konfiguraciji klijenta i dokažite tako što ćete spustiti tunel i gledati što se još povezuje. Nijedan mehanizam ne podrazumijeva to ponašanje i nikakva disciplina ponavljanja to ne uspostavlja.

Zabilježite koji je mehanizam radio i je li novi zahtjev poslije uspio. Ta dva podatka trebaju sljedećem inženjeru i nijedan nije vidljiv u ikoni stanja. Linija u dnevniku koja kaže da se klijent ponovo povezao nije isto što i zahtjev koji je uspio.

Napišite pravilo, ne samo broj

Stavite par u jednu rečenicu: interval mirovanja, prag živosti, što pokreće ponovnu izgradnju , i što klijent radi dok ponavlja. Bez te rečenice svaki budući incident ponovo otvara istu raspravu o tome je li keepalive prekratak ili je ponovno povezivanje presporo.

WireGuardove bilješke o ograničenjima korisno su podsjećanje da je keepalive zaobilazno rješenje za middleboxe, a ne opći dizajn živosti. Pročitajte to ograničenje prije nego što povisite učestalost kao odgovor na problem koji ono ne može riješiti.