Cópia de segurança do servidor VPN: decida o que deve poder ser restaurado

Copiar um ficheiro de configuração não é uma cópia de segurança, e uma cópia que ninguém consegue restaurar não é um plano. O arquivo deve conter a identidade do serviço, a política que o rodeia e o estado que diz quais dispositivos ainda são permitidos. Também tem de ser protegido, porque na maioria das implementações o arquivo concede exatamente o que a VPN concede. Decidir o que deve poder ser restaurado vem primeiro; a lista de ficheiros decorre dessa decisão.

Comece pelo objetivo de reconstrução

Escreva o que um servidor reconstruído tem de fazer antes de listar um único ficheiro: terminar os mesmos túneis, apresentar a mesma identidade e recusar os dispositivos que estão presentemente revogados. Essa frase exclui a maioria das cópias ingénuas, porque um diretório de configuração raramente contém a lista de revogações ou a dependência externa de identidade. Também expõe as partes que vivem fora do anfitrião, como registos DNS, regras de firewall na nuvem e o diretório contra o qual a gateway se autentica. Um plano que as ignora produz um servidor restaurado que parece saudável e não admite ninguém.

Agrupe o material em três cestos: identidade, configuração e estado. A identidade são as chaves, os certificados e a autoridade que os assina. A configuração são os parâmetros do daemon, os pools, as rotas e a política de firewall, enquanto o estado é o conjunto de pares, contas e revogações que muda todos os dias.

A identidade é a parte que não pode regenerar

As chaves privadas não podem ser recriadas de memória, e os certificados que dependem delas expiram segundo um calendário que herda em vez de escolher. Faça cópia da chave do servidor, do material de aprovisionamento de clientes e da autoridade de certificação, e depois anote quais deles devem permanecer offline. Uma chave de autoridade que só vive na gateway em funcionamento está a um compromisso de distância de um restauro completo de identidade para cada cliente. Registe o que é deliberadamente guardado noutro lugar, para que ninguém o duplique num arquivo com menor proteção.

A revogação merece a sua própria linha no plano. Restaurar a configuração de ontem pode repor uma identidade que removeu hoje, o que transforma uma recuperação num incidente de segurança. Mantenha o estado de revogação atual num local independente do instantâneo para o qual voltaria, e verifique-o depois de qualquer restauro.

Capture o estado num único momento

Uma cópia tirada enquanto o serviço escreve produz um inventário inconsistente, e dados de identidade inconsistentes são piores do que uma cópia limpa mais antiga. Utilize o caminho de exportação suportado para cada armazenamento e depois registe a hora do instantâneo, porque qualquer pergunta posterior sobre o restauro depende dela.

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

O primeiro comando imprime a interface em execução de volta como configuração, que é a forma mais rápida de capturar pares adicionados à mão em vez de por uma ferramenta de gestão; o manual do wg(8) documenta-o. A linha sqlite é o padrão para uma base de dados de gestão: o comando de cópia produz uma cópia consistente enquanto o escritor continua. A cópia do diretório preserva as permissões, o que importa porque esses ficheiros de chaves só podem ser lidos pelo root. O manifesto é o que permite distinguir um arquivo completo de um truncado.

Torne o restauro possível e só depois experimente-o

Cifre o arquivo e guarde a chave de recuperação noutro local que não a máquina de onde veio. Uma cópia cuja frase-passe só existe no servidor falhado é uma cópia que ninguém abrirá. Restrinja a obtenção às pessoas que já podiam administrar a gateway, e registe cada obtenção. Teste o restauro numa rede isolada, porque uma identidade clonada levantada ao lado da produção cria dois servidores que respondem pela mesma chave de par.

Documente as exclusões com o mesmo cuidado que o conteúdo. As regras de firewall na nuvem, os registos DNS e um diretório externo podem cada um precisar do seu próprio passo de recuperação. Uma cópia de ficheiros bem-sucedida não é prova de que o serviço regressa; a única prova que conta é um ponto final reconstruído que passa o mesmo teste de aceitação que o original.