OpenVPN dagelijks herstarten? Kies de storing, niet de klok

Je erft een cron-taak die OpenVPN elke dag om 04:10 herstart, en die houdt de zaken al een jaar stabiel. Hij verbreekt ook een gezonde tunnel op een vast tijdstip en doet niets aan de storing die in werkelijkheid tijdens de lunch gebeurt. Een herstart volgens de kalender is een onderhoudsbeslissing. Herstel is een ander ontwerp, met een specifieke trigger.

Drie storingsvormen vragen drie verschillende eigenaren. Kies eerst de storing, dan volgt het mechanisme.

Drie storingen, drie eigenaren

Een tunnel kan actief zijn terwijl zijn peer weg is: het proces draait, de interface bestaat en er gaat niets nuttigs doorheen. Een proces kan dood zijn terwijl de peer in orde is, en dan kan alleen wat het heeft gestart het terugbrengen. Een applicatie achter de tunnel kan stuk zijn terwijl zowel de tunnel als de peer gezond zijn, en het herstarten van de client vergroot dan de storing zonder de oorzaak te raken. Die drie gevallen scheiden is de hele beslissing.

Elk heeft zijn eigen signaal en zijn eigen eigenaar. Leefbaarheid hoort bij het VPN-protocol, de levenscyclus van het proces bij de servicemanager, en de gezondheid van de applicatie bij monitoring met een smal mandaat.

Wat een leefbaarheidsoptie wel en niet kan

keepalive is een hulpje dat uitgroeit tot een ping- en ping-restart-paar, zoals de referentie voor linkopties beschrijft, en de time-outs die het oplevert zijn niet identiek op de server en de client. Waarden die een server pusht kunnen ook overschrijven wat een client lokaal heeft ingesteld, en daarom is een time-out die in een lokaal bestand juist lijkt misschien niet degene die geldt.

Daardoor is het het juiste gereedschap voor een verloren peer en het verkeerde gereedschap voor een dood proces, want een afgesloten proces kan zijn eigen timers niet laten lopen. Het zegt ook niets over of een applicatie achter de tunnel antwoordt, omdat de uitwisseling tussen de twee VPN-eindpunten plaatsvindt. Een time-outpaar uit een andere uitrol kopiëren zonder rol, verwachte onderbrekingen en herauthenticatiegedrag te controleren is hoe een stabiele tunnel gaat fladderen.

Wat de servicemanager bezit

Als de daemon stopt, beslist de manager die hem heeft gestart wat er daarna gebeurt. Een herstartbeleid dat op falen is gebaseerd, met een vertraging en een limiet op de startsnelheid, behandelt een crash-lus zonder er een forkbom van te maken. Die instellingen reageren op procesuitkomsten en time-outs, en ze detecteren geen proces dat leeft maar nutteloos is. Dat is geen gat om met een breder beleid te dichten; het is de grens tussen levenscyclus en leefbaarheid.

Eigendom is net zo belangrijk als de instellingen. Een verbinding die door een netwerkbeheerder op de desktop is gestart, moet de herstelregeling van die beheerder houden, en een concurrerende service-unit voor dezelfde interface toevoegen geeft één tunnel twee eigenaren. Kies er één en schrijf op welke.

Wanneer een geplande herstart gerechtvaardigd is

Een herstart op een vaste tijd kan een redelijke onderhoudsactie zijn: hij heeft een eigenaar, een venster, een genoemde instantie en een onafhankelijke ingang. Wat hij niet kan zijn, is een algemeen betrouwbaarheidsbeleid dat ook iedereen op een vast tijdstip loskoppelt.

Als de herstart bestaat om een bekend lek of een vastgelopen toestand te omzeilen, zeg dat dan in de beschrijving van de unit, want anders houdt de volgende persoon hem voor altijd.

Test de gevallen die ertoe doen: de peer verdwijnt terwijl het proces blijft draaien, het proces stopt, een nieuwe poging vraagt om verse inloggegevens, en de tunnel komt terug terwijl de applicatie stuk blijft. Kijk welke component reageert en welke toestand die achterlaat.

De juiste vraag is niet hoe vaak je moet herstarten, maar wat de storing als eerste zou moeten opmerken.