OpenVPN continua reintentant després d’una error TLS: com aturar-ho

El client es connecta, falla durant la negociació TLS, espera i torna a provar el mateix servidor amb el mateix resultat. Sota un supervisor que reinicia un procés fallit, aquests intents es converteixen en un bucle sense fi al registre, i la primera línia de diagnòstic surt de l’abast. OpenVPN inclou una opció que converteix aquesta fallada de negociació en una sortida visible en lloc d’un altre reintent. És un paràmetre de diagnòstic i supervisió, no una reparació, així que combineu-lo amb una política que permeti de debò que el procés quedi aturat.

El cicle que amaga el primer error

El que veieu és un bloc repetitiu i no una fallada: un intent de connexió, un error TLS, una pausa i després la mateixa seqüència. Cada repetició empeny la línia original més amunt del registre. Si la unitat es reinicia en fallar, el cicle pot continuar durant hores sense que ningú llegeixi la causa. El símptoma és el bucle, encara que la fallada subjacent sigui un sol problema de negociació.

Les sessions interactives ho toleren perquè una fallada transitòria pot desaparèixer en el següent intent. Les connexions automatitzades no es poden permetre el mateix optimisme: el procés s’ha d’aturar perquè una persona o un monitor pugui veure l’estat.

Abans de canviar res, captureu un cicle complet. Anoteu l’adreça remota, l’etapa TLS indicada a l’error i si el procés arriba a sortir.

La maquinària de reintents darrere del bucle

El reintent és el comportament per defecte perquè diversos temps d’espera no relacionats comparteixen la mateixa maquinària. connect-retry fixa l’interval entre intents de connexió, connect-retry-max pot limitar quantes vegades es prova cada entrada remota, i resolv-retry governa les cerques repetides de noms. Una fallada de negociació TLS arriba a aquesta maquinària com un esdeveniment de transport, així que el client programa un altre intent en lloc d’informar. El valor per defecte ajuda en un enllaç inestable i perjudica en una fallada que no pot curar-se.

L’opció --tls-exit només canvia el cas de negociació. El manual la descriu com sortir quan falla la negociació TLS, cosa més estreta que sortir amb qualsevol error. Els temps d’espera, les fallades del resolutor i els rebuigs d’autenticació conserven el seu comportament.

Fer que el client surti en fallar TLS

Poseu tls-exit al perfil que el client carrega realment, o passeu --tls-exit en iniciar-lo, i executeu-lo una vegada en primer pla. Llegiu l’estat de sortida i també l’última línia del registre, perquè és l’estat el que fa actuar un supervisor. Una sortida diferent de zero després d’una fallada de negociació és el resultat previst. Si el procés continua reintentant en lloc d’acabar, l’opció no és al perfil que el client carrega realment.

El supervisor decideix si aquesta sortida és visible. Una unitat systemd amb Restart=always o Restart=on-failure torna a iniciar el client, així que el bucle continua i l’opció sembla no fer res. Reviseu la política abans de culpar el client:

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

Restart=no permet que el procés quedi aturat, i Restart=on-failure encara reinicia després d’un estat diferent de zero. Si voleu que la fallada sigui visible però que el servei es recuperi de caigudes no relacionades, definiu Restart=on-failure i utilitzeu StartLimitBurst i StartLimitIntervalSec per aturar la tempesta de reinicis. Després llegiu l’estat de la unitat per confirmar l’últim codi de sortida: systemctl status l’informa, i el registre conserva el primer error per sobre dels reinicis.

Escriviu la decisió a la unitat o a les notes del perfil. Un perfil que surt en fallar TLS sembla un accident per a la següent persona tret que el motiu quedi registrat. Indiqueu quines fallades han d’aturar el procés i quines s’han de reintentar.

Provar-ho amb un punt final d’un sol ús

Per veure el comportament abans de confiar-hi, copieu el perfil i apunteu la còpia a un punt final que accepta una connexió TCP però mai no parla OpenVPN. N’hi ha prou amb un oient que respongui i després calli. Amb tls-exit, el client hauria d’acabar quan falla l’apretada de mans; sense l’opció, el mateix perfil hauria de continuar fent cicles. Feu servir la còpia, mai el perfil de treball.

Compareu les dues execucions per l’estat de sortida i per la primera línia d’error, no per quant va durar cadascuna. L’estat us diu si l’opció s’ha activat, i la primera línia us diu quina etapa ha fallat.

Traieu el perfil de prova quan hàgiu acabat. Una còpia amb un punt final deliberadament equivocat és un parany per a qui després iniciï tots els perfils del directori.

Etapes a què aquesta opció no arriba mai

Un rebuig d’autenticació és una etapa posterior. Si el servidor avalua el compte i el rebutja, la TLS ja s’ha negociat, així que tls-exit no s’activa. Els paràmetres de reintent d’autenticació són el següent lloc on mirar, i el motiu del servidor importa més que l’última línia del client. Una contrasenya incorrecta i un certificat absent poden produir missatges semblants al costat del client.

Una ruta absent, un resolutor equivocat o una passarel·la inabastable també queden fora de l’opció, perquè no són fallades de negociació. La pèrdua silenciosa de paquets és el cas menys evident: segons com d’avançada estigui l’intercanvi, el client pot informar d’una fallada de negociació o simplement esgotar el temps.

Manteniu la distinció a les notes. El paràmetre és per a diagnòstic i supervisió, no per a reparació, així que no arregla una discrepància de xifratge, un problema de certificat ni un port equivocat. Repareu primer la causa de la negociació fallida i després decidiu si sortir immediatament encara convé al desplegament.