Prova la recuperació del servidor VPN després d'un reinici: què cal comprovar primer

Reinicia el servidor sense que ningú hagi iniciat sessió i connecta't després des d'una xarxa que no controles. Aquesta única prova respon si la recuperació és real, perquè un túnel que només funciona després que algú executi una ordre a mà no és recuperació, és una reparació. La majoria de comprovacions s'aturen massa aviat: el dimoni es mostra actiu, la interfície apareix, i la pàgina encara no carrega. El buit és gairebé sempre la persistència de les peces al voltant del túnel, no l'ordre del túnel en si.

Quatre propietaris, quatre proves diferents

Abans del reinici, anomena què ha de tornar el túnel. La prova que executes i la correcció que apliques depenen totes dues d'aquesta resposta, i hi ha quatre propietaris habituals: una unitat systemd per al dimoni VPN, una unitat d'instància wg-quick per a una interfície WireGuard, un runtime de contenidors o un perfil de gestor de xarxa. Si no pots anomenar el propietari, atura't i troba'l, perquè una prova de reinici sense un camí d'arrencada esperat només et diu que alguna cosa ha passat.

Cada propietari guarda la seva configuració en un lloc diferent. Un servidor OpenVPN gestionat per systemd llegeix la configuració en arrencar, així que el que hi hagi al fitxer en el moment d'arrencar és el que s'executa. Una interfície wg-quick obté les adreces, les rutes i el DNS del mateix fitxer, cosa que significa que una interfície aixecada a mà des d'un shell i mai habilitada com a unitat no tornarà. Un contenidor recupera el seu punt d'entrada, però no els canvis del tallafoc de l'amfitrió tret que aquests visquin fora del contenidor.

Primer la línia base, o el resultat no vol dir res

Captura l'estat de funcionament mentre funciona: adreces al túnel, rutes per a la subxarxa de clients, regles NAT o de reenviament, el sòcol d'escolta i el sysctl de reenviament. ip addr show wg0, ip route, nft list ruleset o iptables-save, ss -lunp i sysctl net.ipv4.ip_forward són suficients a la majoria d'amfitrions.

Anota com està configurat el servei per arrencar, no només que s'estigui executant. systemctl is-enabled wg-quick@wg0 i systemctl is-active wg-quick@wg0 responen preguntes diferents, i l'estat habilitat és el que importa en arrencar, tal com es descriu a systemctl(1). Per a OpenVPN, comprova quin patró fa servir l'amfitrió, ja que openvpn@server i openvpn-server@server són unitats diferents amb valors per defecte diferents.

Executa el reinici i llegeix la primera fallada

Reinicia expressament, durant una finestra que hagis triat, amb una consola o un camí fora de banda obert. Observa l'ordre dels esdeveniments en lloc de l'estat final: amfitrió accessible, unitat activada, interfície present, rutes instal·lades, regles del tallafoc presents, oient lligat, client acceptat. El primer pas que no passa és la troballa; tot el que ve després és soroll.

Un dimoni pot estar actiu mentre el túnel és inutilitzable, i aquesta és la falsa aprovació més habitual. L'arrencada pot completar-se abans que la xarxa estigui en línia si la unitat només espera network.target en lloc de network-online.target. Els fitxers referenciats com certificats, claus o una CRL poden ser illegibles en aquell moment perquè un muntatge o un camí de secrets encara no està a punt. Cap dels dos problemes no apareix a systemctl status fins que llegeixes el registre de la unitat.

Prova des de fora de l'amfitrió. Un client a la mateixa LAN pot tenir èxit per una ruta que cap client remot no faria servir, i una sessió SSH a la màquina no demostra res sobre el túnel. Connecta't, resol un nom intern, arriba al recurs privat i torna a connectar-te un cop per confirmar que l'estat de revocació i les claus encara s'apliquen.

Les tres condicions que decideixen la teva correcció

Si el túnel torna però els clients no arriben enlloc, la fallada és en l'encaminament o en la persistència del NAT. Si els clients ni tan sols poden completar un handshake, la fallada és en la interfície o en el material d'autenticació. Si el servei no arrenca mai, la fallada és en el fitxer d'unitat o en les seves dependències. Aquestes tres branques porten a correccions diferents, i per això un reinici a cegues sense línia base costa més temps del que estalvia.

Fes la correcció on la configuració és propietat. Posa el reenviament en un drop-in de sysctl, posa les regles NAT al conjunt de regles que es carrega en arrencar, habilita la unitat en lloc d'iniciar-la, i guarda els secrets en un camí que existeixi abans que la unitat arrenqui. Afegir una espera a la unitat amaga una dependència en lloc de declarar-la.

Anota el resultat al runbook

Escriu què va tornar tot sol, què vas haver d'iniciar i quant va durar el buit. Inclou les ordres exactes que vas fer servir per verificar, perquè la propera persona repeteixi la prova en lloc d'inventar-ne una. Si algun pas va necessitar una ordre manual, aquella ordre pertany a la configuració, no al runbook com a pas permanent.

Després programa la propera prova per després del proper canvi a la pila de xarxa de l'amfitrió, no per a una data de calendari d'aquí a sis mesos. El mode de fallada contra el qual et protegeixes és una ordre temporal que semblava permanent, i aquestes apareixen exactament quan algú edita regles del tallafoc o mou un servei a una unitat nova.