Cambiar de proveedor de VPN: planifique el nombre de host, no solo la IP

Su registro DNS es correcto, el reemplazo está sano y, aun así, algunos clientes pasan horas marcando la dirección antigua. Unos pocos fallan de inmediato contra un nombre que se resuelve y nunca responde. Ambos resultados vienen de una misma laguna: un nombre de host cambia qué consulta un cliente, no cuándo lo consulta, ni en qué confía cuando llega la respuesta.

El síntoma: un registro correcto, túneles obsoletos

Un perfil que guarda un nombre no es un cliente que lo resuelva continuamente. La mayoría lo resuelve una vez, al aplicar la configuración o cuando sube el túnel, y luego reutiliza esa dirección hasta que termina la sesión. Un TTL largo encima es la razón por la que el cambio debe planificarse en torno a las reconexiones y no en torno a la edición del DNS.

Ninguno de los dos comportamientos es un defecto, y eso es lo que hace confuso el síntoma. El cliente trabaja con una respuesta que obtuvo antes, y nada del lado del servidor muestra cuál fue esa respuesta. Planifique la reconexión dentro de la ventana de mantenimiento y diga a los usuarios qué verán, o pase la ventana respondiendo tickets. Una cola de informes idénticos es el resultado habitual.

Quién controla el nombre y qué verifica el cliente

El control de la zona decide la rapidez con que puede avanzar una migración. Mantenga el registro en un registrador al que pueda entrar y anote quién más puede cambiarlo.

La confianza no sigue al nombre. Un cliente basado en TLS puede comprobar la identidad de un certificado o un nombre fijado, mientras que WireGuard autentica la clave pública del par e ignora por completo el nombre de host. Esa diferencia decide si basta con editar el DNS o si cada perfil necesita una huella nueva. Un cambio de registro nunca debería autorizar un punto final que nadie aprobó.

Mantenga el acceso administrativo y de recuperación lejos del nombre público del cliente. Perder una cuenta de alojamiento no debería costarle también el registro que redirige a los clientes. Guarde la ruta de recuperación en un lugar que no dependa del proveedor que deja.

Cuándo vuelve a leer el nombre cada cliente

El momento de la resolución es una propiedad de cada cliente, así que revise la implementación que realmente distribuye antes de prometer una ventana de cambio. wg-quick resuelve el punto final cuando sube la interfaz y conserva esa dirección hasta que se reinicia el túnel. Un cliente OpenVPN consulta el nombre al conectarse, y si vuelve a mirar al reconectarse depende de sus opciones.

Los clientes móviles son la sorpresa habitual, porque pueden conservar una dirección resuelta durante la suspensión o un cambio de red. Publique registros A y AAAA solo si el reemplazo responde en ambas familias. Una dirección que responde en una familia no demuestra nada sobre la otra, y un registro AAAA muerto añade un tiempo de espera a cada intento. Documente el comportamiento de resolución de cada cliente que admita y luego pruebe en los dispositivos que la gente usa de verdad.

La reconexión es una acción del usuario en la mayoría de los clientes, y el servidor no puede forzarla. Incluya ese paso en la nota de mantenimiento, con una línea sobre lo que verá el usuario cuando ocurra.

Cambie con pruebas y luego retire el punto final antiguo

Antes del cambio, demuestre cada capa en el reemplazo: el oyente responde, el cortafuegos deja pasar el puerto, las rutas vuelven por el camino correcto, el nombre se resuelve a la dirección nueva y una identidad conocida es aceptada. Un oyente que acepta una conexión no es lo mismo que uno que completa un handshake, así que pruebe el handshake y no el puerto. Mantenga la lista de revocación actual junto a la configuración, porque una copia de seguridad restaurada recrea la lista de pares tal como estaba y reabriría un acceso que ya había cerrado. Anote con qué identidad probó, porque «funciona» no es una prueba que nadie pueda repetir.

getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes

Durante la transición, observe los intentos de conexión en ambos puntos finales para la misma identidad. Un cliente que sigue autenticándose contra la dirección antigua es un perfil o una respuesta en caché que nunca se movió. Retire el punto final antiguo según un plan con fecha, porque dos servicios que aceptan una identidad dejan dos puertas abiertas.

La prueba del cambio es una sesión de aplicación a través del punto final nuevo, no un ping. Cuando esa sesión funcione y el punto final antiguo no registre intentos autorizados durante un ciclo completo de reconexión, el traslado habrá terminado.