Keepalives en herverbindingen worden in één adem geconfigureerd maar lossen verschillende problemen op, daarom lost het afstellen van het ene zelden het andere op. Een keepalive stuurt klein verkeer om een statusvermelding in leven te houden of om te merken dat een peer niet meer antwoordt. Een herverbinding breekt af wat stuk is en bouwt de relatie opnieuw op, inclusief sleutels, adressen en routes. Kies het mechanisme dat bij de fout past, niet dat waarvan je de knop al kent. Twee vragen beslissen het: is het pad dood, of vergeet iets tussen de peers het?

Wanneer de mapping het probleem is

Een tunnel die pas na minuten stilte sterft, verliest meestal een vertaalvermelding en niet een peer. WireGuards PersistentKeepalive bestaat voor NAT- en firewalstatus, en de eigen notities van het project beschrijven het precies zo en niet als een gezondheidscontrole. Een interval van enkele tientallen seconden houdt een vermelding warm, terwijl een pakket per seconde een batterijbeslissing is en geen betrouwbaarheidsbeslissing. OpenVPN komt via ping en ping-restart op dezelfde plek uit, die eerst de stilte opmerken en er dan op reageren.

Die instellingen zijn ook niet tussen protocollen uitwisselbaar. Een IKEv2-beleid voor dode peers, een OpenVPN-pingtimer en een WireGuard-keepalive beantwoorden dezelfde vraag met drie verschillende syntaxen en drie verschillende standaardwaarden, dus een getal ertussen kopiëren is gissen in afstelkleren.

Wanneer de relatie weg is

Als de peer van adres verandert, de referentie verloopt of de andere kant herstart, zijn kleine pakketten niet de reparatie. De herverbinding moet toestand opnieuw opbouwen : een adres halen, routes opnieuw installeren, sleutels opnieuw onderhandelen en in sommige uitrollen een gebruiker opnieuw authenticeren.

Clients die onbeheerd opnieuw verbinden, hebben een certificaat of een opgeslagen geheim. Een client die een mens zou vragen, faalt precies wanneer niemand aanwezig is, en dat is het scenario waarin de herverbinding ertoe deed. Dat is een ontwerpkeuze van maanden eerder, geen instelling die je tijdens een storing kunt wijzigen.

Wat geen van beide bewijst

Een tunnel kan opnieuw verbonden, met sleutels en routes, terwijl de dienst erachter platligt, en een keepalive kan een mapping openhouden voor een sessie waarvan de server al uren weg is. Beide mechanismen kunnen succes melden terwijl wat je werkelijk belangrijk vindt niet beschikbaar is.

Daarom eindigt de test bij een echt verzoek. Stuur iets door de tunnel na het interval dat je belangrijk vindt, en lok daarna afzonderlijk de fout uit waarvoor je ontwierp: een idle-periode voor het mappinggeval, een herstart of een adreswijziging voor het herverbindingsgeval.

Direct verkeer blokkeren is een aparte beslissing

Een herverbindingslus kan volkomen gezond zijn terwijl een toepassing stilletjes de gewone route gebruikt, en dat is een lek en geen fout. Als de eis is dat niets buiten de tunnel gaat, zeg dat dan expliciet in de clientconfiguratie en bewijs het door de tunnel neer te halen en te kijken wat er nog verbindt. Geen van beide mechanismen impliceert dat gedrag, en geen enkele herprobeerdisscipline vestigt het.

Noteer welk mechanisme liep en of daarna een nieuw verzoek slaagde. Die twee feiten heeft de volgende engineer nodig, en geen van beide is zichtbaar in een statuspictogram. Een logregel dat de client opnieuw verbond is niet hetzelfde als een verzoek dat werkte.

Schrijf het beleid, niet alleen het getal

Zet het paar in één zin: het idle-interval, de levendigheidsdrempel, wat een heropbouw uitlokt , en wat de client doet terwijl hij het opnieuw probeert. Zonder die zin heropent elk toekomstig incident hetzelfde debat of de keepalive te kort of de herverbinding te traag is.

WireGuards notities over beperkingen zijn een nuttige herinnering dat de keepalive een omweg is voor middleboxes en geen algemeen levendigheidsontwerp. Lees die beperking voordat je de frequentie verhoogt als antwoord op een probleem dat ze niet kan oplossen.

Gerelateerde artikelen