Keepalive er ikkje ei gjenoppkopling: vel etter feilen du har

Keepalive og gjenoppkoplingar vert konfigurerte i same andedrag, men løyser ulike problem, og difor rettar justering av den eine sjeldan den andre. Ein keepalive sender litt trafikk for å halde ein tilstandsoppføring i live eller for å merke at ein peer har slutta å svare. Ei gjenoppkopling riv ned det som er øydelagt og byggjer sambandet opp att, inkludert nøklar, adresser og ruter. Vel mekanismen som passar feilen, ikkje den du allereie kjenner knappen på. To spørsmål avgjer det: er stien død, eller er det noko mellom partane som har gløymt han?

Når mappinga er problemet

Ein tunnel som først døyr etter minutt med stillheit, mistar som regel ein omsetjingsoppføring og ikkje ein peer. WireGuards PersistentKeepalive finst for NAT- og brannmurtilstand, og dei eigne notata til prosjektet skildrar han nettopp slik og ikkje som ein helsesjekk. Eit intervall på nokre få titals sekund held ei oppføring varm, medan ein pakke kvart sekund er ei batteriavgjerd og ikkje ei pålitelegheitsavgjerd. OpenVPN kjem til same stad via ping og ping-restart , som først merkar stillheita og deretter handlar på henne.

Desse innstillingane kan heller ikkje bytast mellom protokollar. Ein IKEv2-policy for død peer, ein OpenVPN-pingtimer og ein WireGuard-keepalive svarar på det same spørsmålet med tre ulike syntaksar og tre ulike standardverdiar, så å kopiere eit tal mellom dei er gissing kledd ut som justering.

Når sambandet er borte

Viss peeren byter adresse, legitimasjonen går ut eller den fjerne enden startar på nytt, er små pakkar ikkje reparasjonen. Gjenoppkoplinga må byggje tilstanden på nytt : skaffe ei adresse, installere ruter på nytt, forhandle nøklar på nytt og i nokre utrullingar autentisere ein brukar på nytt.

Klientar som koplar til på nytt utan tilsyn, har eit sertifikat eller ei lagra løyndom. Ein klient som ville spørje eit menneske, feilar nettopp når ingen er til stades, og det er scenarioet der gjenoppkoplinga betydde noko. Det er eit designval tekne månader tidlegare, ikkje ei innstilling du kan endre under eit avbrot.

Kva ingen av dei beviser

Ein tunnel kan vere gjenoppkopla, med nøklar og ruter, medan tenesta bak er nede, og ein keepalive kan halde ei mapping open for ei økt der tenaren har vore borte i timar. Begge mekanismane kan rapportere suksess medan det du faktisk bryr deg om, er utilgjengeleg.

Difor sluttar testen ved ein ekte førespurnad. Send noko gjennom tunnelen etter intervallet du bryr deg om, og framkall deretter separat feilen du designa for: ein tomgangsperiode for mapping-saka, ein omstart eller ei adresseendring for gjenoppkopling-saka.

Å blokkere direkte trafikk er ei eiga avgjerd

Ei gjenoppkopling-løkke kan vere heilt sunn medan ein applikasjon stille brukar den vanlege ruta, og det er ein lekkasje og ikkje ein feil. Viss kravet er at ingenting går utanfor tunnelen, sei det eksplisitt i klientkonfigurasjonen og prov det ved å ta tunnelen ned og sjå kva som framleis koplar til. Ingen av mekanismane inneber den åtferda, og inga mengd gjenforsøksdisiplin etablerer henne.

Noter kva mekanisme som køyrde og om ein ny førespurnad lukkast etterpå. Dei to fakta er det neste ingeniør treng, og ingen av dei er synlege i eit statusikon. Ei logglinje som seier at klienten kopla til på nytt, er ikkje det same som ein førespurnad som verka.

Skriv policyen, ikkje berre talet

Set paret i éi setning: tomgangsintervallet, liveness-terskelen, kva som utløyser ein gjenoppbygging , og kva klienten gjer medan han prøver på nytt. Utan den setninga opnar kvar framtidig hending den same diskusjonen om keepaliven er for kort eller gjenoppkoplinga for treg.

WireGuards notat om avgrensingar er ei nyttig påminning om at keepaliven er ein omveg for middleboxes og ikkje eit generelt liveness-design. Les den avgrensinga før du aukar frekvensen som svar på eit problem ho ikkje kan løyse.