OpenVPN bliver ved med at prøve igen efter en TLS-fejl: sådan stopper du det

Klienten opretter forbindelse, fejler under TLS-forhandlingen, venter og prøver den samme server igen med samme resultat. Under en supervisor, der genstarter en fejlende proces, bliver disse forsøg en endeløs løkke i journalen, og den første diagnostiske linje ruller ud af syne. OpenVPN leverer en indstilling, der gør den forhandlingsfejl til en synlig afslutning i stedet for endnu et forsøg. Det er en indstilling til diagnosticering og overvågning, ikke en reparation, så par den med en politik, der faktisk lader processen blive nede.

Cyklussen, der skjuler den første fejl

Det, du ser, er en gentagen blok og ikke én fejl: et forbindelsesforsøg, en TLS-fejl, en pause og derefter samme sekvens. Hver gentagelse skubber den oprindelige linje længere op i journalen. Hvis enheden genstarter ved fejl, kan cyklussen fortsætte i timer, uden at nogen læser årsagen. Symptomet er løkken, selv om den underliggende fejl er ét enkelt forhandlingsproblem.

Interaktive sessioner tåler det, fordi en forbigående fejl kan forsvinde ved næste forsøg. Automatiske forbindelser har ikke råd til samme optimisme: processen skal stoppe, så et menneske eller en monitor kan se status.

Før du ændrer noget, skal du fange én fuld cyklus. Noter fjernadressen, det TLS-trin, der nævnes i fejlen, og om processen overhovedet afslutter.

Genforsøgsmekanikken bag løkken

Genforsøg er standarden, fordi flere urelaterede timeouts deler den samme mekanik. connect-retry sætter afstanden mellem forbindelsesforsøg, connect-retry-max kan begrænse, hvor ofte hver fjernpost prøves, og resolv-retry styrer gentagne navneopslag. En TLS-forhandlingsfejl når denne mekanik som en transportbegivenhed, så klienten planlægger endnu et forsøg i stedet for at rapportere. Standardværdien er nyttig ved et ustabilt link og skadelig ved en fejl, der ikke kan hele.

Indstillingen --tls-exit ændrer kun forhandlingstilfældet. Manualen beskriver den som at afslutte ved TLS-forhandlingsfejl, hvilket er snævrere end at afslutte ved enhver fejl. Timeouts, resolverfejl og afviste godkendelser beholder deres egen adfærd.

Få klienten til at afslutte ved TLS-fejl

Sæt tls-exit i den profil, klienten faktisk indlæser, eller giv --tls-exit ved opstart, og kør den én gang i forgrunden. Læs exitstatus såvel som den sidste loglinje, fordi status er det, en supervisor handler på. En ikke-nul-exit efter en forhandlingsfejl er det tilsigtede resultat. Hvis processen bliver ved med at prøve igen i stedet for at slutte, er indstillingen ikke i den profil, klienten faktisk indlæser.

Supervisoren afgør, om den exit er synlig. En systemd-enhed med Restart=always eller Restart=on-failure starter klienten igen, så løkken fortsætter, og indstillingen ser ud til ikke at gøre noget. Kontroller politikken, før du bebrejder klienten:

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

Restart=no lader processen blive nede, og Restart=on-failure genstarter stadig efter en ikke-nul-status. Hvis du vil have fejlen synlig, men tjenesten skal komme sig over urelaterede nedbrud, så sæt Restart=on-failure og brug StartLimitBurst og StartLimitIntervalSec til at stoppe genstartsstormen. Læs derefter enhedens status for at bekræfte den sidste exitkode: systemctl status rapporterer den, og journalen bevarer den første fejl over genstarterne.

Skriv beslutningen i enheden eller i profilnoterne. En profil, der afslutter ved TLS-fejl, ligner en fejl for den næste person, medmindre årsagen er noteret. Angiv, hvilke fejl der skal stoppe processen, og hvilke der skal forsøges igen.

Bevis det med et midlertidigt endepunkt

For at se adfærden, før du stoler på den, skal du kopiere profilen og pege kopien mod et endepunkt, der accepterer en TCP-forbindelse, men aldrig taler OpenVPN. En lytter, der svarer og derefter forbliver tavs, er nok. Med tls-exit bør klienten slutte, når håndtrykket fejler; uden den bør den samme profil blive ved med at cykle. Brug kopien, aldrig den fungerende profil.

Sammenlign de to kørsler på exitstatus og på den første fejllinje, ikke på hvor længe hver varede. Status fortæller, om indstillingen blev udløst, og den første linje fortæller, hvilket trin der fejlede.

Fjern testprofilen, når du er færdig. En kopi med et bevidst forkert endepunkt er en fælde for enhver, der senere starter hver profil i mappen.

Trin, som denne indstilling aldrig når

En afvist godkendelse er et senere trin. Hvis serveren vurderer kontoen og afviser den, er TLS allerede forhandlet, så tls-exit udløses ikke. Genforsøgsindstillingerne for godkendelse er det næste sted at kigge, og serverens årsag betyder mere end klientens sidste linje. En forkert adgangskode og et manglende certifikat kan give lignende beskeder på klientsiden.

En manglende rute, en forkert resolver eller en uopnåelig gateway er også uden for indstillingen, fordi de ikke er forhandlingsfejl. Tavst pakketab er det mindst oplagte tilfælde: afhængigt af hvor langt udvekslingen nåede, kan klienten rapportere en forhandlingsfejl eller bare timeout.

Hold sondringen i dine noter. Indstillingen er til diagnosticering og overvågning snarere end reparation, så den retter ikke et cipher-mismatch, et certifikatproblem eller en forkert port. Reparer årsagen til den mislykkede forhandling først, og beslut derefter, om øjeblikkelig afslutning stadig passer til udrulningen.