Pritunl: estado de control fronte ao perfil xerado

Un arquivo restaura unha implantación de Pritunl funcional; o outro restaura unha imaxe dela. Un perfil de cliente, unha copia da configuración do anfitrión e un tarball do directorio de estado parecen todos copias de seguridade, e ningún deles por si só devolve as organizacións, os usuarios e as definicións de servidor que xestiona Pritunl. A diferenza é a propiedade: parte do estado pertence a unha base de datos, parte ao anfitrión e parte é saída rexenerada. Escolla a capa equivocada e a restauración produce un servidor que arrinca, escoita e non sabe nada. Esta comparación separa as tres capas para que o arquivo que garde coincida co fallo do que se recupera.

Dous obxectos parecen copias de seguridade e só un restaura o servizo

Un perfil de cliente descargado contén un certificado, unha chave e un punto de conexión. Está completo para ese único dispositivo e é inútil como rexistro da implantación: non leva organizacións, nin usuarios desactivados, nin rutas de servidor, nin contas administrativas. Restaurar desde un cartafol de perfís dá clientes que non poden autenticarse contra nada.

Unha copia da configuración do anfitrión é igualmente parcial. /etc/pritunl.conf contén axustes a nivel de anfitrión, incluído como chegar á base de datos, e non contén os propios obxectos VPN.

O que posúe a base de datos e o que posúe o anfitrión

Pritunl garda as definicións de servidor, os usuarios, as organizacións e as chaves en MongoDB. Ese base de datos é o plano de control autoritativo, e cada ficheiro OpenVPN xerado no disco é saída derivada del. Un cambio feito directamente nun ficheiro xerado sobrevive ata a seguinte rexeneración e despois desaparece, e por iso editar ficheiros de execución non é unha corrección duradeira. A mesma regra aplícase ás rutas e interfaces efectivas: describen o que produciu o plano de control, non o que debería producir.

O anfitrión achega un conxunto de valores máis pequeno pero non transferible. Un deles é /var/lib/pritunl/pritunl.uuid, a identidade dese nodo concreto.

Esa identidade importa sobre todo nun clúster. Un anfitrión de substitución necesita a súa propia inscrición en lugar dun clon do UUID dun nodo activo, ou os dous pelexan pola mesma identidade. Rexistre a correspondencia entre cada anfitrión, o seu UUID e a base de datos á que apunta, porque un único volcado da base de datos non describe que axustes do anfitrión pertencían a que máquina. As versións de software e os nomes de punto de conexión públicos pertencen ao mesmo rexistro.

Faga un volcado consistente, non unha copia de directorio

Copiar o directorio de datos de MongoDB mentres o servizo escribe produce ficheiros que poden non formar unha base de datos utilizábel. Use en cambio a ruta de volcado admitida pola base de datos, executada contra a topoloxía que realmente teña:

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 anfitrión autónomo tolera esa forma simple. Un conxunto de réplicas necesita un punto no tempo consistente, e un volcado baseado en oplog ten requisitos que un volcado simple non ten. O procedemento admitido depende da súa versión e topoloxía de MongoDB, así que non o deduza da presenza dun directorio de datos. Archive a capa do anfitrión xunto ao volcado, na mesma execución e coa mesma marca de tempo.

Ensaie a restauración antes de necesitala

Unha copia de seguridade que ninguén restaurou é unha hipótese. Constrúa o servizo nunha rede illada, restaure o volcado e volva poñer os ficheiros do anfitrión:

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

Despois verifique os obxectos en lugar do proceso: inicie sesión, confirme que as organizacións e os usuarios están presentes e levante un cliente de proba contra unha definición de servidor que recoñeza. Evite que o anfitrión restaurado anuncio o punto de conexión de produción ou acepte conexións reais ata que os enderezos e as identidades sexan deliberados. Aquí tamén descobre que o arquivo necesita credenciais que só vivían na máquina fallida, así que garde as credenciais de recuperación nalgún lugar independente. Unha restauración que depende do anfitrión que acaba de perder non é un plan de restauración.

Por último, lembre que unha instantánea antiga restaura decisións antigas. Se un administrador desactivou unha identidade despois de tomar o volcado, a restauración volve activala. A reconciliación tras a recuperación pertence ao procedemento, non á reflexión posterior.