OpenVPN keepalive eller systemd-omstart: vilket återställer?

Tre olika saker kan gå fel med en tunnel, och de kräver tre olika reaktioner. Peeren slutar svara, daemonprocessen dör, eller applikationen bakom tunneln slutar betjäna. En konfiguration som startar om tjänsten vid vilket som helst av dem är inte noggrann övervakning; det är en enda trubbig åtgärd som tillämpas på orelaterade fel. Att jämföra vad varje mekanism faktiskt kan observera gör arbetsfördelningen uppenbar.

Tre fel som ser ut som ett

Peer-tystnad betyder att andra änden slutade skicka, och OpenVPN kan upptäcka det själv eftersom det äger hjärtslagen. Processdöd betyder att daemonen avslutades, vilket tjänstehanteraren märker och OpenVPN inte kan. Applikationsfel betyder att tunneln är okej och att något bakom den inte är det, och ingen av de andra två mekanismerna har något sätt att veta det. Var och en kräver en annan reaktion, och ingen av dem är samma sak som att märka att tunneln är uppe.

Det är olika signaler från olika lager, och var och en har en ägare som kan agera på den utan att gissa. Att blanda dem ger ett system som startar om på symtom det inte kan tolka.

Skriv ner de tre fallen innan du ändrar någon timer. Listan i sig visar oftast att en mekanism ombeds täcka alla tre.

Vad keepalive faktiskt expanderar till

Direktivet keepalive är en förkortning, och expansionen skiljer sig mellan lägen. På en server blir keepalive 10 60 en lokal ping var tionde sekund, en lokal omstartstimeout på 120 sekunder och pushade värden på 10 och 60 för klienter. Serverns timeout fördubblas medvetet så att en klient får en chans att starta om innan servern ger upp. Läs den expanderade formen i den körande konfigurationen i stället för förkortningen i profilen.

Den fördubblingen är varför varje beskrivning som påstår att båda ändarna startar om efter sextio sekunder är fel. Det förklarar också varför de två ändarna inte fladdrar i takt när en väg försämras.

Hjärtslagen är OpenVPN-peer-trafik, inte en ICMP-probe mot någon offentlig värd. Ett svar bevisar bara att tunnelns bortre ände lever. Det säger ingenting om databasen eller webbtjänsten användaren faktiskt behöver.

Vad Restart=on-failure inte bevakar

Läs den installerade uniten innan du lägger till en override. Restart=on-failure svarar på dokumenterade processfelvillkor, vilket inte är samma sak som att bevaka anslutningstillstånd. Det utlöses inte för att en intern återanslutning startade, och en ren avslutning har annan semantik än en krasch.

Den skillnaden spelar roll eftersom en intern omstart håller samma process vid liv. Uniten ser ingenting, tunneln återhämtar sig själv, och det är rätt utfall.

Sätt RestartSec och startgränser medvetet, annars kommer en kraschloop att hamra på gatewayen och begrava det verkliga felet under omstartsmeddelanden. En omstartsgräns som utlöses lämnar uniten misslyckad, vilket syns, medan en obegränsad loop inte gör det.

ping-restart och ping-exit är inte utbytbara

ping-restart utlöser OpenVPN:s interna omstart och behåller processen. ping-exit avslutar processen vid samma typ av timeout, vilket överlämnar beslutet till tjänstehanteraren. De är ömsesidigt uteslutande, och att välja den andra ändrar vem som äger återhämtningen. Skillnaden är vem som beslutar att försöka igen, och hur mycket tillstånd som överlever försöket.

Om du väljer exit-on-timeout behöver uniten en omstartspolicy och exit-status-hantering som matchar, annars ser ett liveness-fel ut som ett permanent stopp. Persistensalternativ kan också bevara gränssnitt och rutter över en intern omstart men inte över en processavslutning.

Välj en livscykel per driftsättning och skriv ner varför. En profil som bär båda direktiven är en profil som inte har bestämt sig.

Testa varje fel som ett eget fall

Simulera en tyst peer, en dödad daemon och en otillgänglig applikation i ett godkänt fönster, och kontrollera sedan vilken återhämtning som utlöstes. En tyst peer bör ge en intern återanslutning, en dödad process en unit-omstart, och ett applikationsavbrott inget av dem. När två fall ger samma åtgärd är ägarskapet fortfarande blandat.

Upprepad återhämtning är inte heller en reparation. Avvisade inloggningsuppgifter eller två klienter som delar ett effektivt namn kommer att fortsätta ersätta varandra, och snabbare timers gör bara det fladdrandet snabbare.