Pritunl: estat de control enfront del perfil generat

Un arxiu restaura un desplegament de Pritunl funcional; l’altre restaura una imatge d’aquest. Un perfil de client, una còpia de la configuració de l’amfitrió i un tarball del directori d’estat s’assemblen tots a còpies de seguretat, i cap d’ells per si sol no retorna les organitzacions, els usuaris i les definicions de servidor que gestiona Pritunl. La diferència és la propietat: una part de l’estat pertany a una base de dades, una part a l’amfitrió i una part és sortida regenerada. Trieu la capa equivocada i la restauració produeix un servidor que arrenca, escolta i no sap res. Aquesta comparació separa les tres capes perquè l’arxiu que guardeu coincideixi amb la fallada de la qual us recupereu.

Dos objectes s’assemblen a còpies de seguretat i només un restaura el servei

Un perfil de client descarregat conté un certificat, una clau i un punt de connexió. És complet per a aquest dispositiu i inútil com a registre del desplegament: no porta cap organització, cap usuari desactivat, cap ruta de servidor ni cap compte administratiu. Restaurar des d’una carpeta de perfils dona clients que no es poden autenticar contra res.

Una còpia de la configuració de l’amfitrió és igualment parcial. /etc/pritunl.conf conté ajustos a nivell d’amfitrió, incloent com arribar a la base de dades, i no conté els objectes VPN en si.

Què posseeix la base de dades i què posseeix l’amfitrió

Pritunl desa les definicions de servidor, els usuaris, les organitzacions i les claus a MongoDB. Aquesta base de dades és el pla de control autoritatiu, i cada fitxer OpenVPN generat al disc és sortida derivada d’ella. Un canvi fet directament en un fitxer generat sobreviu fins a la regeneració següent i després desapareix, i per això editar fitxers d’execució no és una correcció duradora. La mateixa regla s’aplica a les rutes i interfícies efectives: descriuen què ha produït el pla de control, no què hauria de produir.

L’amfitrió aporta un conjunt de valors més petit però no transferible. Un d’ells és /var/lib/pritunl/pritunl.uuid, la identitat d’aquest node concret.

Aquesta identitat importa sobretot en un clúster. Un amfitrió de substitució necessita la seva pròpia inscripció en lloc d’un clon de l’UUID d’un node actiu, o els dos es barallen per la mateixa identitat. Registreu la correspondència entre cada amfitrió, el seu UUID i la base de dades a la qual apunta, perquè un sol bolcat de la base de dades no descriu quins ajustos de l’amfitrió pertanyien a quina màquina. Les versions de programari i els noms de punt de connexió públics pertanyen al mateix registre.

Feu un bolcat consistent, no una còpia de directori

Copiar el directori de dades de MongoDB mentre el servei escriu produeix fitxers que poden no formar una base de dades utilitzable. Feu servir en canvi el camí de bolcat suportat per la base de dades, executat contra la topologia que realment teniu:

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 amfitrió autònom tolera aquesta forma simple. Un conjunt de rèpliques necessita un punt en el temps consistent, i un bolcat basat en oplog té requisits que un bolcat simple no té. El procediment suportat depèn de la vostra versió i topologia de MongoDB, així que no l’infreu de la presència d’un directori de dades. Archiveu la capa de l’amfitrió al costat del bolcat, en la mateixa execució i amb la mateixa marca de temps.

Assageu la restauració abans de necessitar-la

Una còpia de seguretat que ningú ha restaurat és una hipòtesi. Construïu el servei en una xarxa aïllada, restaureu el bolcat i torneu a posar els fitxers de l’amfitrió:

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

Després verifiqueu els objectes en lloc del procés: inicieu sessió, confirmeu que les organitzacions i els usuaris hi són i engegueu un client de prova contra una definició de servidor que reconegueu. Eviteu que l’amfitrió restaurat anunciï el punt de connexió de producció o accepti connexions reals fins que les adreces i les identitats siguin deliberades. És també aquí on descobriu que l’arxiu necessita credencials que només vivien a la màquina avariada, així que guardeu les credencials de recuperació en un lloc independent. Una restauració que depèn de l’amfitrió que acabeu de perdre no és un pla de restauració.

Finalment, recordeu que una instantània antiga restaura decisions antigues. Si un administrador va desactivar una identitat després de fer el bolcat, la restauració la torna a activar. La reconciliació després de la recuperació pertany al procediment, no a la reflexió posterior.