Per què el vostre client OpenVPN es queda aturat després d’un sol temps d’espera

Dilluns al matí: el túnel que va pujar divendres ha desaparegut, la interfície encara apareix a la llista i al registre no hi ha res que digui que algú se n’ha adonat. L’amfitrió és en línia, el tauler és verd i tot el que va enviar durant el cap de setmana va sortir per la interfície física. Aquí falten dues decisions independents: una sobre si el procés del client sobreviu a una fallada transitòria i una altra sobre si alguna cosa per sobre seu torna a iniciar el procés després que surti. Arreglar només una de les dues deixa l’altra escletxa oberta.

Comenceu pel que la unitat ha fet realment, no pel que assegura el monitoratge. systemctl status openvpn-client@office i journalctl -u openvpn-client@office -n 50 mostren el motiu de sortida i l’última línia que el client va escriure abans de marxar.

El procés va sortir abans que ningú se n’adonés

Un client que desapareix sense error normalment ha sortit a propòsit. El perfil decideix aquest comportament, no el gestor de serveis: ping-exit acaba el procés tan bon punt l’igual deixa de respondre, mentre que ping-restart manté el procés i es reconnecta dins seu. Els límits de sessió i els temporitzadors d’inactivitat produeixen la mateixa imatge des de fora: sense túnel i sense alarma.

Les dues directrius ping no poden aparèixer juntes en un sol perfil, així que trieu-ne una i anoteu la decisió. Mireu també el servidor, perquè el seu propi ping-exit tanca una sessió sigui què sigui el que va demanar el client, i només el registre del servidor anota qui va prendre aquesta decisió.

Triar entre ping-exit i ping-restart

Trieu ping-restart per a un portàtil o un lloc remot que s’hagi de curar sol, i reserveu ping-exit per als casos en què un túnel mort ha d’aturar el procés perquè una altra cosa hi pugui actuar. Els números importen menys que la relació: ping 10 amb ping-restart 60 significa deu segons de silenci abans d’una sonda i seixanta abans del reinici, cosa agressiva en un enllaç mòbil amb pèrdues i raonable en un de cablejat. Escriviu el motiu al costat de la línia, perquè el lector següent assumirà altrament que els valors per defecte eren deliberats.

Després confirmeu que el que ha sortit és realment el procés. Una unitat que informa d’activitat mentre el túnel és mort és una fallada diferent, tractada més avall.

Supervisió que realment reinicia la unitat

En un amfitrió amb systemd, el canvi durador més petit és un sol fitxer drop-in: Restart=on-failure i RestartSec=10 a /etc/systemd/system/[email protected]/restart.conf. Un drop-in només es llegeix quan systemd recarrega les seves pròpies definicions, així que executeu systemctl daemon-reload després. Verifiqueu amb systemctl show -p Restart -p ExecMainStatus openvpn-client@office en lloc d’assumir que el valor ha arribat. La instància del nom del fitxer ha de ser el perfil que la unitat carrega realment, de manera que un fitxer escrit per a office no fa res per a openvpn-client@home.

on-failure ignora un cas: una sortida neta amb estat zero. Alguns camins de desmuntatge acaben així, així que llegiu l’estat registrat en lloc de confiar en la redacció d’una pàgina de manual. Si el vostre client es rendeix amb un zero, us cal Restart=always, i el cost és que un perfil realment trencat torna una i altra vegada fins que salta el límit de velocitat d’inici i el registre s’omple.

Restart=always també s’activa després d’una aturada deliberada. Feu servir systemctl stop per al manteniment i emmascareu la unitat si ha de quedar aturada mentre treballeu.

Atrapar la fuita mentre el túnel és aturat

La supervisió fa tornar el túnel, però no impedeix que el trànsit surti mentre el túnel no hi és. persist-tun manté el dispositiu i les seves rutes entre reconnexions, cosa convenient que obre una finestra. El dispositiu sobreviu, les rutes encara hi apunten i els paquets surten sense protecció i sense cap avís. És una decisió de política, no un valor per defecte neutre.

Quan un amfitrió no pot emetre mai paquets sense protecció, només el tallafoc ho pot garantir. Una regla de sortida que permet la interfície del túnel i l’adreça del servidor VPN mentre descarta tota la resta continua vigent després que el client mori, i res a la configuració del propi client no pot filtrar el trànsit que el client no porta.

Proveu-ho aturant el client a propòsit. Executeu systemctl stop openvpn-client@office, i després curl -m 5 https://example.com, que hauria de fallar en lloc d’encertar-se per l’enllaç físic. Un èxit significa que la regla del tallafoc falta o és massa permissiva.

Torneu a connectar, confirmeu que el túnel torna a portar trànsit i només llavors afegiu la comprovació al monitoratge. Enquestar ip addr des de cron per a un dispositiu tun és la supervisió que falla més sovint, perquè amb persist-tun el dispositiu sobreviu a la sessió i la sonda informa de salut mentre no es porta res.