Cómo retirar un servidor VPN sin dejar acceso atrás

Su cliente todavía se conecta el día en que se abre el ticket de retirada. Un perfil está en la aplicación, negocia, y el túnel sube como si nada hubiera cambiado. Ese es el momento de trabajar en la dirección opuesta a cómo construyó el servicio: empiece por la lista de clientes, avance hacia fuera hasta el oyente, luego hasta el cortafuegos y termine con las credenciales que sobreviven a todos ellos. Apagar la VM es el último paso, no el primero. Este recorrido supone que tiene acceso de consola al host y la autoridad para editar registros de clientes y DNS.

Recorra primero la lista de clientes

Abra lo que sea que distribuya sus perfiles y lea la lista antes de tocar el servidor. Cada entrada es un dispositivo que cree tener acceso: teléfonos, portátiles, un router de sucursal, un contenedor que se sincroniza cada noche. Exporte esa lista al ticket, porque una vez que el host desaparezca no habrá ningún wg show que le diga quién estaba conectado.

Clasifique cada dispositivo en punto final de reemplazo, ya no necesario o desconocido. El cubo de los desconocidos es el que importa, ya que son los perfiles que alguien encontrará en un cajón dentro de unos meses y probará. Envíe el aviso por el mismo canal que usa para las solicitudes de acceso y ponga en él una fecha para cuando el punto final antiguo deje de responder.

Revoque la identidad, no solo el archivo

Dos acciones distintas reciben ambas el nombre de revocación. En WireGuard, un par solo se autoriza por su clave pública que aparece en una sección de par con una entrada AllowedIPs, así que borrar el archivo de configuración del portátil no cambia nada en el servidor. Elimine el bloque del par y vuelva a aplicar el archivo sin dejar caer los pares que conserva, como describe el manual de wg(8):

wg show
wg set wg0 peer <CLIENT_PUBLIC_KEY> remove
wg syncconf wg0 <(wg-quick strip wg0)

wg syncconf es la parte que le ahorra una ventana de mantenimiento. Reconstruye la interfaz desde el archivo en su sitio, así que eliminar un par no derriba el túnel que todos los demás usan. Si retira todo el host en lugar de un solo par, el orden sigue importando, porque esas claves pueden ser de confianza en otro lugar.

Con una configuración X.509 el paso de revocación es el certificado, no el archivo: openssl ca -revoke client.crt y luego openssl ca -gencrl -out crl.pem. Eso solo surte efecto donde el verificador lo lee, lo que significa que un OpenVPN servidor con crl-verify configurado y recargado después. Si esta puerta de enlace es el único consumidor de esa CA, la CRL deja de importar el día que muere; si la misma CA firma para una segunda puerta de enlace, un certificado que nunca revocó sigue funcionando allí.

Las cuentas son el tercer caso y el que más a menudo se omite. Cuando la puerta de enlace se autenticaba contra RADIUS, LDAP o un proveedor de identidad alojado, la cuenta vive fuera de la VPN. Desactívela en el directorio. Borrar una estanza de usuario en el servidor deja una credencial válida que el punto final de reemplazo aceptará en el momento en que apunte al mismo directorio.

Cierre los oyentes y los caminos hacia ellos

Detenga el servicio de una forma que sobreviva a un reinicio y luego confírmelo con un listado de sockets en lugar del estado de la unidad. systemctl disable --now wg-quick@wg0 detiene la interfaz y elimina las rutas y reglas que añadió wg-quick; systemctl disable --now openvpn-server@server hace lo mismo para una instancia de OpenVPN con plantilla. Siga cualquiera de las dos con ss -lunp y ss -ltnp. Un resultado vacío para el puerto antiguo es la única prueba que cuenta.

Lo que wg-quick añadió, wg-quick lo quita. Lo que añadió a mano se queda: una regla NAT persistente, un permiso de cortafuegos, un reenvío de puerto del router, una regla de entrada de un grupo de seguridad en la nube, un oyente de equilibrador de carga. Todos necesitan una eliminación explícita, y también el registro DNS, es decir el A, el AAAA y cualquier CNAME que apunte al nombre. Un nombre que resuelve a un host muerto falla de forma distinta a un nombre que no resuelve, y esa diferencia le costará una tarde a alguien.

La copia que olvida es el clon. Una instantánea o una VM restaurada desde una copia de seguridad todavía guarda las claves del host y la lista antigua de pares, y si algo la devuelve a la misma dirección, los clientes se reconectan a un servicio que usted cree retirado. Etiquete el conjunto de copias como perteneciente a un servicio dado de baja y manténgalo fuera de las rutas de restauración automáticas.

Persiga lo que todavía apunta al punto final antiguo

Los perfiles en caché sobreviven al DNS. Una configuración guardada con una dirección numérica sigue marcando después de que el registro desaparezca, y un cliente siempre activo reintenta en cada cambio de red. Eso es ruido y no acceso, porque el oyente está cerrado, pero saber cuál de los dos está mirando decide cómo responde al ticket.

Luego barra las dependencias que nadie archiva bajo VPN: comprobaciones de disponibilidad que sondean el puerto, tareas de copia que extraían configuraciones del host, credenciales de automatización usadas para empujar entradas de pares, cuentas de recuperación creadas solo para este punto final. Cada una es una ruta de acceso con su propia vida y su propio dueño, así que cada una recibe una decisión en lugar de un borrado silencioso.

Verifique y luego anótelo

La retirada termina cuando una prueba desde fuera falla tal como usted espera. Desde una red que no controla, conéctese a la dirección y el puerto antiguos. Un resultado filtrado o rechazado es el caso de éxito. En la aplicación del cliente, confirme que el perfil se eliminó y no solo se apagó, y que ningún perfil de gestión lo vuelve a añadir en silencio.

Luego registre lo que hizo: punto final, fecha, claves y certificados revocados, cuentas desactivadas, dónde viven las copias de seguridad. Quien encuentre después una configuración antigua necesita responder si se revocó o solo se borró, sin adivinar, y una tabla breve en el ticket lo consigue.

Antes de cerrar el ticket:

• perfiles de cliente eliminados o reemplazados, dispositivos desconocidos resueltos
• pares eliminados y la configuración reaplicada, o certificados revocados y la CRL publicada
• cuentas del directorio desactivadas, no solo archivos locales borrados
• servicio desactivado, ningún oyente queda en el puerto antiguo
• cortafuegos, reenvío de puerto, grupo de seguridad y registros DNS eliminados
• copias de seguridad etiquetadas, instantánea excluida de las rutas de restauración
• credenciales de monitorización y automatización retiradas

Verifique el reemplazo por separado, desde un cliente que nunca tuvo el perfil antiguo. Esa única prueba le dice si retiró un servicio o solo le cambió el nombre al problema.