Keepalive er ikke en genopkobling: vælg efter den fejl, du har

Keepalives og genopkoblinger konfigureres i samme åndedrag og løser forskellige problemer, og derfor retter tuning af den ene sjældent den anden. En keepalive sender lidt trafik for at holde en tilstandspost i live eller for at bemærke, at en peer er holdt op med at svare. En genopkobling river det ned, der er brudt, og bygger forbindelsen op igen, inklusive nøgler, adresser og ruter. Vælg den mekanisme, der passer til fejlen, ikke den, hvis knap du allerede kender. To spørgsmål afgør det: er stien død, eller er der noget mellem parterne, som har glemt den?

Når mappingen er problemet

En tunnel, der først dør efter minutters stilhed, mister som regel en oversættelsespost og ikke en peer. WireGuards PersistentKeepalive findes til NAT- og firewall-tilstand, og projektets egne noter beskriver den netop sådan og ikke som et sundhedstjek. Et interval på nogle få snese sekunder holder en post varm, mens en pakke hvert sekund er en batteribeslutning og ikke en pålidelighedsbeslutning. OpenVPN når samme sted via ping og ping-restart , som først bemærker stilheden og derefter handler på den.

De indstillinger kan heller ikke udveksles mellem protokoller. En IKEv2-politik for død peer, en OpenVPN-pingtimer og en WireGuard-keepalive besvarer det samme spørgsmål med tre forskellige syntakser og tre forskellige standardværdier, så at kopiere et tal mellem dem er gætværk klædt ud som tuning.

Når forbindelsen er væk

Hvis peeren skifter adresse, legitimationen udløber, eller den fjerne ende genstarter, er små pakker ikke reparationen. Genopkoblingen skal genopbygge tilstand : få en adresse, geninstaller ruter, genforhandle nøgler og i nogle udrulninger godkend en bruger igen.

Klienter, der genopkobler uden opsyn, har et certifikat eller en gemt hemmelighed. En klient, der ville spørge et menneske, fejler netop, når ingen er til stede, og det er det scenarie, hvor genopkoblingen betød noget. Det er et designvalg truffet måneder tidligere, ikke en indstilling, du kan ændre under et udfald.

Hvad ingen af dem beviser

En tunnel kan være genopkoblet, med nøgler og ruter, mens tjenesten bag den er nede, og en keepalive kan holde en mapping åben for en session, hvis server har været væk i timer. Begge mekanismer kan rapportere succes, mens det, du faktisk bekymrer dig om, er utilgængeligt.

Derfor slutter testen ved en rigtig anmodning. Send noget gennem tunnelen efter det interval, du bekymrer dig om, og fremkald derefter separat den fejl, du designede til: en tomgangsperiode for mapping-sagen, en genstart eller en adresseændring for genopkoblingssagen.

Blokering af direkte trafik er en separat beslutning

En genopkoblingsløkke kan være helt sund, mens et program stille bruger den almindelige rute, og det er en lækage og ikke en fejl. Hvis kravet er, at intet forlader tunnelen, så sig det udtrykkeligt i klientkonfigurationen, og bevis det ved at tage tunnelen ned og se, hvad der stadig forbinder. Ingen af mekanismerne indebærer den adfærd, og ingen mængde genforsøgsdisciplin etablerer den.

Notér, hvilken mekanisme der kørte, og om en ny anmodning lykkedes bagefter. De to fakta er, hvad den næste ingeniør har brug for, og ingen af dem er synlige i et statusikon. En loglinje, der siger, at klienten genopkoblede, er ikke det samme som en anmodning, der virkede.

Skriv politikken, ikke bare tallet

Sæt parret i én sætning: tomgangsintervallet, liveness-tærsklen, hvad der udløser en genopbygning , og hvad klienten gør, mens den prøver igen. Uden den sætning genåbner hver fremtidig hændelse den samme diskussion om, hvorvidt keepaliven er for kort, eller genopkoblingen er for langsom.

WireGuards noter om begrænsninger er en nyttig påmindelse om, at keepaliven er en omvej for middleboxes og ikke et generelt liveness-design. Læs den begrænsning, før du hæver frekvensen som svar på et problem, den ikke kan løse.