Verificare il ripristino del server VPN dopo un riavvio: cosa controllare per primo

Riavvia il server senza che nessuno abbia effettuato l'accesso, poi collega da una rete che non controlli. Questo unico test risponde se il ripristino è reale, perché un tunnel che funziona solo dopo che qualcuno esegue un comando a mano non è ripristino, è una riparazione. La maggior parte dei controlli si ferma troppo presto: il demone risulta attivo, l'interfaccia appare, e la pagina ancora non si carica. Il divario è quasi sempre nella persistenza delle parti attorno al tunnel, non nel comando del tunnel stesso.

Quattro proprietari, quattro test diversi

Prima del riavvio, nomina ciò che dovrebbe riportare il tunnel. Il test che esegui e la correzione che applichi dipendono entrambi da quella risposta, e ci sono quattro proprietari comuni: un'unità systemd per il demone VPN, un'unità di istanza wg-quick per un'interfaccia WireGuard, un runtime di container o un profilo del gestore di rete. Se non riesci a nominare il proprietario, fermati e trovalo, perché un test di riavvio senza un percorso di avvio atteso ti dice solo che è successo qualcosa.

Ogni proprietario conserva la propria configurazione altrove. Un server OpenVPN gestito da systemd legge la configurazione all'avvio, quindi ciò che c'è nel file al boot è ciò che viene eseguito. Un'interfaccia wg-quick ricava indirizzi, rotte e DNS dallo stesso file, il che significa che un'interfaccia alzata a mano da una shell e mai abilitata come unità non tornerà. Un container riporta il suo entrypoint ma non le modifiche al firewall dell'host, a meno che queste non vivano fuori dal container.

Prima la baseline, altrimenti il risultato non significa nulla

Cattura lo stato funzionante mentre funziona: indirizzi sul tunnel, rotte per la subnet dei client, regole NAT o di inoltro, il socket in ascolto e il sysctl di inoltro. ip addr show wg0, ip route, nft list ruleset o iptables-save, ss -lunp e sysctl net.ipv4.ip_forward bastano sulla maggior parte degli host.

Annota come il servizio è configurato per avviarsi, non solo che è in esecuzione. systemctl is-enabled wg-quick@wg0 e systemctl is-active wg-quick@wg0 rispondono a domande diverse, e lo stato abilitato è quello che conta al boot, come descritto in systemctl(1). Per OpenVPN, controlla quale modello usa l'host, poiché openvpn@server e openvpn-server@server sono unità diverse con valori predefiniti diversi.

Esegui il riavvio e leggi il primo guasto

Riavvia di proposito, durante una finestra che hai scelto, con una console o un percorso fuori banda aperto. Osserva l'ordine degli eventi invece dello stato finale: host raggiungibile, unità attivata, interfaccia presente, rotte installate, regole del firewall presenti, listener associato, client accettato. Il primo passo che non avviene è la constatazione; tutto ciò che segue è rumore.

Un demone può essere attivo mentre il tunnel è inutilizzabile, e questo è il falso superamento più comune. L'avvio può completarsi prima che la rete sia online se l'unità attende solo network.target invece di network-online.target. I file referenziati come certificati, chiavi o una CRL possono essere illeggibili in quel momento perché un mount o un percorso dei segreti non è ancora pronto. Nessuno dei due problemi compare in systemctl status finché non leggi il journal dell'unità.

Prova da fuori dell'host. Un client sulla stessa LAN può riuscire attraverso una rotta che nessun client remoto userebbe mai, e una sessione SSH verso la macchina non dimostra nulla sul tunnel. Collegati, risolvi un nome interno, raggiungi la risorsa privata, poi ricollegati una volta per confermare che lo stato di revoca e le chiavi valgono ancora.

Le tre condizioni che decidono la tua correzione

Se il tunnel torna ma i client non raggiungono nulla, il guasto è nell'instradamento o nella persistenza del NAT. Se i client non riescono nemmeno a completare un handshake, il guasto è nell'interfaccia o nel materiale di autenticazione. Se il servizio non si avvia mai, il guasto è nel file di unità o nelle sue dipendenze. Questi tre rami portano a correzioni diverse, ed è per questo che un riavvio cieco senza baseline costa più tempo di quanto ne faccia risparmiare.

Esegui la correzione dove la configurazione è posseduta. Metti l'inoltro in un drop-in sysctl, metti le regole NAT nel set di regole che si carica al boot, abilita l'unità invece di avviarla, e tieni i segreti su un percorso che esiste prima che l'unità si avvii. Aggiungere un'attesa all'unità nasconde una dipendenza invece di dichiararla.

Registra il risultato nel runbook

Scrivi cosa è tornato da solo, cosa hai dovuto avviare e quanto è durato il divario. Includi i comandi esatti che hai usato per verificare, così la persona successiva ripete il test invece di inventarne uno. Se un passo ha richiesto un comando manuale, quel comando appartiene alla configurazione, non al runbook come passo permanente.

Poi pianifica il test successivo per dopo la prossima modifica allo stack di rete dell'host, non per una data di calendario tra sei mesi. La modalità di guasto da cui ti proteggi è un comando temporaneo che sembrava permanente, e questi compaiono esattamente quando qualcuno modifica le regole del firewall o sposta un servizio in una nuova unità.