Restarte OpenVPN daglig? Velg feilen, ikke klokken

Du arver en cron-jobb som restarter OpenVPN hver dag klokken 04:10, og den har holdt ting stabile i et år. Den kobler også ned en sunn tunnel på et fast tidspunkt og gjør ingenting med det avbruddet som faktisk skjer i lunsjen. En omstart etter kalenderen er et vedlikeholdsvedtak. Gjenoppretting er et annet design med en bestemt utløser.

Tre feilformer trenger tre ulike eiere. Velg feilen først, så følger mekanismen.

Tre feil, tre eiere

En tunnel kan være oppe mens peeren er borte: prosessen kjører, grensesnittet finnes, og ingenting nyttig går gjennom det. En prosess kan være død mens peeren er i orden, og da kan bare det som startet den bringe den tilbake. En applikasjon bak tunnelen kan være ødelagt mens både tunnelen og peeren er sunne, og å restarte klienten da utvider avbruddet uten å røre årsaken. Å skille disse tre tilfellene er hele avgjørelsen.

Hver har sitt eget signal og sin egen eier. Levedyktighet tilhører VPN-protokollen, prosessens livssyklus tilhører tjenestebehandleren, og applikasjonens helse tilhører overvåking med et snevert mandat.

Hva et levedyktighetsvalg kan og ikke kan gjøre

keepalive er en hjelper som utvider seg til et ping- og ping-restart-par, slik referansen for koblingsvalg beskriver, og tidsavbruddene den produserer er ikke identiske på serveren og klienten. Verdier som en server sender kan også overstyre det en klient har konfigurert lokalt, og derfor er et tidsavbrudd som ser riktig ut i en lokal fil kanskje ikke det som gjelder.

Det gjør den til det riktige verktøyet for en tapt peer og det gale verktøyet for en død prosess, siden en avsluttet prosess ikke kan kjøre sine egne tidtakere. Den sier heller ingenting om hvorvidt en applikasjon bak tunnelen svarer, fordi utvekslingen skjer mellom de to VPN-endepunktene. Å kopiere et tidsavbruddspar fra en annen utrulling uten å sjekke rolle, forventede avbrudd og reautentiseringsadferd er måten en stabil tunnel begynner å flagre på.

Hva tjenestebehandleren eier

Hvis daemonen avsluttes, bestemmer behandleren som startet den hva som skjer videre. En omstartspolicy knyttet til feil, med forsinkelse og grense for startfrekvens, håndterer en krasjløkke uten å gjøre den til en fork-bombe. Disse innstillingene reagerer på prosessutfall og tidsavbrudd, og de oppdager ikke en prosess som lever men er ubrukelig. Det er ikke et hull som skal lappes med en bredere policy; det er grensen mellom livssyklus og levedyktighet.

Eierskap betyr like mye som innstillingene. En tilkobling startet av en nettverksbehandler på skrivebordet bør beholde den behandlerens gjenopprettingsordning, og å legge til en konkurrerende tjenesteenhet for samme grensesnitt gir én tunnel to eiere. Velg én, og skriv ned hvilken.

Når en planlagt omstart er berettiget

En tidsbestemt omstart kan være en rimelig vedlikeholdshandling: den har en eier, et vindu, en navngitt instans og en uavhengig inngangsvei. Det den ikke kan være, er en generell pålitelighetspolicy som også kobler alle ned på et fast tidspunkt.

Hvis omstarten finnes for å omgå en kjent lekkasje eller en fastlåst tilstand, si det i enhetens beskrivelse, ellers beholder neste person den for alltid.

Test tilfellene som betyr noe: peeren forsvinner mens prosessen blir oppe, prosessen avsluttes, et nytt forsøk trenger ferske påloggingsdata, og tunnelen kommer tilbake mens applikasjonen forblir ødelagt. Se hvilken komponent som reagerer og hvilken tilstand den etterlater.

Det riktige spørsmålet er ikke hvor ofte man skal restarte, men hva som bør oppdage feilen først.