OpenVPN fortsetter å prøve på nytt etter en TLS-feil: slik stopper du det

Klienten kobler til, feiler under TLS-forhandlingen, venter og prøver samme server igjen med samme resultat. Under en overvåker som restarter en mislykket prosess, blir disse forsøkene en endeløs løkke i journalen, og den første diagnostiske linjen forsvinner ut av syne. OpenVPN har et alternativ som gjør den forhandlingsfeilen til en synlig avslutning i stedet for et nytt forsøk. Det er en innstilling for diagnostikk og overvåking, ikke en reparasjon, så kombiner den med en policy som faktisk lar prosessen bli liggende nede.

Syklusen som skjuler den første feilen

Det du ser, er en gjentatt blokk og ikke én feil: et tilkoblingsforsøk, en TLS-feil, en pause og deretter samme sekvens. Hver gjentakelse skyver den opprinnelige linjen lenger opp i journalen. Hvis enheten restarter ved feil, kan syklusen fortsette i timer uten at noen leser årsaken. Symptomet er løkken, selv om den underliggende feilen er ett enkelt forhandlingsproblem.

Interaktive økter tåler dette fordi en forbigående feil kan forsvinne ved neste forsøk. Automatiske tilkoblinger har ikke råd til samme optimisme: prosessen må stoppe slik at et menneske eller en monitor ser statusen.

Før du endrer noe, fang én full syklus. Noter fjernadressen, TLS-trinnet som er nevnt i feilen, og om prosessen i det hele tatt avslutter.

Forsøksmekanismen bak løkken

Nytt forsøk er standard fordi flere urelaterte tidsavbrudd deler samme mekanisme. connect-retry setter intervallet mellom tilkoblingsforsøk, connect-retry-max kan begrense hvor ofte hver fjernoppføring prøves, og resolv-retry styrer gjentatte navneoppslag. En TLS-forhandlingsfeil når denne mekanismen som en transporthendelse, så klienten planlegger et nytt forsøk i stedet for å rapportere. Standardverdien hjelper på en ustabil linje og skader ved en feil som ikke kan leges.

Alternativet --tls-exit endrer bare forhandlingstilfellet. Håndboken beskriver det som å avslutte ved TLS-forhandlingsfeil, som er snevrere enn å avslutte ved enhver feil. Tidsavbrudd, resolverfeil og autentiseringsavvisninger beholder sin egen oppførsel.

Få klienten til å avslutte ved TLS-feil

Sett tls-exit i profilen klienten faktisk laster, eller gi --tls-exit ved oppstart, og kjør den én gang i forgrunnen. Les avslutningsstatusen og den siste logglinjen, fordi det er statusen en overvåker handler på. En avslutning ulik null etter en forhandlingsfeil er det tilsiktede resultatet. Hvis prosessen fortsetter å prøve i stedet for å avslutte, står ikke alternativet i profilen klienten faktisk laster.

Overvåkeren avgjør om avslutningen er synlig. En systemd-enhet med Restart=always eller Restart=on-failure starter klienten igjen, så løkken fortsetter og alternativet ser ut til å ikke gjøre noe. Sjekk policyen før du klandrer klienten:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no lar prosessen bli liggende nede, og Restart=on-failure restarter likevel etter en status ulik null. Hvis du vil at feilen skal være synlig, men tjenesten skal komme seg etter urelaterte krasj, setter du Restart=on-failure og bruker StartLimitBurst og StartLimitIntervalSec for å stoppe restartstormen. Les deretter enhetens status for å bekrefte den siste avslutningskoden: systemctl status rapporterer den, og journalen beholder den første feilen over restartsene.

Skriv beslutningen i enheten eller i profilnotatene. En profil som avslutter ved TLS-feil ser ut som et uhell for den neste personen med mindre årsaken er notert. Angi hvilke feil som skal stoppe prosessen og hvilke som skal prøves på nytt.

Bevis det med et engangsendepunkt

For å se oppførselen før du stoler på den, kopier profilen og pek kopien mot et endepunkt som godtar en TCP-tilkobling, men aldri snakker OpenVPN. En lytter som svarer og deretter tier, er nok. Med tls-exit skal klienten avslutte når håndtrykket feiler; uten det skal samme profil fortsette å gå i ring. Bruk kopien, aldri arbeidsprofilen.

Sammenlign de to kjøringene etter avslutningsstatus og første feillinje, ikke etter hvor lenge hver varte. Statusen sier om alternativet utløste, og den første linjen sier hvilket trinn som feilet.

Fjern testprofilen når du er ferdig. En kopi med et bevisst feil endepunkt er en felle for alle som senere starter hver profil i mappen.

Trinn dette alternativet aldri når

En autentiseringsavvisning er et senere trinn. Hvis serveren vurderer kontoen og avviser den, er TLS allerede forhandlet, så tls-exit utløses ikke. Innstillingene for nytt forsøk ved autentisering er neste sted å se, og serverens årsak betyr mer enn klientens siste linje. Feil passord og manglende sertifikat kan gi lignende meldinger på klientsiden.

En manglende rute, feil resolver eller en utilgjengelig gateway er også utenfor alternativet, fordi de ikke er forhandlingsfeil. Stille pakketap er det minst åpenbare tilfellet: avhengig av hvor langt utvekslingen kom, kan klienten rapportere en forhandlingsfeil eller rett og slett gå i tidsavbrudd.

Hold skillet i notatene dine. Innstillingen er for diagnostikk og overvåking snarere enn reparasjon, så den fikser ikke et cipher-avvik, et sertifikatproblem eller en feil port. Reparer årsaken til den mislykkede forhandlingen først, og avgjør deretter om umiddelbar avslutning fortsatt passer for utrullingen.