OpenVPN held fram med å prøve på nytt etter ein TLS-feil: slik stoppar du det

Klienten koplar til, feilar under TLS-forhandlinga, ventar og prøver same tenar igjen med same resultat. Under ein overvakar som startar ein mislukka prosess på nytt, vert desse forsøka ei endelaus løkke i journalen, og den første diagnostiske linja forsvinn ut av syne. OpenVPN har eit val som gjer den forhandlingsfeilen om til ei synleg avslutning i staden for eit nytt forsøk. Det er ei innstilling for diagnostikk og overvaking, ikkje ei reparasjon, så kombiner ho med ein policy som faktisk lèt prosessen bli liggjande nede.

Syklusen som skjuler den første feilen

Det du ser, er ein gjenteken blokk og ikkje éin feil: eit tilkoplingsforsøk, ein TLS-feil, ei pause og deretter same sekvens. Kvar gjentaking skyt den opphavlege linja lenger opp i journalen. Viss eininga startar på nytt ved feil, kan syklusen halde fram i timar utan at nokon les årsaka. Symtomet er løkka, sjølv om den underliggjande feilen er eitt enkelt forhandlingsproblem.

Interaktive økter toler dette fordi ein forbigåande feil kan forsvinne ved neste forsøk. Automatiske tilkoplingar har ikkje råd til same optimisme: prosessen må stoppe slik at eit menneske eller ein monitor ser statusen.

Før du endrar noko, fang ein full syklus. Noter fjernadressa, TLS-trinnet som er nemnt i feilen, og om prosessen i det heile avsluttar.

Forsøksmekanismen bak løkka

Nytt forsøk er standard fordi fleire urelaterte tidsavbrot deler same mekanisme. connect-retry set intervallet mellom tilkoplingsforsøk, connect-retry-max kan avgrense kor ofte kvar fjernoppføring vert prøvd, og resolv-retry styrer gjentekne namneoppslag. Ein TLS-forhandlingsfeil når denne mekanismen som ei transporthending, så klienten planlegg eit nytt forsøk i staden for å rapportere. Standardverdien hjelper på ei ustabil line og skadar ved ein feil som ikkje kan legast.

Valet --tls-exit endrar berre forhandlingstilfellet. Handboka skildrar det som å avslutte ved TLS-forhandlingsfeil, som er snevrare enn å avslutte ved kvar feil. Tidsavbrot, resolverfeil og autentiseringsavvisingar held på si eiga åtferd.

Få klienten til å avslutte ved TLS-feil

Set tls-exit i profilen klienten faktisk lastar, eller gje --tls-exit ved oppstart, og køyr han éin gong i forgrunnen. Les avslutningsstatusen og den siste logglinja, fordi det er statusen ein overvakar handlar på. Ei avslutning ulik null etter ein forhandlingsfeil er det tilsikta resultatet. Viss prosessen held fram med å prøve i staden for å avslutte, står ikkje valet i profilen klienten faktisk lastar.

Overvakaren avgjer om avslutninga er synleg. Ei systemd-eining med Restart=always eller Restart=on-failure startar klienten på nytt, så løkka held fram og valet ser ut til å ikkje gjere noko. Sjekk policyen før du klandrar klienten:

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

Restart=no lèt prosessen bli liggjande nede, og Restart=on-failure startar likevel på nytt etter ein status ulik null. Viss du vil at feilen skal vere synleg, men tenesta skal kome seg etter urelaterte krasj, set du Restart=on-failure og brukar StartLimitBurst og StartLimitIntervalSec for å stoppe restartstormen. Les deretter statusen til eininga for å stadfeste den siste avslutningskoden: systemctl status rapporterer han, og journalen held på den første feilen over restartane.

Skriv avgjerda i eininga eller i profilnotata. Ein profil som avsluttar ved TLS-feil ser ut som eit uhell for den neste personen med mindre årsaka er notert. Angi kva feil som skal stoppe prosessen og kva som skal prøvast på nytt.

Prov det med eit eingongsendepunkt

For å sjå åtferda før du stolar på ho, kopier profilen og peik kopien mot eit endepunkt som godtar ei TCP-tilkopling, men aldri snakkar OpenVPN. Ein lyttar som svarar og deretter teier, er nok. Med tls-exit skal klienten avslutte når handtrykket feilar; utan det skal same profil halde fram med å gå i ring. Bruk kopien, aldri arbeidsprofilen.

Samanlikn dei to køyringane etter avslutningsstatus og første feillinje, ikkje etter kor lenge kvar varte. Statusen seier om valet slo til, og den første linja seier kva trinn som feila.

Fjern testprofilen når du er ferdig. Ein kopi med eit medvite feil endepunkt er ei felle for alle som seinare startar kvar profil i mappa.

Trinn dette valet aldri når

Ei autentiseringsavvising er eit seinare trinn. Viss tenaren vurderer kontoen og avviser han, er TLS alt forhandla, så tls-exit slår ikkje til. Innstillingane for nytt forsøk ved autentisering er neste stad å sjå, og årsaka til tenaren veg tyngre enn den siste linja til klienten. Feil passord og manglande sertifikat kan gje liknande meldingar på klientsida.

Ei manglande rute, feil resolver eller ein utilgjengeleg gateway er også utanfor valet, fordi dei ikkje er forhandlingsfeil. Stille pakketap er det minst openberre tilfellet: avhengig av kor langt utvekslinga kom, kan klienten rapportere ein forhandlingsfeil eller rett og slett gå i tidsavbrot.

Hald skillet i notata dine. Innstillinga er for diagnostikk og overvaking snarare enn reparasjon, så ho fiksar ikkje eit cipher-avvik, eit sertifikatproblem eller ei feil port. Reparer årsaka til den mislukka forhandlinga først, og avgjer deretter om ei umiddelbar avslutning framleis passar for utrullinga.