OpenVPN bliuwt opnij besykjen nei in TLS-flater: hoe’t jo it stopje

De klant ferbynt, mislearret by de TLS-ûnderhanneling, wachtet en besiket deselde server opnij mei deselde útslach. Under in tafersjochhâlder dy’t in mislearre proses opnij start, wurde dy pogingen in einleaze lus yn it sjoernaal, en de earste diagnostyske rigel rekket bûten berik. OpenVPN leveret in opsje dy’t dy ûnderhannelingsflater yn in sichtbere ôfsluting feroaret ynstee fan noch in poging. It is in ynstelling foar diagnostyk en tafersjoch, net in reparaasje, dus kombinearje it mei in belied dat it proses wier dellizze lit.

De syklus dy’t de earste flater ferberget

Wat jo sjogge is in werheljend blok en net ien flater: in ferbiningspoging, in TLS-flater, in skoft en dan deselde folchoarder. Eltse werhelling skoot de oarspronklike rigel heger yn it sjoernaal. As de ienheid by mislearring opnij start, kin de syklus oeren trochgean sûnder dat immen de oarsaak lêst. It symptoom is de lus, ek al is de ûnderlizzende brek ien inkeld ûnderhannelingsprobleem.

Ynteraktive sesjes ferneare dit om’t in tydlike flater by de folgjende poging ferdwine kin. Automatyske ferbiningen kinne itselde optimisme net bekostje: it proses moat stopje sadat in minske as in monitor de status sjen kin.

Foardat jo wat feroarje, fêstigje ien folsleine syklus. Notearje it fiere adres, de TLS-etappe dy’t yn ’e flater neamd wurdt en oft it proses uberhaad ôfslút.

It opnij-besykje-meganisme efter de lus

Opnij besykjen is de standert om’t ferskate net besibbe timeouts itselde meganisme diele. connect-retry stelt de tuskenromte tusken ferbiningspogingen, connect-retry-max kin beheine hoe faak elke fiere ynfier besocht wurdt, en resolv-retry regelet werhelle nammesykjen. In TLS-ûnderhannelingsflater berikt dat meganisme as in ferfiersbar-gedrach, dus de klant plendet noch in poging ynstee fan te rapportearjen. De standert helpt by in wifkige ferbining en docht skea by in brek dy’t net genêze kin.

De opsje --tls-exit feroaret allinnich it ûnderhannelingsgefal. De hânlieding beskriuwt it as ôfslute by in TLS-ûnderhannelingsflater, wat smeller is as ôfslute by elke flater. Timeouts, resolverflaters en ôfwizingen fan autentikaasje hâlde har eigen gedrach.

Lit de klant ôfslute by in TLS-flater

Set tls-exit yn it profyl dat de klant wier ladt, of jou --tls-exit by it starten, en rinn it ien kear op ’e foargrûn. Lês de ôfslutingsstatus en ek de lêste rigel fan it sjoernaal, want de status is wêrop in tafersjochhâlder reagearret. In net-nul ôfsluting nei in ûnderhannelingsflater is it bedoelde resultaat. As it proses opnij besykjen bliuwt ynstee fan te einigjen, sit de opsje net yn it profyl dat de klant wier ladt.

De tafersjochhâlder beslút oft dy ôfsluting sichtber is. In systemd-ienheid mei Restart=always of Restart=on-failure start de klant opnij, dus de lus giet troch en de opsje liket neat te dwaan. Kontrolearje it belied foardat jo de klant de skuld jouwe:

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

Restart=no lit it proses del lizze, en Restart=on-failure start noch altyd opnij nei in net-nul status. As jo wolle dat de flater sichtber is mar de tsjinst him fan net besibbe crashes werstelt, set Restart=on-failure en brûk StartLimitBurst en StartLimitIntervalSec om de werstartstoarm te stopjen. Lês dan de status fan ’e ienheid om de lêste ôfslutingskoade te befêstigjen: systemctl status rapportearret dy, en it sjoernaal hâldt de earste flater boppe de werstarts.

Skriuw it beslút yn ’e ienheid of yn ’e profylnotysjes. In profyl dat by in TLS-flater ôfslút liket foar de folgjende persoan op in ûngelok, útsein as de reden fêstlein is. Jou oan hokker flaters it proses stopje moatte en hokker opnij besocht wurde moatte.

Bewiis it mei in weismyt-einpunt

Om it gedrach te sjen foardat jo it fertrouwe, kopiearje it profyl en rjochtsje de kopy op in einpunt dat in TCP-ferbining akseptearret mar nea OpenVPN praat. In harker dy’t antwurdet en dan stil bliuwt, is genôch. Mei tls-exit moat de klant einigje as de hânskuddfaasje mislearret; sûnder dy moat itselde profyl trochgean mei syklen. Brûk de kopy, nea it wurkjende profyl.

Fergelykje de twa runs op ôfslutingsstatus en op ’e earste flaterrigel, net op hoe lang elk duorre. De status fertelt oft de opsje ôfgie, en de earste rigel fertelt hokker etappe mislearre.

Ferwiderje it testprofyl as jo klear binne. In kopy mei in mei sin ferkeard einpunt is in falstrik foar elkenien dy’t letter elk profyl yn ’e map start.

Etappes dy’t dizze opsje nea berikt

In ôfwizing fan autentikaasje is in lettere etappe. As de server it akkount beoardielet en it wegeret, is TLS al ûnderhannele, dus tls-exit giet net ôf. De opnij-besykje-ynstellingen foar autentikaasje binne it folgjende plak om te sjen, en de reden fan ’e server jildt mear as de lêste rigel fan ’e klant. In ferkeard wachtwurd en in ûntbrekkend sertifikaat kinne oan ’e klantkant ferlykbere berjochten jaan.

In ûntbrekkende rûte, in ferkearde resolver of in ûnberikbere gateway binne ek bûten de opsje, want it binne gjin ûnderhannelingsflaters. Stille pakketferlies is it minst dúdlike gefal: ôfhinklik fan hoe fier de útwikseling kaam, kin de klant in ûnderhannelingsflater rapportearje of gewoan in timeout krije.

Hâld it ûnderskie yn jo notysjes. De ynstelling is foar diagnostyk en tafersjoch ynstee fan reparaasje, dus it reparearret in cipher-ôfwiking, in sertifikaatprobleem of in ferkearde poarte net. Reparearje earst de oarsaak fan ’e mislearre ûnderhanneling en beslút dan oft fuort ôfslute noch by de útrulling past.