Como restaurar um servidor VPN sem duplicar identidades

Restaurou a cópia de segurança, o serviço iniciou e um cliente ligou-se à primeira tentativa. Esse sucesso é a armadilha. Uma restauração devolve os ficheiros que o servidor tinha no momento da instantânea, não o estado de acesso que mudou desde então, e se o endpoint antigo ainda está acessível tem agora duas máquinas a responder a uma identidade. A solução não é uma cópia melhor; é decidir o que o anfitrião restaurado pode ser antes de responder a um único handshake.

Uma cópia de segurança devolve ficheiros, não autoridade

A instantânea contém a configuração do servidor, as chaves privadas, a autoridade de certificação, a lista de pares e as regras da firewall tal como estavam quando a cópia correu. Não pode conter o que mudou depois: o dispositivo que revogou, a chave que reemitiu, o par que removeu quando um portátil foi vendido, a sub-rede que moveu. Restaurar rebobina os ficheiros até esse momento. Não rebobina as decisões que as pessoas tomaram desde então.

O dano vem exatamente dessa lacuna. Um portátil roubado revogado duas semanas depois da cópia apresenta um certificado que ainda valida contra a CRL mais antiga na árvore restaurada, e o servidor aceita um dispositivo que retirou. WireGuard é mais direto: um par é autorizado por estar listado, por isso um par apagado após a instantânea está simplesmente presente outra vez. Ninguém voltou a aprovar esse acesso. O ficheiro antigo fê-lo.

A identidade do servidor e a identidade do cliente falham de formas diferentes

No WireGuard a identidade do servidor é a chave privada em wg0.conf, por isso copiar esse ficheiro para um segundo anfitrião acessível cria dois servidores com a mesma identidade e sem conhecimento um do outro. Cada um mantém a sua própria lista de pares. Remova um par no anfitrião novo e o antigo continua a aceitá-lo; verifique wg show num e vê metade da verdade. Os clientes também não mudam sozinhos: um perfil transporta um único Endpoint, por isso um dispositivo continua a falar com o endereço com que foi configurado, que pode ser o anfitrião que queria retirar.

OpenVPN duplica-se na mesma camada com um certificado de servidor, a sua chave privada e a chave estática tls-auth ou tls-crypt. Copie as três e um cliente não distingue as instâncias; se ambas estiverem acessíveis, uma reconexão pode cair em qualquer uma, e cada ficheiro de registo conta uma história parcial. A autoridade de certificação é a cópia mais profunda. Uma árvore easy-rsa restaurada é uma segunda fonte de verdade que pode emitir um certificado válido para qualquer nome que lhe dê.

Os clientes também são duplicados, normalmente durante a própria migração. Copiar um perfil para um dispositivo de reserva «só para testar» produz um segundo dispositivo com a mesma chave e o mesmo nome comum. Com duplicate-cn as duas sessões podem ficar ativas ao mesmo tempo, e uma atribuição estática de endereço em ccd ou ifconfig-pool-persist pode colidir com o dispositivo original. São duas máquinas com uma identidade, e nada na configuração do servidor as distingue.

Escolha um de três estados para o endpoint antigo

Uma restauração só é segura quando o destino do endpoint antigo está decidido. Retire-o: o serviço antigo tem de parar de aceitar a porta VPN antes de o anfitrião novo arrancar, e se não conseguir chegar à máquina, bloqueie essa porta na borda da rede para tudo exceto a sua origem administrativa. Repare o mesmo anfitrião: reutilizar a identidade está bem porque uma só máquina a detém, mas depois destrua a cópia em disco ou a instantânea da VM da chave antiga para que não possa voltar. Construa um par de disponibilidade: dois anfitriões precisam de identidades de anfitrião distintas mais um endpoint partilhado, como um endereço flutuante, um balanceador de carga ou um DNS que possa mover. Copiar a chave privada não é um desenho de failover; são dois servidores a reclamar um só nome.

Confirme em que estado está realmente antes de tocar nos clientes. O anfitrião antigo que responde na porta VPN é o que vai aceitar o dispositivo revogado, mesmo que o DNS tenha mudado. Verifique os ouvintes e a chave pública:

ss -lunp | grep -E ':51820|:1194'
wg show wg0
wg pubkey < /etc/wireguard/server.key

Primeiro reconcilie pares, revogações e endereços

Liste o que a restauração alega face ao que está autorizado agora. No WireGuard, wg show wg0 dá a chave, o endpoint, o último handshake e os contadores de transferência de cada par, o suficiente para detetar um dispositivo que já não possui. Remova-o ao vivo com wg set wg0 peer <key> remove, e depois edite também a configuração, senão o par regressa no próximo arranque. wg show wg0 allowed-ips expõe o segundo problema: dois pares num endereço, ou um endereço que já reatribuiu.

No OpenVPN a lista de revogação é um ficheiro com uma data, e uma restauração pode trazer uma antiga. Verifique-a antes de os clientes se ligarem:

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
grep -E 'crl-verify|reneg-sec' /etc/openvpn/server.conf

Se a última atualização é anterior à revogação, o servidor ainda está a honrar um certificado que revogou. O OpenVPN 2.4 e posteriores releem o ficheiro CRL em cada nova ligação, por isso substituir o ficheiro para as sessões novas, mas os túneis estabelecidos persistem até à renegociação; o valor predefinido de reneg-sec é 3600 segundos, e é baixá-lo ou reiniciar o serviço que lhe dá a mudança agora. Compilações antigas podem não ler o ficheiro com a mesma fiabilidade, por isso reinicie quando não conseguir confirmar o comportamento da versão. O manual do wg(8) cobre a remoção de pares e a sintaxe allowed-ips usadas acima.

Limpe também as atribuições estáticas de dispositivos que já não existem. Reutilizar o endereço de um dispositivo retirado para um novo enquanto o perfil antigo ainda está instalado cria exatamente o duplicado que tenta evitar.

Verifique com um cliente que revogou

Execute as verificações por ordem, a partir de uma rede fora do túnel. Primeiro um dispositivo autorizado liga-se, resolve DNS através do resolver empurrado e alcança um recurso privado. Depois o dispositivo revogado tem de falhar, usando o perfil existente e não um novo. Por fim experimente o endpoint antigo de fora: se a porta VPN ainda completa um handshake, o anfitrião antigo está vivo e a duplicação é real, não teórica.

Reinicie o anfitrião restaurado e repita as verificações de autorizado e revogado, porque é então que o ficheiro de configuração vence o que alterou em tempo de execução. Compare a chave pública ou a impressão digital do certificado do anfitrião com a que a máquina retirada usou. Impressões digitais iguais em duas máquinas vivas significam que a restauração clonou a identidade; impressões iguais numa só máquina são normais. Registe as versões restauradas, as impressões digitais das chaves e o número de série ou a chave do par revogados, e depois faça a cópia seguinte após esta reconciliação, para representar o serviço como está agora. O teste que funciona não é que um cliente se ligue. É que o cliente que removeu fique de fora enquanto o endpoint antigo fica fechado.