OpenVPN blijft opnieuw proberen na een TLS-fout: zo stop je het

De client maakt verbinding, mislukt tijdens de TLS-onderhandeling, wacht en probeert dezelfde server opnieuw met hetzelfde resultaat. Onder een supervisor die een mislukt proces herstart, worden die pogingen een eindeloze lus in het journaal, en de eerste diagnostische regel raakt buiten bereik. OpenVPN heeft een optie die die onderhandelingsfout omzet in een zichtbare afsluiting in plaats van nog een poging. Het is een instelling voor diagnostiek en toezicht, geen reparatie, dus combineer hem met een beleid dat het proces echt laat stoppen.

De cyclus die de eerste fout verbergt

Wat je ziet is een herhalend blok en niet één storing: een verbindingspoging, een TLS-fout, een pauze en dan dezelfde reeks. Elke herhaling duwt de oorspronkelijke regel verder omhoog in het journaal. Als de unit bij een fout herstart, kan de cyclus uren doorgaan zonder dat iemand de oorzaak leest. Het symptoom is de lus, ook al is het onderliggende defect één onderhandelingsprobleem.

Interactieve sessies verdragen dit omdat een tijdelijke fout bij de volgende poging kan verdwijnen. Geautomatiseerde verbindingen kunnen zich dat optimisme niet veroorloven: het proces moet stoppen zodat een mens of een monitor de status ziet.

Voordat je iets verandert, leg je één volledige cyclus vast. Noteer het externe adres, de TLS-fase die in de fout wordt genoemd en of het proces überhaupt afsluit.

De herhaalmechaniek achter de lus

Opnieuw proberen is de standaard omdat verschillende ongerelateerde time-outs dezelfde mechaniek delen. connect-retry stelt de tussenruimte tussen verbindingspogingen in, connect-retry-max kan beperken hoe vaak elke externe vermelding wordt geprobeerd, en resolv-retry regelt herhaalde naamopzoekingen. Een TLS-onderhandelingsfout bereikt die mechaniek als een transportgebeurtenis, dus de client plant een nieuwe poging in plaats van te rapporteren. De standaard helpt bij een instabiele verbinding en schaadt bij een defect dat niet kan genezen.

De optie --tls-exit verandert alleen het onderhandelingsgeval. De handleiding beschrijft het als stoppen bij een mislukte TLS-onderhandeling, wat smaller is dan stoppen bij elke fout. Time-outs, resolverfouten en authenticatieweigeringen behouden hun eigen gedrag.

De client laten stoppen bij een TLS-fout

Zet tls-exit in het profiel dat de client daadwerkelijk laadt, of geef --tls-exit mee bij het starten, en voer het één keer op de voorgrond uit. Lees de exitstatus en de laatste logregel, want de status is waar een supervisor op reageert. Een exit ongelijk aan nul na een onderhandelingsfout is het bedoelde resultaat. Als het proces blijft proberen in plaats van te eindigen, staat de optie niet in het profiel dat de client daadwerkelijk laadt.

De supervisor beslist of die exit zichtbaar is. Een systemd-unit met Restart=always of Restart=on-failure start de client opnieuw, dus de lus gaat door en de optie lijkt niets te doen. Controleer het beleid voordat je de client de schuld geeft:

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

Restart=no laat het proces gestopt blijven, en Restart=on-failure herstart nog steeds na een status ongelijk aan nul. Als je wilt dat de fout zichtbaar is maar de dienst herstelt van ongerelateerde crashes, stel je Restart=on-failure in en gebruik je StartLimitBurst en StartLimitIntervalSec om de herstartstorm te stoppen. Lees daarna de status van de unit om de laatste exitcode te bevestigen: systemctl status rapporteert die, en het journaal bewaart de eerste fout boven de herstarts.

Schrijf de beslissing in de unit of in de profielnotities. Een profiel dat stopt bij een TLS-fout lijkt voor de volgende persoon een ongeluk, tenzij de reden is vastgelegd. Geef aan welke fouten het proces moeten stoppen en welke opnieuw moeten worden geprobeerd.

Bewijs het met een wegwerp-eindpunt

Om het gedrag te zien voordat je erop vertrouwt, kopieer je het profiel en wijs je de kopie naar een eindpunt dat een TCP-verbinding accepteert maar nooit OpenVPN spreekt. Een luisteraar die antwoordt en daarna zwijgt, is genoeg. Met tls-exit zou de client moeten eindigen wanneer de handshake mislukt; zonder de optie zou hetzelfde profiel moeten blijven ronddraaien. Gebruik de kopie, nooit het werkende profiel.

Vergelijk de twee runs op exitstatus en op de eerste foutregel, niet op hoe lang elk duurde. De status zegt of de optie afging, en de eerste regel zegt welke fase faalde.

Verwijder het testprofiel als je klaar bent. Een kopie met een bewust verkeerd eindpunt is een val voor iedereen die later elk profiel in de map start.

Fases die deze optie nooit bereikt

Een authenticatieweigering is een latere fase. Als de server het account beoordeelt en weigert, is TLS al onderhandeld, dus tls-exit gaat niet af. De herhaalinstellingen voor authenticatie zijn de volgende plek om te kijken, en de reden van de server weegt zwaarder dan de laatste regel van de client. Een verkeerd wachtwoord en een ontbrekend certificaat kunnen aan de clientkant vergelijkbare meldingen geven.

Een ontbrekende route, een verkeerde resolver of een onbereikbare gateway vallen ook buiten de optie, omdat het geen onderhandelingsfouten zijn. Stil pakketverlies is het minst duidelijke geval: afhankelijk van hoe ver de uitwisseling kwam, kan de client een onderhandelingsfout melden of gewoon in een time-out lopen.

Houd het onderscheid in je notities. De instelling is voor diagnostiek en toezicht in plaats van reparatie, dus hij verhelpt een cipher-afwijking, een certificaatprobleem of een verkeerde poort niet. Repareer eerst de oorzaak van de mislukte onderhandeling en beslis dan of onmiddellijk stoppen nog bij de uitrol past.