Keepalive är inte en återanslutning: välj efter felet du har

Keepalive och återanslutningar konfigureras i samma andetag men löser olika problem, därför rättar justering av den ena sällan den andra. En keepalive skickar lite trafik för att hålla en tillståndspost vid liv eller för att märka att en peer slutat svara. En återanslutning river ner det som är trasigt och bygger upp relationen igen, inklusive nycklar, adresser och rutter. Välj mekanismen som passar felet, inte den vars knapp du redan känner. Två frågor avgör det: är vägen död, eller har något mellan parterna glömt den?

När mappningen är problemet

En tunnel som först dör efter minuters tystnad förlorar oftast en översättningspost och inte en peer. WireGuards PersistentKeepalive finns för NAT- och brandväggstillstånd, och projektets egna anteckningar beskriver den just så och inte som en hälsokontroll. Ett intervall på några tiotal sekunder håller en post varm, medan ett paket varje sekund är ett batteribeslut och inte ett tillförlitlighetsbeslut. OpenVPN kommer till samma ställe via ping och ping-restart , som först märker tystnaden och sedan agerar på den.

Dessa inställningar är inte heller utbytbara mellan protokoll. En IKEv2-regel för död peer, en OpenVPN-pingtimer och en WireGuard-keepalive svarar på samma fråga med tre olika syntaxer och tre olika standardvärden, så att kopiera ett tal mellan dem är gissning klädd i justering.

När relationen är borta

Om peeren byter adress, legitimationen går ut eller den bortre änden startar om, är små paket inte reparationen. Återanslutningen måste bygga upp tillståndet igen : skaffa en adress, installera rutter igen, förhandla om nycklar och i vissa utrullningar autentisera en användare igen.

Klienter som återansluter utan tillsyn har ett certifikat eller en lagrad hemlighet. En klient som skulle fråga en människa misslyckas just när ingen är närvarande, och det är scenariot där återanslutningen spelade roll. Det är ett designval som gjordes månader tidigare, inte en inställning du kan ändra under ett avbrott.

Vad ingen av dem bevisar

En tunnel kan vara återansluten, med nycklar och rutter, medan tjänsten bakom är nere, och en keepalive kan hålla en mappning öppen för en session vars server varit borta i timmar. Båda mekanismerna kan rapportera framgång medan det du faktiskt bryr dig om inte är tillgängligt.

Därför slutar testet vid en riktig begäran. Skicka något genom tunneln efter det intervall du bryr dig om och framkalla sedan separat felet du designade för: en tomgångsperiod för mappningsfallet, en omstart eller en adressändring för återanslutningsfallet.

Att blockera direkt trafik är ett eget beslut

En återanslutningsslinga kan vara helt frisk medan en applikation tyst använder den vanliga vägen, och det är ett läckage och inte ett fel. Om kravet är att ingenting går utanför tunneln, säg det uttryckligen i klientkonfigurationen och bevisa det genom att ta ner tunneln och se vad som fortfarande ansluter. Ingen av mekanismerna innebär det beteendet, och ingen mängd återförsöksdisciplin etablerar det.

Anteckna vilken mekanism som körde och om en ny begäran lyckades efteråt. De två fakta är vad nästa ingenjör behöver, och ingen av dem syns i en statusikon. En logglinje som säger att klienten återanslöt är inte samma sak som en begäran som fungerade.

Skriv policyn, inte bara talet

Sätt paret i en mening: tomgångsintervallet, livskraftströskeln, vad som utlöser en ombyggnad , och vad klienten gör medan den försöker igen. Utan den meningen öppnar varje framtida händelse samma diskussion om keepaliven är för kort eller återanslutningen för långsam.

WireGuards anteckningar om begränsningar är en nyttig påminnelse om att keepaliven är en omväg för middleboxes och inte en allmän livskraftsdesign. Läs den begränsningen innan du höjer frekvensen som svar på ett problem den inte kan lösa.