Probar la recuperación del servidor VPN tras un reinicio: qué comprobar primero

Reinicia el servidor sin que nadie haya iniciado sesión y luego conéctate desde una red que no controles. Esa única prueba responde si la recuperación es real, porque un túnel que solo funciona después de que alguien ejecute un comando a mano no es recuperación, es una reparación. La mayoría de las comprobaciones se detienen demasiado pronto: el demonio se muestra activo, la interfaz aparece y la página aún no carga. El hueco casi siempre está en la persistencia de las piezas que rodean el túnel, no en el propio comando del túnel.

Cuatro propietarios, cuatro pruebas distintas

Antes del reinicio, nombra qué se supone que debe devolver el túnel. La prueba que ejecutas y la corrección que aplicas dependen ambas de esa respuesta, y hay cuatro propietarios habituales: una unidad de systemd para el demonio VPN, una unidad de instancia wg-quick para una interfaz WireGuard, un runtime de contenedores o un perfil de gestor de red. Si no puedes nombrar al propietario, detente y encuéntralo, porque una prueba de reinicio sin una ruta de arranque esperada solo te dice que pasó algo.

Cada propietario guarda su configuración en un lugar distinto. Un servidor OpenVPN gestionado por systemd lee su configuración al arrancar, así que lo que haya en el archivo en el momento del arranque es lo que se ejecuta. Una interfaz wg-quick obtiene sus direcciones, rutas y DNS del mismo archivo, lo que significa que una interfaz levantada a mano desde una shell y nunca habilitada como unidad no volverá. Un contenedor recupera su punto de entrada, pero no los cambios del cortafuegos del host, salvo que estos vivan fuera del contenedor.

Primero la línea base, o el resultado no significa nada

Captura el estado de funcionamiento mientras funciona: direcciones en el túnel, rutas para la subred de clientes, reglas NAT o de reenvío, el socket de escucha y el sysctl de reenvío. ip addr show wg0, ip route, nft list ruleset o iptables-save, ss -lunp y sysctl net.ipv4.ip_forward bastan en la mayoría de los hosts.

Anota cómo está configurado el servicio para arrancar, no solo que se esté ejecutando. systemctl is-enabled wg-quick@wg0 y systemctl is-active wg-quick@wg0 responden a preguntas distintas, y el estado habilitado es el que importa en el arranque, como se describe en systemctl(1). Para OpenVPN, comprueba qué plantilla usa el host, ya que openvpn@server y openvpn-server@server son unidades distintas con valores predeterminados distintos.

Ejecuta el reinicio y lee el primer fallo

Reinicia a propósito, durante una ventana que hayas elegido, con una consola o una ruta fuera de banda abierta. Observa el orden de los eventos en lugar del estado final: host accesible, unidad activada, interfaz presente, rutas instaladas, reglas de cortafuegos presentes, escucha vinculada, cliente aceptado. El primer paso que no ocurre es el hallazgo; todo lo que viene después es ruido.

Un demonio puede estar activo mientras el túnel es inutilizable, y ese es el falso aprobado más común. El arranque puede completarse antes de que la red esté en línea si la unidad solo espera network.target en lugar de network-online.target. Los archivos referenciados, como certificados, claves o una CRL, pueden ser ilegibles en ese momento porque un montaje o una ruta de secretos aún no está listo. Ninguno de los dos problemas aparece en systemctl status hasta que lees el registro de la unidad.

Prueba desde fuera del host. Un cliente en la misma LAN puede tener éxito por una ruta que ningún cliente remoto usaría jamás, y una sesión SSH a la máquina no demuestra nada sobre el túnel. Conéctate, resuelve un nombre interno, llega al recurso privado y luego vuelve a conectarte una vez para confirmar que el estado de revocación y las claves siguen aplicándose.

Las tres condiciones que deciden tu corrección

Si el túnel vuelve pero los clientes no llegan a nada, el fallo está en el enrutamiento o en la persistencia del NAT. Si los clientes ni siquiera pueden completar un handshake, el fallo está en la interfaz o en el material de autenticación. Si el servicio nunca arranca, el fallo está en el archivo de unidad o en sus dependencias. Esas tres ramas llevan a correcciones distintas, y por eso un reinicio a ciegas sin línea base cuesta más tiempo del que ahorra.

Haz la corrección donde se posee la configuración. Pon el reenvío en un drop-in de sysctl, pon las reglas NAT en el conjunto de reglas que se carga al arrancar, habilita la unidad en lugar de iniciarla, y guarda los secretos en una ruta que exista antes de que la unidad arranque. Añadir una espera a la unidad oculta una dependencia en lugar de declararla.

Anota el resultado en el runbook

Escribe qué volvió por sí solo, qué tuviste que iniciar y cuánto duró el hueco. Incluye los comandos exactos que usaste para verificar, para que la siguiente persona repita la prueba en lugar de inventar una. Si algún paso necesitó un comando manual, ese comando pertenece a la configuración, no al runbook como paso permanente.

Después programa la siguiente prueba para después del siguiente cambio en la pila de red del host, no para una fecha de calendario dentro de seis meses. El modo de fallo contra el que te proteges es un comando temporal que parecía permanente, y esos aparecen justo cuando alguien edita reglas de cortafuegos o mueve un servicio a una unidad nueva.