Backup del server VPN: decidere cosa deve essere ripristinabile

Copiare un file di configurazione non è un backup, e un backup che nessuno può ripristinare non è un piano. L’archivio deve contenere l’identità del servizio, la politica che lo circonda e lo stato che dice quali dispositivi sono ancora ammessi. Deve anche essere protetto, perché nella maggior parte delle installazioni l’archivio concede esattamente ciò che concede la VPN. Decidere cosa deve essere ripristinabile viene prima; l’elenco dei file deriva da quella decisione.

Partite dall’obiettivo di ricostruzione

Scrivete cosa deve fare un server ricostruito prima di elencare un solo file: chiudere gli stessi tunnel, presentare la stessa identità e rifiutare i dispositivi attualmente revocati. Quella frase esclude la maggior parte delle copie ingenue, perché una directory di configurazione raramente contiene l’elenco delle revoche o la dipendenza esterna dell’identità. Espone anche le parti che vivono fuori dall’host, come i record DNS, le regole del firewall cloud e la directory contro cui il gateway si autentica. Un piano che le ignora produce un server ripristinato che sembra sano e non ammette nessuno.

Raggruppate il materiale in tre cesti: identità, configurazione e stato. L’identità sono le chiavi, i certificati e l’autorità che li firma. La configurazione sono le impostazioni del demone, i pool, le rotte e la politica del firewall, mentre lo stato è l’insieme di peer, account e revoche che cambia ogni giorno.

L’identità è la parte che non potete rigenerare

Le chiavi private non si possono ricreare a memoria, e i certificati che ne dipendono scadono secondo un calendario che ereditate anziché scegliere. Fate il backup della chiave del server, del materiale di provisioning dei client e dell’autorità di certificazione, poi annotate quali devono restare offline. Una chiave dell’autorità che vive solo sul gateway in funzione è a un compromesso di distanza da un ripristino completo dell’identità per ogni client. Annotate ciò che è deliberatamente conservato altrove, così nessuno lo duplica in un archivio meno protetto.

La revoca merita una riga propria nel piano. Ripristinare la configurazione di ieri può reintrodurre un’identità che avete rimosso oggi, il che trasforma un recupero in un incidente di sicurezza. Tenete lo stato di revoca attuale in un luogo indipendente dall’istantanea su cui tornereste, e controllatelo dopo ogni ripristino.

Catturate lo stato in un solo istante

Una copia presa mentre il servizio scrive produce un inventario incoerente, e dati di identità incoerenti sono peggiori di una copia pulita più vecchia. Usate il percorso di esportazione supportato per ogni archivio, poi registrate l’ora dell’istantanea, perché ogni domanda successiva sul ripristino dipende da essa.

wg showconf wg0 > /srv/backup/wg0.runtime.conf
sqlite3 /var/lib/vpn/admin.db ".backup '/srv/backup/admin.db'"
cp -a /etc/wireguard /srv/backup/etc-wireguard
sha256sum /srv/backup/*.conf > /srv/backup/MANIFEST

Il primo comando ristampa l’interfaccia in esecuzione come configurazione, che è il modo più rapido per catturare i peer aggiunti a mano anziché con uno strumento di gestione; il manuale di wg(8) lo documenta. La riga sqlite è il modello per un database di gestione: il comando di backup produce una copia coerente mentre lo scrittore continua. La copia della directory conserva i permessi, il che conta perché quei file di chiavi possono essere letti solo da root. Il manifesto è ciò che vi permette di distinguere un archivio completo da uno troncato.

Rendete possibile il ripristino, poi provatelo

Cifrate l’archivio e tenete la chiave di recupero altrove rispetto alla macchina da cui proviene. Un backup la cui passphrase esiste solo sul server guasto è un backup che nessuno aprirà. Limitate il recupero alle persone che potevano già amministrare il gateway, e registrate ogni recupero. Provate il ripristino su una rete isolata, perché un’identità clonata avviata accanto alla produzione crea due server che rispondono per la stessa chiave di peer.

Documentate le esclusioni con la stessa cura del contenuto. Le regole del firewall cloud, i record DNS e una directory esterna possono ciascuno richiedere il proprio passo di recupero. Una copia di file riuscita non è prova che il servizio torni; l’unica prova che conta è un endpoint ricostruito che supera lo stesso test di accettazione dell’originale.