Tre forskjellige ting kan gå galt med en tunnel, og de krever tre forskjellige reaksjoner. Motparten slutter å svare, daemonprosessen dør, eller applikasjonen bak tunnelen slutter å betjene. En konfigurasjon som starter tjenesten på nytt ved enhver av dem, er ikke nøye overvåking; det er én grov handling brukt på urelaterte feil. Å sammenligne hva hver mekanisme faktisk kan observere gjør arbeidsdelingen åpenbar.

Tre feil som ser ut som én

Stillhet fra motparten betyr at den andre enden sluttet å sende, og OpenVPN kan oppdage det selv fordi det eier hjerteslaget. Prosessdød betyr at daemonen avsluttet, noe tjenestebehandleren merker og OpenVPN ikke kan. Applikasjonsfeil betyr at tunnelen er fin og noe bak den ikke, og ingen av de to andre mekanismene har noen måte å vite det på. Hver av dem trenger en annen reaksjon, og ingen av dem er det samme som å merke at tunnelen er oppe.

Dette er forskjellige signaler fra forskjellige lag, og hver har en eier som kan handle på det uten å gjette. Å blande dem gir et system som starter på nytt på symptomer det ikke kan tolke.

Skriv ned de tre tilfellene før du endrer noen timer. Listen viser vanligvis at én mekanisme blir bedt om å dekke alle tre.

Hva keepalive faktisk utvider til

Direktivet keepalive er en forkortelse, og utvidelsen varierer etter modus. På en server blir keepalive 10 60 et lokalt ping hvert tiende sekund, en lokal omstartsfrist på 120 sekunder og verdiene 10 og 60 som sendes til klienter. Serverens frist dobles bevisst slik at en klient får en sjanse til å starte på nytt før serveren gir opp. Les den utvidede formen i den kjørende konfigurasjonen, ikke forkortelsen i profilen.

Den doblingen er grunnen til at enhver beskrivelse som hevder at begge ender starter på nytt etter seksti sekunder, er feil. Det forklarer også hvorfor de to endene ikke blafrer i takt når en rute forverres.

Hjerteslaget er OpenVPN-motpartstrafikk, ikke en ICMP-sondering av en offentlig vert. Et svar beviser bare at den fjerne enden av tunnelen er i live. Det sier ingenting om databasen eller webtjenesten brukeren faktisk trenger.

Hva Restart=on-failure ikke overvåker

Les den installerte enheten før du legger til en overstyring. Restart=on-failure reagerer på dokumenterte prosessfeiltilstander, som ikke er det samme som å overvåke tilkoblingstilstanden. Den utløses ikke fordi en intern gjenoppkobling startet, og en ren avslutning har en annen betydning enn en krasj.

Den forskjellen betyr noe fordi en intern omstart holder den samme prosessen i live. Enheten ser ingenting, tunnelen kommer seg selv, og det er det riktige resultatet.

Sett RestartSec og startgrenser bevisst, ellers vil en krasjløkke hamre på gatewayen og begrave den egentlige feilen under omstartsmeldinger. En omstartsgrense som utløses, etterlater enheten i feil, noe som er synlig, mens en ubegrenset løkke ikke er det.

ping-restart og ping-exit kan ikke byttes om

ping-restart utløser OpenVPNs interne omstart og beholder prosessen. ping-exit avslutter prosessen ved samme type frist, noe som overlater beslutningen til tjenestebehandleren. De utelukker hverandre, og å velge den andre endrer hvem som eier gjenopprettingen. Forskjellen er hvem som bestemmer seg for å prøve igjen, og hvor mye tilstand som overlever forsøket.

Hvis du velger avslutning ved tidsavbrudd, trenger enheten en omstartspolicy og håndtering av avslutningsstatus som passer, ellers ser en levedyktighetsfeil ut som en permanent stopp. Persistensalternativer kan også bevare grensesnitt og ruter gjennom en intern omstart, men ikke gjennom en prosessavslutning.

Velg én livssyklus per utrulling og skriv ned hvorfor. En profil som bærer begge direktivene, er en profil som ikke har bestemt seg.

Test hver feil som sitt eget tilfelle

Simuler en stille motpart, en drept daemon og en utilgjengelig applikasjon i et godkjent vindu, og kontroller deretter hvilken gjenoppretting som ble utløst. En stille motpart bør gi en intern gjenoppkobling, en drept prosess en enhetsomstart, og et applikasjonsavbrudd ingen av delene. Når to tilfeller gir samme handling, er eierskapet fortsatt blandet.

Gjentatt gjenoppretting er heller ikke en reparasjon. Avviste påloggingsdata eller to klienter som deler ett effektivt navn, vil fortsette å erstatte hverandre, og raskere timere gjør bare den blafringen raskere.

Relaterte artikler