keepalive in OpenVPN of systemd-restart: wat herstelt de tunnel?
Een stille peer, een dood proces en een onbruikbare toepassing zijn drie verschillende storingen. Geef OpenVPN de keepalive, systemd het proces, en test elk geval.
Drie verschillende dingen kunnen misgaan met een tunnel, en ze vragen drie verschillende reacties. De peer stopt met antwoorden, het daemonproces sterft, of de toepassing achter de tunnel stopt met bedienen. Een configuratie die bij elk daarvan de dienst herstart, is geen zorgvuldig toezicht; het is één botte actie op ongerelateerde storingen. Vergelijken wat elk mechanisme werkelijk kan waarnemen maakt de taakverdeling duidelijk.
Drie storingen die op één lijken
Stilte van de peer betekent dat de andere kant stopte met zenden, en OpenVPN kan dat zelf detecteren omdat het de hartslag bezit. Procesdood betekent dat de daemon is afgesloten, wat de servicemanager opmerkt en OpenVPN niet kan. Applicatiestoring betekent dat de tunnel in orde is en iets erachter niet, en geen van de andere twee mechanismen heeft een manier om dat te weten. Elk vraagt een andere reactie, en geen ervan is hetzelfde als opmerken dat de tunnel leeft.
Dit zijn verschillende signalen uit verschillende lagen, en elk heeft een eigenaar die er zonder gokken op kan handelen. Ze mengen levert een systeem op dat herstart op symptomen die het niet kan interpreteren.
Schrijf de drie gevallen op voordat je een timer wijzigt. De lijst zelf laat meestal zien dat één mechanisme wordt gevraagd alle drie te dekken.
Waartoe keepalive zich werkelijk uitstrekt
De richtlijn keepalive is een afkorting, en de uitbreiding verschilt per modus. Op een server wordt keepalive 10 60 een lokale ping elke tien seconden, een lokale herstarttermijn van 120 seconden en waarden 10 en 60 die naar clients worden gestuurd. De termijn van de server wordt bewust verdubbeld zodat een client de kans krijgt te herstarten voordat de server opgeeft. Lees de uitgebreide vorm in de draaiende configuratie, niet de afkorting in het profiel.
Die verdubbeling is de reden dat elke beschrijving die beweert dat beide kanten na zestig seconden herstarten onjuist is. Het verklaart ook waarom de twee kanten niet gelijkmatig flapperen wanneer een pad verslechtert.
De hartslag is OpenVPN-peerverkeer, geen ICMP-probe naar een publieke host. Een antwoord bewijst alleen dat de verre kant van de tunnel leeft. Het zegt niets over de database of webservice die de gebruiker werkelijk nodig heeft.
Wat Restart=on-failure niet bewaakt
Lees de geïnstalleerde unit voordat je een override toevoegt. Restart=on-failure reageert op gedocumenteerde processtoringen, wat niet hetzelfde is als de verbindingsstatus bewaken. Het treedt niet in werking omdat een interne herverbinding begon, en een schone afsluiting heeft een andere betekenis dan een crash.
Dat onderscheid is belangrijk omdat een interne herstart hetzelfde proces in leven houdt. De unit ziet niets, de tunnel herstelt zichzelf, en dat is de juiste uitkomst.
Stel RestartSec en startlimieten bewust in, anders hamert een crashlus op de gateway en begraaft de echte fout onder herstartmeldingen. Een herstartlimiet die afgaat laat de unit in storing achter, wat zichtbaar is, terwijl een onbeperkte lus dat niet is.
ping-restart en ping-exit zijn niet uitwisselbaar
ping-restart veroorzaakt de interne herstart van OpenVPN en houdt het proces. ping-exit beëindigt het proces bij hetzelfde soort termijn, wat de beslissing aan de servicemanager overlaat. Ze sluiten elkaar uit, en het tweede kiezen verandert wie het herstel bezit. Het verschil is wie besluit het opnieuw te proberen, en hoeveel toestand de poging overleeft.
Als je voor afsluiten bij timeout kiest, heeft de unit een herstartbeleid en afhandeling van de afsluitstatus nodig die passen, anders lijkt een levensvatbaarheidsstoring op een permanente stop. Persistentieopties kunnen interfaces en routes ook behouden over een interne herstart, maar niet over een procesafsluiting.
Kies één levenscyclus per uitrol en schrijf op waarom. Een profiel dat beide richtlijnen draagt, is een profiel dat niet heeft besloten.
Test elke storing als zijn eigen geval
Simuleer een stille peer, een gedode daemon en een niet-beschikbare toepassing in een goedgekeurd venster, en controleer dan welk herstel afging. Een stille peer zou een interne herverbinding moeten geven, een gedood proces een unit-herstart, en een applicatiestoring geen van beide. Wanneer twee gevallen dezelfde actie geven, is het eigenaarschap nog steeds gemengd.
Herhaald herstel is ook geen reparatie. Geweigerde inloggegevens of twee clients die één effectieve naam delen, blijven elkaar vervangen, en snellere timers maken dat flapperen alleen sneller.