OpenVPN hou aan herprobeer ná ’n TLS-fout: hoe om dit te stop

Die kliënt maak verbinding, misluk tydens TLS-onderhandeling, wag en probeer dan dieselfde bediener weer met dieselfde resultaat. Onder ’n toesighouer wat ’n mislukte proses herbegin, word daardie pogings ’n eindelose lus in die joernaal, en die eerste diagnostiese reël verdwyn buite bereik. OpenVPN lewer ’n opsie wat daardie onderhandelingsmislukking in ’n sigbare uitgang verander eerder as nog ’n herpoging. Dit is ’n diagnostiese en toesighoudingsinstelling, nie ’n herstel nie, so pas dit saam met ’n beleid wat die proses werklik laat afbly.

Die siklus wat die eerste fout wegsteek

Wat jy sien, is ’n herhalende blok eerder as een fout: ’n verbindingspoging, ’n TLS-fout, ’n pouse en dan dieselfde reeks. Elke herhaling skuif die oorspronklike reël verder op in die joernaal. As die eenheid met herbegin-op-mislukking werk, kan die siklus ure lank aanhou sonder dat iemand die oorsaak lees. Die simptoom is die lus, al is die onderliggende fout ’n enkele onderhandelingsprobleem.

Interaktiewe sessies verdra dit omdat ’n kortstondige fout met die volgende poging kan opklaar. Outomatiese verbindings kan nie dieselfde optimisme bekostig nie: die proses moet stop sodat ’n mens of ’n monitor die status kan sien.

Voordat jy iets verander, teken een volledige siklus op. Let op die afgeleë adres, die TLS-stadium wat in die fout genoem word en of die proses hoegenaamd uitgaan.

Die herpogingsmasjinerie agter die lus

Herprobeer is die verstek omdat verskeie onverwante timeouts dieselfde masjinerie deel. connect-retry stel die gaping tussen verbindingspogings, connect-retry-max kan beperk hoe dikwels elke afgeleë inskrywing probeer word, en resolv-retry beheer herhaalde naamsoektogte. ’n TLS-onderhandelingsmislukking bereik daardie masjinerie as ’n vervoergebeurtenis, so die kliënt beplan nog ’n poging in plaas daarvan om te rapporteer. Die verstek is nuttig vir ’n wankelrige skakel en skadelik vir ’n fout wat nie kan genees nie.

Die opsie --tls-exit verander net die onderhandelingsgeval. Die handleiding beskryf dit as om by TLS-onderhandelingsmislukking uit te gaan, wat smaller is as om by elke fout uit te gaan. Timeouts, oplosserfoute en verwerping van verifikasie behou hul eie gedrag.

Laat die kliënt by ’n TLS-mislukking uitgaan

Plaas tls-exit in die profiel wat die kliënt werklik laai, of gee --tls-exit wanneer jy dit begin, en voer dit een keer in die voorgrond uit. Lees die uitgangstatus sowel as die laaste joernaalreël, want die status is waarop ’n toesighouer reageer. ’n Nie-nul-uitgang ná ’n onderhandelingsmislukking is die bedoelde resultaat. As die proses aanhou herprobeer in plaas daarvan om te eindig, is die opsie nie in die profiel wat die kliënt werklik laai nie.

Die toesighouer besluit of daardie uitgang sigbaar is. ’n systemd-eenheid met Restart=always of Restart=on-failure begin die kliënt weer, so die lus hou aan en die opsie lyk of dit niks doen. Kontroleer die beleid voordat jy die kliënt blameer:

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

Restart=no laat die proses af bly, en Restart=on-failure herbegin steeds ná ’n nie-nul-status. As jy wil hê die mislukking moet sigbaar wees maar die diens moet van onverwante ineenstortings herstel, stel Restart=on-failure en gebruik StartLimitBurst en StartLimitIntervalSec om die herbegin-storm te stop. Lees dan die eenheid se status om die laaste uitgangkode te bevestig: systemctl status rapporteer dit, en die joernaal hou die eerste fout bo die herbeginne.

Skryf die besluit in die eenheid of in die profielnotas. ’n Profiel wat by ’n TLS-mislukking uitgaan, lyk vir die volgende persoon soos ’n ongeluk tensy die rede opgeteken is. Meld watter mislukkings die proses moet stop en watter herprobeer moet word.

Bewys dit met ’n weggooi-eindpunt

Om die gedrag te sien voordat jy dit vertrou, kopieer die profiel en wys die kopie na ’n eindpunt wat ’n TCP-verbinding aanvaar maar nooit OpenVPN praat nie. ’n Luisteraar wat antwoord en dan stilbly, is genoeg. Met tls-exit moet die kliënt eindig wanneer die handdruk misluk; daarsonder moet dieselfde profiel aanhou siklus. Gebruik die kopie, nooit die werkende profiel nie.

Vergelyk die twee lopies volgens uitgangstatus en die eerste foutreël, nie volgens hoe lank elkeen geduur het nie. Die status sê vir jou of die opsie gevuur het, en die eerste reël sê vir jou watter stadium misluk het.

Verwyder die toetsprofiel wanneer jy klaar is. ’n Kopie met ’n doelbewus verkeerde eindpunt is ’n lokval vir enigiemand wat later elke profiel in die gids begin.

Stadiums wat hierdie opsie nooit bereik nie

’n Verwerping van verifikasie is ’n later stadium. As die bediener die rekening evalueer en dit weier, is TLS reeds onderhandel, so tls-exit vuur nie. Die herpogingsinstellings vir verifikasie is die volgende plek om te kyk, en die bediener se rede is belangriker as die kliënt se laaste reël. ’n Verkeerde wagwoord en ’n ontbrekende sertifikaat kan soortgelyke boodskappe aan die kliëntkant lewer.

’n Ontbrekende roete, ’n verkeerde oplosser of ’n onbereikbare poort is ook buite die opsie, want dit is nie onderhandelingsmislukkings nie. Stille pakkieverlies is die minste duidelike geval: afhangend van hoe ver die uitruiling gevorder het, kan die kliënt ’n onderhandelingsmislukking rapporteer of bloot uitty.

Hou die onderskeid in jou notas. Die instelling is vir diagnose en toesig eerder as herstel, so dit maak nie ’n cipher-wanpassing, ’n sertifikaatprobleem of ’n verkeerde poort reg nie. Herstel eers die oorsaak van die mislukte onderhandeling en besluit dan of onmiddellik uitgaan steeds by die ontplooiing pas.