Pritunl: stato di controllo o profilo generato

Un archivio ripristina un deployment Pritunl funzionante; l’altro ripristina un’immagine di esso. Un profilo client, una copia della configurazione dell’host e un tarball della directory di stato sembrano tutti backup, e nessuno di essi da solo riporta le organizzazioni, gli utenti e le definizioni dei server che Pritunl gestisce. La differenza è la proprietà: parte dello stato appartiene a un database, parte all’host e parte è output rigenerato. Scegli il livello sbagliato e il ripristino produce un server che si avvia, ascolta e non sa nulla. Questo confronto separa i tre livelli, così l’archivio che conservi corrisponde al guasto da cui ti stai riprendendo.

Due oggetti sembrano backup e solo uno ripristina il servizio

Un profilo client scaricato contiene un certificato, una chiave e un endpoint. È completo per quel singolo dispositivo e inutile come registro del deployment: non porta organizzazioni, utenti disabilitati, route dei server né account amministrativi. Ripristinare da una cartella di profili fornisce client che non possono autenticarsi contro nulla.

Una copia della configurazione dell’host è altrettanto parziale. /etc/pritunl.conf contiene impostazioni a livello di host, incluso come raggiungere il database, e non contiene gli oggetti VPN stessi.

Cosa possiede il database e cosa possiede l’host

Pritunl conserva definizioni dei server, utenti, organizzazioni e chiavi in MongoDB. Quel database è il control plane autorevole, e ogni file OpenVPN generato su disco è output derivato da esso. Una modifica fatta direttamente a un file generato sopravvive fino alla rigenerazione successiva e poi scompare, ed è per questo che modificare i file di runtime non è una correzione duratura. La stessa regola vale per route e interfacce effettive: descrivono ciò che il control plane ha prodotto, non ciò che dovrebbe produrre.

L’host fornisce un insieme di valori più piccolo ma non trasferibile. Uno è /var/lib/pritunl/pritunl.uuid, l’identità di quel particolare nodo.

Quell’identità conta soprattutto in un cluster. Un host sostitutivo ha bisogno della propria registrazione invece che di un clone dell’UUID di un nodo attivo, altrimenti i due si contendono la stessa identità. Registra la corrispondenza tra ogni host, il suo UUID e il database a cui punta, perché un singolo dump del database non descrive quali impostazioni dell’host appartenessero a quale macchina. Versioni software e nomi degli endpoint pubblici appartengono allo stesso registro.

Fai un dump coerente, non una copia della directory

Copiare la directory dati di MongoDB mentre il servizio scrive produce file che potrebbero non formare un database utilizzabile. Usa invece il percorso di dump supportato dal database, eseguito sulla topologia che hai davvero:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

Un host standalone tollera quella forma semplice. Un replica set ha bisogno di un punto nel tempo coerente, e un dump basato su oplog ha requisiti che un dump semplice non ha. La procedura supportata dipende dalla tua versione e topologia MongoDB, quindi non dedurla dalla presenza di una directory dati. Archivia il livello host accanto al dump, nella stessa esecuzione, con lo stesso timestamp.

Prova il ripristino prima di averne bisogno

Un backup che nessuno ha ripristinato è un’ipotesi. Costruisci il servizio in una rete isolata, ripristina il dump e rimetti a posto i file dell’host:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

Poi verifica gli oggetti invece del processo: accedi, conferma che organizzazioni e utenti siano presenti e avvia un client di test contro una definizione di server che riconosci. Evita che l’host ripristinato annunci l’endpoint di produzione o accetti connessioni reali finché indirizzi e identità non sono deliberati. È anche qui che scopri che l’archivio richiede credenziali che vivevano solo sulla macchina guasta, quindi conserva le credenziali di ripristino da qualche parte in modo indipendente. Un ripristino che dipende dall’host che hai appena perso non è un piano di ripristino.

Infine, ricorda che uno snapshot vecchio ripristina decisioni vecchie. Se un amministratore ha disabilitato un’identità dopo il dump, il ripristino la riabilita. La riconciliazione dopo il ripristino appartiene alla procedura, non al ripensamento.