OpenVPN fortsätter att försöka igen efter ett TLS-fel: så stoppar du det

Klienten ansluter, misslyckas under TLS-förhandlingen, väntar och försöker samma server igen med samma resultat. Under en övervakare som startar om en misslyckad process blir dessa försök en oändlig loop i journalen, och den första diagnostiska raden försvinner ur synfältet. OpenVPN har ett alternativ som gör det förhandlingsfelet till en synlig avslutning i stället för ett nytt försök. Det är en inställning för diagnostik och övervakning, inte en reparation, så kombinera den med en policy som faktiskt låter processen ligga nere.

Cykeln som döljer det första felet

Det du ser är ett upprepande block och inte ett enda fel: ett anslutningsförsök, ett TLS-fel, en paus och sedan samma sekvens. Varje upprepning skjuter den ursprungliga raden högre upp i journalen. Om enheten startar om vid fel kan cykeln fortsätta i timmar utan att någon läser orsaken. Symtomet är loopen, även om det underliggande felet är ett enda förhandlingsproblem.

Interaktiva sessioner tål detta eftersom ett tillfälligt fel kan försvinna vid nästa försök. Automatiska anslutningar har inte råd med samma optimism: processen måste stanna så att en människa eller en monitor ser statusen.

Innan du ändrar något, fånga en fullständig cykel. Notera fjärradressen, det TLS-steg som nämns i felet och om processen överhuvudtaget avslutar.

Försöksmekanismen bakom loopen

Nytt försök är standard eftersom flera orelaterade tidsgränser delar samma mekanism. connect-retry ställer in intervallet mellan anslutningsförsök, connect-retry-max kan begränsa hur ofta varje fjärrpost prövas, och resolv-retry styr upprepade namnsökningar. Ett TLS-förhandlingsfel når den mekanismen som en transporthändelse, så klienten planerar ett nytt försök i stället för att rapportera. Standardvärdet hjälper vid en instabil länk och skadar vid ett fel som inte kan läkas.

Alternativet --tls-exit ändrar bara förhandlingsfallet. Handboken beskriver det som att avsluta vid TLS-förhandlingsfel, vilket är snävare än att avsluta vid varje fel. Tidsgränser, resolverfel och autentiseringsavvisningar behåller sitt eget beteende.

Få klienten att avsluta vid TLS-fel

Sätt tls-exit i profilen som klienten faktiskt läser in, eller ge --tls-exit vid start, och kör den en gång i förgrunden. Läs avslutningsstatusen och den sista loggrader, eftersom det är statusen en övervakare agerar på. En avslutning som inte är noll efter ett förhandlingsfel är det avsedda resultatet. Om processen fortsätter att försöka i stället för att sluta, finns inte alternativet i profilen som klienten faktiskt läser in.

Övervakaren avgör om den avslutningen syns. En systemd-enhet med Restart=always eller Restart=on-failure startar klienten igen, så loopen fortsätter och alternativet verkar inte göra något. Kontrollera policyn innan du skyller på klienten:

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

Restart=no låter processen ligga nere, och Restart=on-failure startar ändå om efter en status som inte är noll. Om du vill att felet ska synas men tjänsten återhämta sig från orelaterade krascher, sätt Restart=on-failure och använd StartLimitBurst och StartLimitIntervalSec för att stoppa omstartsstormen. Läs sedan enhetens status för att bekräfta den sista avslutningskoden: systemctl status rapporterar den, och journalen behåller det första felet ovanför omstarterna.

Skriv beslutet i enheten eller i profilanteckningarna. En profil som avslutar vid TLS-fel ser ut som en olycka för nästa person om inte orsaken är antecknad. Ange vilka fel som ska stoppa processen och vilka som ska försökas igen.

Bevisa det med en engångsendpunkt

För att se beteendet innan du litar på det, kopiera profilen och rikta kopian mot en endpunkt som accepterar en TCP-anslutning men aldrig talar OpenVPN. En lyssnare som svarar och sedan tiger räcker. Med tls-exit bör klienten sluta när handskakningen misslyckas; utan det bör samma profil fortsätta snurra. Använd kopian, aldrig arbetsprofilen.

Jämför de två körningarna efter avslutningsstatus och första felrad, inte efter hur länge var och en varade. Statusen säger om alternativet utlöstes, och den första raden säger vilket steg som misslyckades.

Ta bort testprofilen när du är klar. En kopia med en avsiktligt felaktig endpunkt är en fälla för alla som senare startar varje profil i mappen.

Steg som detta alternativ aldrig når

En autentiseringsavvisning är ett senare steg. Om servern utvärderar kontot och avvisar det är TLS redan förhandlat, så tls-exit utlöses inte. Inställningarna för nytt försök vid autentisering är nästa ställe att titta på, och serverns orsak väger tyngre än klientens sista rad. Fel lösenord och saknat certifikat kan ge liknande meddelanden på klientsidan.

En saknad rutt, en felaktig resolver eller en oåtkomlig gateway ligger också utanför alternativet, eftersom de inte är förhandlingsfel. Tyst paketförlust är det minst uppenbara fallet: beroende på hur långt utbytet kom kan klienten rapportera ett förhandlingsfel eller helt enkelt slå i tidsgränsen.

Behåll åtskillnaden i dina anteckningar. Inställningen är för diagnostik och övervakning snarare än reparation, så den åtgärdar inte en cipher-avvikelse, ett certifikatproblem eller en felaktig port. Reparera orsaken till den misslyckade förhandlingen först och avgör sedan om omedelbar avslutning fortfarande passar utrullningen.