Keepalive er ikke en gjenoppkobling: velg etter feilen du har

Keepalive og gjenoppkoblinger konfigureres i samme åndedrag, men løser forskjellige problemer, og derfor retter justering av den ene sjelden den andre. En keepalive sender litt trafikk for å holde en tilstandsoppføring i live eller for å merke at en peer har sluttet å svare. En gjenoppkobling river ned det som er ødelagt og bygger forbindelsen opp igjen, inkludert nøkler, adresser og ruter. Velg mekanismen som passer feilen, ikke den du allerede kjenner knappen på. To spørsmål avgjør det: er stien død, eller er det noe mellom partene som har glemt den?

Når mappingen er problemet

En tunnel som først dør etter minutters stillhet, mister som regel en oversettelsesoppføring og ikke en peer. WireGuards PersistentKeepalive finnes for NAT- og brannmurtilstand, og prosjektets egne notater beskriver den nettopp slik og ikke som en helsesjekk. Et intervall på noen få titalls sekunder holder en oppføring varm, mens en pakke hvert sekund er en batteribeslutning og ikke en pålitelighetsbeslutning. OpenVPN kommer til samme sted via ping og ping-restart , som først merker stillheten og deretter handler på den.

Disse innstillingene kan heller ikke byttes mellom protokoller. En IKEv2-policy for død peer, en OpenVPN-pingtimer og en WireGuard-keepalive svarer på det samme spørsmålet med tre forskjellige syntakser og tre forskjellige standardverdier, så å kopiere et tall mellom dem er gjetning kledd ut som justering.

Når forbindelsen er borte

Hvis peeren bytter adresse, legitimasjonen utløper eller den fjerne enden starter på nytt, er små pakker ikke reparasjonen. Gjenoppkoblingen må bygge tilstanden på nytt : skaffe en adresse, installere ruter på nytt, forhandle nøkler på nytt og i noen utrullinger autentisere en bruker på nytt.

Klienter som kobler til på nytt uten tilsyn, har et sertifikat eller en lagret hemmelighet. En klient som ville spørre et menneske, feiler nettopp når ingen er til stede, og det er scenarioet der gjenoppkoblingen betydde noe. Det er et designvalg tatt måneder tidligere, ikke en innstilling du kan endre under et avbrudd.

Hva ingen av dem beviser

En tunnel kan være gjenoppkoblet, med nøkler og ruter, mens tjenesten bak er nede, og en keepalive kan holde en mapping åpen for en økt der serveren har vært borte i timer. Begge mekanismene kan rapportere suksess mens det du faktisk bryr deg om, er utilgjengelig.

Derfor slutter testen ved en ekte forespørsel. Send noe gjennom tunnelen etter intervallet du bryr deg om, og fremkall deretter separat feilen du designet for: en tomgangsperiode for mapping-saken, en omstart eller en adresseendring for gjenoppkoblingssaken.

Å blokkere direkte trafikk er en egen beslutning

En gjenoppkoblingsløkke kan være helt sunn mens en applikasjon stille bruker den vanlige ruten, og det er en lekkasje og ikke en feil. Hvis kravet er at ingenting går utenfor tunnelen, si det eksplisitt i klientkonfigurasjonen og bevis det ved å ta tunnelen ned og se hva som fortsatt kobler til. Ingen av mekanismene innebærer den oppførselen, og ingen mengde gjenforsøksdisiplin etablerer den.

Noter hvilken mekanisme som kjørte og om en ny forespørsel lyktes etterpå. De to fakta er det neste ingeniør trenger, og ingen av dem er synlige i et statusikon. En logglinje som sier at klienten koblet til på nytt, er ikke det samme som en forespørsel som virket.

Skriv policyen, ikke bare tallet

Sett paret i én setning: tomgangsintervallet, liveness-terskelen, hva som utløser en gjenoppbygging , og hva klienten gjør mens den prøver på nytt. Uten den setningen gjenåpner hver fremtidig hendelse den samme diskusjonen om keepaliven er for kort eller gjenoppkoblingen for treg.

WireGuards notater om begrensninger er en nyttig påminnelse om at keepaliven er en omvei for middleboxes og ikke et generelt liveness-design. Les den begrensningen før du øker frekvensen som svar på et problem den ikke kan løse.