OpenVPN reîncearcă după o eroare TLS: cum îl oprești

Clientul se conectează, eșuează în timpul negocierii TLS, așteaptă și încearcă din nou același server cu același rezultat. Sub un supraveghetor care repornește un proces eșuat, acele încercări devin o buclă fără sfârșit în jurnal, iar prima linie de diagnostic iese din raza de acțiune. OpenVPN oferă o opțiune care transformă acel eșec de negociere într-o ieșire vizibilă în loc de încă o încercare. Este o setare de diagnostic și supraveghere, nu o reparație, așa că asociaz-o cu o politică ce lasă într-adevăr procesul oprit.

Ciclul care ascunde prima eroare

Ceea ce vezi este un bloc repetat, nu un singur eșec: o încercare de conectare, o eroare TLS, o pauză și apoi aceeași secvență. Fiecare repetare împinge linia originală mai sus în jurnal. Dacă unitatea se repornește la eșec, ciclul poate continua ore în șir fără ca cineva să citească cauza. Simptomul este bucla, deși defectul de fond este o singură problemă de negociere.

Sesiunile interactive suportă asta pentru că un eșec temporar poate dispărea la următoarea încercare. Conexiunile automatizate nu își pot permite același optimism: procesul trebuie să se oprească pentru ca un om sau un monitor să vadă starea.

Înainte de a schimba ceva, captează un ciclu complet. Notează adresa la distanță, etapa TLS menționată în eroare și dacă procesul iese cu totul.

Mecanismul de reîncercare din spatele buclei

Reîncercarea este implicită pentru că mai multe expirări nelegate partajează același mecanism. connect-retry stabilește intervalul dintre încercările de conectare, connect-retry-max poate limita cât de des este încercată fiecare intrare la distanță, iar resolv-retry guvernează căutările repetate de nume. Un eșec de negociere TLS ajunge la acel mecanism ca eveniment de transport, așa că clientul programează altă încercare în loc să raporteze. Valoarea implicită ajută la o legătură instabilă și dăunează la un defect care nu se poate vindeca.

Opțiunea --tls-exit schimbă doar cazul negocierii. Manualul o descrie ca ieșire la eșecul negocierii TLS, ceea ce este mai îngust decât ieșirea la orice eroare. Expirările, eșecurile resolverului și refuzurile de autentificare își păstrează propriul comportament.

Fă clientul să iasă la eșecul TLS

Pune tls-exit în profilul pe care clientul îl încarcă efectiv, sau transmite --tls-exit la pornire, și rulează-l o dată în prim-plan. Citește starea de ieșire și ultima linie din jurnal, pentru că starea este cea pe care acționează un supraveghetor. O ieșire diferită de zero după un eșec de negociere este rezultatul dorit. Dacă procesul continuă să încerce în loc să se termine, opțiunea nu este în profilul pe care clientul îl încarcă efectiv.

Supraveghetorul decide dacă acea ieșire este vizibilă. O unitate systemd cu Restart=always sau Restart=on-failure pornește din nou clientul, așa că bucla continuă și opțiunea pare să nu facă nimic. Verifică politica înainte de a da vina pe client:

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

Restart=no lasă procesul oprit, iar Restart=on-failure tot repornește după o stare diferită de zero. Dacă vrei ca eșecul să fie vizibil dar serviciul să se refacă după căderi nelegate, setează Restart=on-failure și folosește StartLimitBurst și StartLimitIntervalSec pentru a opri furtuna de reporniri. Apoi citește starea unității pentru a confirma ultimul cod de ieșire: systemctl status îl raportează, iar jurnalul păstrează prima eroare deasupra repornirilor.

Scrie decizia în unitate sau în notițele profilului. Un profil care iese la eșecul TLS pare un accident pentru următoarea persoană dacă motivul nu este consemnat. Precizează ce eșecuri trebuie să oprească procesul și care trebuie reîncercate.

Dovedește-o cu un punct final de unică folosință

Ca să vezi comportamentul înainte de a te baza pe el, copiază profilul și îndreaptă copia spre un punct final care acceptă o conexiune TCP dar nu vorbește niciodată OpenVPN. Este suficient un ascultător care răspunde și apoi tace. Cu tls-exit, clientul ar trebui să se termine când eșuează strângerea de mână; fără ea, același profil ar trebui să continue să se rotească. Folosește copia, niciodată profilul de lucru.

Compară cele două rulări după starea de ieșire și după prima linie de eroare, nu după cât a durat fiecare. Starea spune dacă opțiunea s-a declanșat, iar prima linie spune care etapă a eșuat.

Elimină profilul de test când ai terminat. O copie cu un punct final intenționat greșit este o capcană pentru oricine pornește ulterior fiecare profil din director.

Etape la care această opțiune nu ajunge niciodată

Un refuz de autentificare este o etapă ulterioară. Dacă serverul evaluează contul și îl refuză, TLS a fost deja negociat, așa că tls-exit nu se declanșează. Setările de reîncercare a autentificării sunt următorul loc de verificat, iar motivul serverului contează mai mult decât ultima linie a clientului. O parolă greșită și un certificat lipsă pot produce mesaje similare pe partea clientului.

O rută lipsă, un resolver greșit sau o poartă de acces inaccesibilă sunt și ele în afara opțiunii, pentru că nu sunt eșecuri de negociere. Pierderea silențioasă de pachete este cazul cel mai puțin evident: în funcție de cât de departe a ajuns schimbul, clientul poate raporta un eșec de negociere sau pur și simplu poate expira.

Păstrează distincția în notițe. Setarea este pentru diagnostic și supraveghere, nu pentru reparație, așa că nu repară o nepotrivire de cifru, o problemă de certificat sau un port greșit. Repară mai întâi cauza negocierii eșuate, apoi decide dacă ieșirea imediată se mai potrivește implementării.