Por que o seu cliente OpenVPN queda abaixo tras un só tempo de espera

Luns pola mañá: o túnel que subiu o venres desapareceu, a interface segue na lista e nada no rexistro di que alguén o notase. O host está en liña, o panel está verde e todo o que enviou durante a fin de semana saíu pola interface física. Aquí faltan dúas decisións independentes: unha sobre se o proceso do cliente sobrevive a un fallo transitorio e outra sobre se algo por riba del reinicia o proceso tras a súa saída. Arranxar só unha deixa a outra fenda aberta.

Comece polo que a unidade fixo realmente, non polo que afirma a monitorización. systemctl status openvpn-client@office e journalctl -u openvpn-client@office -n 50 mostran o motivo da saída e a última liña que o cliente escribiu antes de marchar.

O proceso saíu antes de que ninguén o notase

Un cliente que desaparece sen erro normalmente saíu a propósito. O perfil decide ese comportamento, non o xestor de servizos: ping-exit remata o proceso en canto o par deixa de responder, mentres que ping-restart mantén o proceso e reconecta dentro del. Os límites de sesión e os temporizadores de inactividade producen a mesma imaxe desde fóra: sen túnel e sen alarma.

As dúas directivas ping non poden aparecer xuntas nun só perfil, así que escolla unha e anote a decisión. Mire tamén o servidor, porque o seu propio ping-exit pecha unha sesión pida o que pida o cliente, e só o rexistro do servidor anota quen tomou esa decisión.

Escoller entre ping-exit e ping-restart

Escolla ping-restart para un portátil ou un sitio remoto que deba curarse só, e reserve ping-exit para os casos en que un túnel morto deba deter o proceso para que outra cousa poida actuar sobre el. Os números importan menos que a relación: ping 10 con ping-restart 60 significa dez segundos de silencio antes dunha sonda e sesenta antes do reinicio, o que é agresivo nunha ligazón móbil con perdas e razoable nunha cableada. Escriba o motivo xunto á liña, porque doutro xeito o seguinte lector asumirá que os valores por defecto foron deliberados.

Despois confirme que o que saíu é realmente o proceso. Unha unidade que informa de actividade mentres o túnel está morto é un fallo distinto, tratado máis abaixo.

Supervisión que realmente reinicia a unidade

Nun host con systemd, o cambio duradeiro máis pequeno é un só ficheiro drop-in: Restart=on-failure e RestartSec=10 en /etc/systemd/system/[email protected]/restart.conf. Un drop-in só se le cando systemd recarga as súas propias definicións, así que execute systemctl daemon-reload despois. Verifique con systemctl show -p Restart -p ExecMainStatus openvpn-client@office en lugar de supor que o valor chegou. A instancia do nome do ficheiro debe ser o perfil que a unidade carga realmente, de modo que un ficheiro escrito para office non fai nada por openvpn-client@home.

on-failure ignora un caso: unha saída limpa con estado cero. Algunhas rutas de desmontaxe acaban así, polo que cómpre ler o estado rexistrado en lugar de confiar na redacción dunha páxina de manual. Se o seu cliente se rende cun cero, necesita Restart=always, e o custo é que un perfil realmente roto volve unha e outra vez ata que salta o límite de velocidade de inicio e o rexistro se enche.

Restart=always tamén se activa tras unha parada deliberada. Use systemctl stop para mantemento, e enmascare a unidade se debe permanecer abaixo mentres traballa.

Atrapar a fuga mentres o túnel está abaixo

A supervisión fai volver o túnel; non impide que o tráfico saia mentres o túnel non está. persist-tun mantén o dispositivo e as súas rutas entre reconexións, o que é cómodo e abre unha xanela. O dispositivo sobrevive, as rutas seguen apuntando a el e os paquetes saen sen protección e sen aviso. É unha decisión de política, non un valor por defecto neutro.

Cando un host non pode emitir ningún paquete sen protección, só o cortafogos pode garantilo. Unha regra de saída que permite a interface do túnel e o enderezo do servidor VPN mentres descarta todo o demais segue vixente despois de que o cliente morra, e nada na configuración do propio cliente pode filtrar o tráfico que o cliente non transporta.

Próbeo detendo o cliente a propósito. Execute systemctl stop openvpn-client@office, logo curl -m 5 https://example.com, que debería fallar en lugar de funcionar pola ligazón física. Un éxito significa que a regra do cortafogos falta ou é demasiado permisiva.

Reconecte, confirme que o túnel volve transportar tráfico e só entón engada a comprobación á monitorización. Sondar ip addr desde cron para un dispositivo tun é a supervisión que falla con máis frecuencia, porque con persist-tun o dispositivo sobrevive á sesión e a sonda informa de saúde mentres non se transporta nada.