Como restaurar un servidor VPN sen duplicar identidades

Restaurou a copia de seguridade, o servizo arrincou e un cliente conectouse ao primeiro intento. Ese éxito é a trampa. Unha restauración devolve os ficheiros que o servidor tiña no momento da instantánea, non o estado de acceso que cambiou desde entón, e se o extremo antigo segue sendo accesible agora ten dúas máquinas que responden a unha identidade. A solución non é unha copia mellor; é decidir que pode ser o host restaurado antes de que responda a unha soa aperta de mans.

Unha copia de seguridade devolve ficheiros, non autoridade

A instantánea contén a configuración do servidor, as chaves privadas, a autoridade de certificación, a lista de pares e as regras da devasa tal como estaban cando se executou a copia. Non pode conter o que cambiou despois: o dispositivo que revogou, a chave que reemitiu, o par que eliminou cando se vendeu un portátil, a subrede que moveu. Restaurar rebobina os ficheiros ata ese momento. Non rebobina as decisións que as persoas tomaron desde entón.

O dano vén exactamente desa fenda. Un portátil roubado, revogado dúas semanas despois da copia, presenta un certificado que aínda se valida contra a CRL máis antiga na árbore restaurada, e o servidor acepta un dispositivo que retirou. WireGuard é máis directo: un par está autorizado por estar na lista, así que un par borrado despois da instantánea simplemente volve estar presente. Ninguén volveu aprobar ese acceso. O ficheiro antigo fíxoo.

A identidade do servidor e a identidade do cliente fallan de maneiras distintas

En WireGuard a identidade do servidor é a chave privada en wg0.conf, así que copiar ese ficheiro a un segundo host accesible crea dous servidores coa mesma identidade e sen coñecemento entre eles. Cada un mantén a súa propia lista de pares. Elimine un par no host novo e o antigo aínda o acepta; comprobe wg show nun e verá a metade da verdade. Os clientes tampouco conmutan sós: un perfil leva un só Endpoint, así que un dispositivo segue falando co enderezo co que se configurou, que pode ser o host que quería retirar.

OpenVPN duplícase na mesma capa cun certificado de servidor, a súa chave privada e a chave estática tls-auth ou tls-crypt. Copie as tres e un cliente non poderá distinguir as instancias; se ambas son accesibles, unha reconexión pode caer en calquera, e cada ficheiro de rexistro conta unha historia parcial. A autoridade de certificación é a copia máis profunda. Unha árbore easy-rsa restaurada é unha segunda fonte de verdade que pode emitir un certificado válido para calquera nome que lle dea.

Os clientes tamén se duplican, normalmente durante a propia migración. Copiar un perfil a un dispositivo de reserva «só para probar» produce un segundo dispositivo coa mesma chave e o mesmo nome común. Con duplicate-cn ambas sesións poden seguir activas á vez, e unha asignación estática de enderezo en ccd ou ifconfig-pool-persist pode chocar co dispositivo orixinal. Son dúas máquinas cunha identidade, e nada na configuración do servidor as distingue.

Escolla un de tres estados para o extremo antigo

Unha restauración só é segura cando o destino do extremo antigo está decidido. Retíreo: o servizo antigo debe deixar de aceptar o porto VPN antes de que arrinque o host novo, e se non pode chegar á máquina, bloquee ese porto no bordo da rede para todo excepto a súa orixe administrativa. Repare o mesmo host: reutilizar a identidade está ben porque unha soa máquina a ten, pero despois destruír a copia en disco ou a instantánea da VM da chave antiga para que non poida volver. Constrúa unha parella de dispoñibilidade: dous hosts necesitan identidades de host distintas máis un extremo compartido, como un enderezo flotante, un balanceador de carga ou un DNS que poida mover. Copiar a chave privada non é un deseño de failover; son dous servidores reclamando un mesmo nome.

Confirme en que estado está realmente antes de tocar os clientes. O host antigo que responde no porto VPN é o que aceptará o dispositivo revogado, aínda que o DNS se movese. Comprobe os oíntes e a chave pública:

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

Primeiro reconcilie pares, revogacións e enderezos

Enumere o que afirma a restauración fronte ao que está autorizado agora. En WireGuard, wg show wg0 dá a chave, o extremo, a última aperta de mans e os contadores de transferencia de cada par, suficiente para detectar un dispositivo que xa non posúe. Elimíneo en vivo con wg set wg0 peer <key> remove, e logo edite tamén a configuración, ou o par volverá no próximo arrinque. wg show wg0 allowed-ips expón o segundo problema: dous pares nun enderezo, ou un enderezo que xa reasignou.

En OpenVPN, a lista de revogación é un ficheiro cunha data, e unha restauración pode traer unha antiga. Compróbea antes de que os clientes se conecten:

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

Se a última actualización é anterior á revogación, o servidor segue respectando un certificado que vostede revogou. OpenVPN 2.4 e posteriores releren o ficheiro CRL en cada conexión nova, así que substituír o ficheiro detén as sesións novas, pero os túneles establecidos persisten ata a renegociación; o valor predeterminado de reneg-sec é 3600 segundos, e baixalo ou reiniciar o servizo é o que lle dá o cambio agora. As compilacións antigas poden non coller o ficheiro coa mesma fiabilidade, así que reinicie cando non poida confirmar o comportamento da versión. O manual de wg(8) cobre a eliminación de pares e a sintaxe allowed-ips usadas arriba.

Limpe tamén as asignacións estáticas de dispositivos que xa non existen. Reutilizar o enderezo dun dispositivo retirado para un novo mentres o perfil antigo segue instalado crea exactamente o duplicado que intenta evitar.

Verifique cun cliente que revogase

Execute as comprobacións en orde, desde unha rede fóra do túnel. Primeiro un dispositivo autorizado conéctase, resolve DNS a través do resolvedor empurrado e alcanza un recurso privado. Despois o dispositivo revogado debe fallar, usando o seu perfil existente en lugar dun novo. Logo probe o extremo antigo desde fóra: se o porto VPN aínda completa unha aperta de mans, o host antigo está vivo e a duplicación é real, non teórica.

Reinicie o host restaurado e repita as comprobacións de autorizado e revogado, porque é entón cando o ficheiro de configuración gaña ao que cambiou en tempo de execución. Compare a chave pública ou a pegada do certificado do host coa que usou a máquina retirada. Pegadas coincidentes en dúas máquinas vivas significan que a restauración clonou a identidade; pegadas coincidentes nunha soa máquina son correctas. Rexistre as versións restauradas, as pegadas das chaves e o número de serie ou a chave de par revogados, e logo faga a seguinte copia tras esta reconciliación, para que represente o servizo tal como é agora. A proba que funciona non é que un cliente se conecte. É que o cliente que eliminou quede fóra mentres o extremo antigo queda pechado.