Cómo restaurar un servidor VPN sin duplicar identidades

Restauró la copia de seguridad, el servicio arrancó y un cliente se conectó al primer intento. Ese éxito es la trampa. Una restauración devuelve los archivos que el servidor tenía en el momento de la instantánea, no el estado de acceso que ha cambiado desde entonces, y si el extremo antiguo sigue siendo accesible ahora tiene dos máquinas que responden a una identidad. La solución no es una copia mejor; es decidir qué puede ser el host restaurado antes de que responda a un solo apretón de manos.

Una copia de seguridad devuelve archivos, no autoridad

La instantánea contiene la configuración del servidor, las claves privadas, la autoridad de certificación, la lista de pares y las reglas del cortafuegos tal como estaban cuando se ejecutó la copia. No puede contener lo que cambió después: el dispositivo que revocó, la clave que reemitió, el par que eliminó cuando se vendió un portátil, la subred que movió. Restaurar rebobina los archivos hasta ese momento. No rebobina las decisiones que las personas han tomado desde entonces.

El daño viene exactamente de esa brecha. Un portátil robado, revocado dos semanas después de la copia, presenta un certificado que todavía se valida contra la CRL más antigua del árbol restaurado, y el servidor acepta un dispositivo que usted retiró. WireGuard es más directo: un par está autorizado por estar en la lista, así que un par borrado después de la instantánea simplemente vuelve a estar presente. Nadie volvió a aprobar ese acceso. El archivo antiguo lo hizo.

La identidad del servidor y la identidad del cliente fallan de maneras distintas

En WireGuard la identidad del servidor es la clave privada de wg0.conf, así que copiar ese archivo a un segundo host accesible crea dos servidores con la misma identidad y sin conocimiento entre ellos. Cada uno mantiene su propia lista de pares. Elimine un par en el host nuevo y el antiguo todavía lo acepta; compruebe wg show en uno y verá la mitad de la verdad. Los clientes tampoco conmutan solos: un perfil lleva un solo Endpoint, así que un dispositivo sigue hablando con la dirección con la que se configuró, que puede ser el host que quería retirar.

OpenVPN se duplica en la misma capa con un certificado de servidor, su clave privada y la clave estática tls-auth o tls-crypt. Copie las tres y un cliente no podrá distinguir las instancias; si ambas son accesibles, una reconexión puede caer en cualquiera, y cada archivo de registro cuenta una historia parcial. La autoridad de certificación es la copia más profunda. Un árbol easy-rsa restaurado es una segunda fuente de verdad que puede emitir un certificado válido para cualquier nombre que le dé.

Los clientes también se duplican, normalmente durante la propia migración. Copiar un perfil a un dispositivo de repuesto «solo para probar» produce un segundo dispositivo con la misma clave y el mismo nombre común. Con duplicate-cn ambas sesiones pueden seguir activas a la vez, y una asignación estática de dirección en ccd o ifconfig-pool-persist puede chocar con el dispositivo original. Son dos máquinas con una identidad, y nada en la configuración del servidor las distingue.

Elija uno de tres estados para el extremo antiguo

Una restauración solo es segura cuando el destino del extremo antiguo está decidido. Retírelo: el servicio antiguo debe dejar de aceptar el puerto VPN antes de que arranque el host nuevo, y si no puede llegar a la máquina, bloquee ese puerto en el borde de la red para todo excepto su origen administrativo. Repare el mismo host: reutilizar la identidad está bien porque una sola máquina la tiene, pero después destruya la copia en disco o la instantánea de la VM de la clave antigua para que no pueda volver. Construya una pareja de disponibilidad: dos hosts necesitan identidades de host distintas más un extremo compartido, como una dirección flotante, un balanceador de carga o un DNS que pueda mover. Copiar la clave privada no es un diseño de failover; son dos servidores reclamando un mismo nombre.

Confirme en qué estado está realmente antes de tocar a los clientes. El host antiguo que responde en el puerto VPN es el que aceptará el dispositivo revocado, aunque el DNS se haya movido. Compruebe los oyentes y la clave pública:

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

Primero reconcilie pares, revocaciones y direcciones

Enumere lo que afirma la restauración frente a lo que está autorizado ahora. En WireGuard, wg show wg0 da la clave, el extremo, el último apretón de manos y los contadores de transferencia de cada par, suficiente para detectar un dispositivo que ya no posee. Elimínelo en vivo con wg set wg0 peer <key> remove, y luego edite también la configuración, o el par volverá en el próximo arranque. wg show wg0 allowed-ips expone el segundo problema: dos pares en una dirección, o una dirección que ya reasignó.

En OpenVPN, la lista de revocación es un archivo con una fecha, y una restauración puede traer una antigua. Compruébela antes de que los clientes se conecten:

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

Si la última actualización es anterior a la revocación, el servidor sigue respetando un certificado que usted revocó. OpenVPN 2.4 y posteriores releen el archivo CRL en cada conexión nueva, así que reemplazar el archivo detiene las sesiones nuevas, pero los túneles establecidos persisten hasta la renegociación; el valor predeterminado de reneg-sec es 3600 segundos, y bajarlo o reiniciar el servicio es lo que le da el cambio ahora. Las compilaciones antiguas pueden no recoger el archivo con la misma fiabilidad, así que reinicie cuando no pueda confirmar el comportamiento de la versión. El manual de wg(8) cubre la eliminación de pares y la sintaxis allowed-ips usadas arriba.

Limpie también las asignaciones estáticas de dispositivos que ya no existen. Reutilizar la dirección de un dispositivo retirado para uno nuevo mientras el perfil antiguo sigue instalado crea exactamente el duplicado que intenta evitar.

Verifique con un cliente que haya revocado

Ejecute las comprobaciones en orden, desde una red fuera del túnel. Primero un dispositivo autorizado se conecta, resuelve DNS a través del resolutor empujado y alcanza un recurso privado. Después el dispositivo revocado debe fallar, usando su perfil existente en lugar de uno nuevo. Luego pruebe el extremo antiguo desde fuera: si el puerto VPN todavía completa un apretón de manos, el host antiguo está vivo y la duplicación es real, no teórica.

Reinicie el host restaurado y repita las comprobaciones de autorizado y revocado, porque es entonces cuando el archivo de configuración gana a lo que cambió en tiempo de ejecución. Compare la clave pública o la huella del certificado del host con la que usó la máquina retirada. Huellas coincidentes en dos máquinas vivas significan que la restauración clonó la identidad; huellas coincidentes en una sola máquina son correctas. Registre las versiones restauradas, las huellas de las claves y el número de serie o la clave de par revocados, y luego haga la siguiente copia tras esta reconciliación, para que represente el servicio tal como es ahora. La prueba que funciona no es que un cliente se conecte. Es que el cliente que eliminó quede fuera mientras el extremo antiguo quede cerrado.