Probar a recuperación do servidor VPN tras un reinicio: que comprobar primeiro

Reinicia o servidor sen que ninguén teña iniciado sesión e despois conéctate desde unha rede que non controlas. Esa única proba responde se a recuperación é real, porque un túnel que só funciona despois de que alguén execute un comando a man non é recuperación, é unha reparación. A maioría das comprobacións detéñense demasiado pronto: o demonio amósase activo, a interface aparece e a páxina aínda non carga. O oco está case sempre na persistencia das pezas arredor do túnel, non no propio comando do túnel.

Catro propietarios, catro probas distintas

Antes do reinicio, nomea que se supón que debe devolver o túnel. A proba que executas e a corrección que aplicas dependen ambas desa resposta, e hai catro propietarios habituais: unha unidade de systemd para o demonio VPN, unha unidade de instancia wg-quick para unha interface WireGuard, un runtime de contedores ou un perfil de xestor de rede. Se non podes nomear o propietario, detente e atópao, porque unha proba de reinicio sen unha ruta de arranque esperada só che di que pasou algo.

Cada propietario garda a súa configuración nun lugar distinto. Un servidor OpenVPN xestionado por systemd le a súa configuración ao arrincar, así que o que haxa no ficheiro no momento do arranque é o que se executa. Unha interface wg-quick obtén os seus enderezos, rutas e DNS do mesmo ficheiro, o que significa que unha interface levantada a man desde unha shell e nunca habilitada como unidade non volverá. Un contedor recupera o seu punto de entrada, pero non os cambios de devasas do host, agás que estes vivan fóra do contedor.

Primeiro a liña base, ou o resultado non significa nada

Captura o estado de funcionamento mentres funciona: enderezos no túnel, rutas para a subrede de clientes, regras NAT ou de reenvío, o socket de escoita e o sysctl de reenvío. ip addr show wg0, ip route, nft list ruleset ou iptables-save, ss -lunp e sysctl net.ipv4.ip_forward abondan na maioría dos hosts.

Anota como está configurado o servizo para arrincar, non só que se estea executando. systemctl is-enabled wg-quick@wg0 e systemctl is-active wg-quick@wg0 responden a preguntas distintas, e o estado habilitado é o que importa no arranque, como se describe en systemctl(1). Para OpenVPN, comproba que modelo usa o host, xa que openvpn@server e openvpn-server@server son unidades distintas con valores predeterminados distintos.

Executa o reinicio e le o primeiro fallo

Reinicia a propósito, durante unha xanela que escollas, cunha consola ou unha ruta fóra de banda aberta. Observa a orde dos acontecementos en lugar do estado final: host accesible, unidade activada, interface presente, rutas instaladas, regras de devasas presentes, escoita ligada, cliente aceptado. O primeiro paso que non ocorre é o achado; todo o que vén despois é ruído.

Un demonio pode estar activo mentres o túnel é inutilizable, e ese é o falso aprobado máis común. O arranque pode completarse antes de que a rede estea en liña se a unidade só espera network.target en lugar de network-online.target. Os ficheiros referenciados, como certificados, chaves ou unha CRL, poden ser ilexibles nese momento porque unha montaxe ou unha ruta de segredos aínda non está lista. Ningún dos dous problemas aparece en systemctl status ata que les o rexistro da unidade.

Proba desde fóra do host. Un cliente na mesma LAN pode ter éxito por unha ruta que ningún cliente remoto usaría xamais, e unha sesión SSH á máquina non demostra nada sobre o túnel. Conéctate, resolve un nome interno, chega ao recurso privado e despois volve conectarte unha vez para confirmar que o estado de revogación e as chaves aínda se aplican.

As tres condicións que deciden a túa corrección

Se o túnel volve pero os clientes non chegan a nada, o fallo está no encamiñamento ou na persistencia do NAT. Se os clientes nin sequera poden completar un handshake, o fallo está na interface ou no material de autenticación. Se o servizo nunca arrinca, o fallo está no ficheiro de unidade ou nas súas dependencias. Esas tres ramas levan a correccións distintas, e por iso un reinicio cego sen liña base custa máis tempo do que aforra.

Fai a corrección onde se posúe a configuración. Pon o reenvío nun drop-in de sysctl, pon as regras NAT no conxunto de regras que se carga no arranque, habilita a unidade en lugar de inicila, e garda os segredos nunha ruta que exista antes de que a unidade arrinque. Engadir unha espera á unidade oculta unha dependencia en lugar de declaraa.

Anota o resultado no runbook

Escribe que volveu por si só, que tiveches que iniciar e canto durou o oco. Inclúe os comandos exactos que usaches para verificar, para que a seguinte persoa repita a proba en lugar de inventar unha. Se algún paso necesitou un comando manual, ese comando pertence á configuración, non ao runbook como paso permanente.

Despois programa a seguinte proba para despois do seguinte cambio na pila de rede do host, non para unha data de calendario dentro de seis meses. O modo de fallo contra o que te protexes é un comando temporal que parecía permanente, e eses aparecen xusto cando alguén edita regras de devasas ou move un servizo a unha unidade nova.