Mover un servidor VPN a una nueva IP pública: qué comprobar primero

Reasignar una dirección lleva un minuto. La semana siguiente es donde se rompe la mudanza, y rara vez donde lo sugiere la consola del proveedor. Una IP pública nueva se referencia en cuatro lugares: el socket en el que escucha el demonio, el ancla de confianza que verifican los clientes, cada regla que nombra la dirección antigua y el registro DNS que los une. Dos mudanzas parecen idénticas desde un panel de control pero se comportan de forma totalmente distinta: reasignar la dirección en la máquina que usted opera, o levantar un segundo endpoint y mover clientes a él. Las comprobaciones de abajo ponen primero los fallos baratos, y cada sección indica a qué mudanza se aplica.

El reemplazo in situ y el corte paralelo son trabajos distintos

El reemplazo in situ conserva el host, las claves, la tabla de rutas y la lista de usuarios; solo cambia la dirección. Eso es lo que hace una reasignación de IP flotante, y en varios proveedores el invitado no se entera, porque la traducción ocurre delante de la instancia. Una reconstrucción o una reasignación del proveedor es más dura: el invitado ve el cambio, y todo lo que había cacheado el valor antiguo lo aprende en el mismo momento.

Un endpoint paralelo es un segundo host que hace el mismo trabajo. Constrúyalo, pruébelo con un perfil y deje que el viejo responda hasta que el nuevo se demuestre por una ruta real. El precio es el estado. Sin entradas de peer compartidas, revocaciones y registro, tiene dos redes que casualmente comparten un nombre.

Encuentre cada lugar donde está escrita la dirección antigua

Empiece con un barrido de texto, porque los archivos de configuración son la mitad fácil. Busque en la configuración del demonio, los fragmentos de cortafuegos, los objetivos de monitorización y cualquier paquete de cliente generado en disco. Incluya la dirección IPv6 si publica una; una mudanza que solo sigue el registro A deja a los clientes de doble pila en la ruta antigua.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

Después recorra el núcleo, porque un sistema en marcha guarda la dirección en lugares que ningún archivo menciona. Una regla NAT de origen estática, una entrada de ipset, una dirección de enlace y una entrada de conntrack sobreviven a la edición de configuración que las eliminó, y algunas sobreviven a un reinicio porque volvieron de un conjunto de reglas guardado. Una capa más arriba, los grupos de seguridad del proveedor, los objetivos del balanceador y las comprobaciones de monitorización no están en su sistema de archivos en absoluto.

Escriba el inventario antes de cambiar nada; también sirve como guion de reversión.

Los clientes con nombre de host se recuperan; los clientes con IP literal se callan

Si los clientes llegan al servidor por nombre de host, el corte es sobre todo un problema de DNS, y el TTL que fijó ayer decide cuán malo será. Los resolutores cachean, los resolutores stub cachean otra vez, y muchos clientes solo buscan el nombre en una conexión nueva, así que un túnel establecido conserva su dirección inicial.

Si el endpoint es una dirección literal, nada vuelve a resolverse y nada registra una queja. WireGuard guarda una dirección de socket resuelta: Endpoint = vpn.example.net:51820 se convierte en una IP en el momento en que se ejecuta wg-quick up y sigue siendo esa IP hasta que la cambie. OpenVPN es más indulgente: resuelve el nombre de host remote al conectar y, con resolv-retry infinite, vuelve a probar DNS al reconectar. Con una IP literal, ambos siguen marcando una máquina que ya no existe.

Lo que engaña a la gente es la imagen especular. Un cliente ya apuntado a la dirección nueva, mientras el escucha viejo aún responde, pasa todas las pruebas que haga desde su escritorio. A mí me engañó: el nuevo endpoint subió en un teléfono al primer intento, y un cliente con un perfil obsoleto solo apareció cuando el escucha viejo se apagó mucho después.

La confianza no se muda con la dirección

WireGuard separa la identidad de la accesibilidad, lo que hace casi gratis mover una dirección. Los peers se identifican por clave pública, y el endpoint es solo adonde van los paquetes ahora; un host actualiza el endpoint de un peer a partir de la dirección de origen del paquete autenticado más reciente. Un peer inactivo sigue necesitando un motivo para hablar con el sitio nuevo, y aprende la dirección solo cuando su sesión caduca y los reintentos de handshake fallan en algún lugar visible. El inicio rápido de WireGuard cubre el campo endpoint.

Los servidores basados en TLS son el caso opuesto. El certificado está ligado a un nombre, y un cliente que marca una dirección compara lo marcado con los nombres alternativos del sujeto. Conecte por IP a un certificado que solo lleva un SAN de DNS y la verificación falla: el nombre que usó el cliente no está en el certificado. Reemitir con un SAN de IP arregla esa conexión y empeora la siguiente mudanza. Mantener un nombre de host en el perfil y dejar verify-x509-name en su sitio mantiene la comprobación estricta mientras la dirección de debajo cambia.

Luego compruebe a qué está ligado el demonio; un socket fijado a la dirección antigua falla en silencio. Un servidor OpenVPN arrancado con local 203.0.113.10 se niega a subir una vez que esa dirección desaparece, mientras que un escucha en 0.0.0.0 sigue el cambio gratis. NAT se divide igual: MASQUERADE sigue la dirección que ahora tenga la máquina, y un SNAT --to-source 203.0.113.10 estático sigue reescribiendo hacia una dirección que ya no posee, así que el tráfico de retorno desaparece. Si la dirección nueva llega con otra puerta de enlace upstream, compruebe rp_filter: el filtrado de ruta inversa descarta el tráfico de retorno que llega por una interfaz que el núcleo no esperaba.

Orden del corte y las pruebas de que funcionó

Baje el TTL un día antes, levante el nuevo escucha y demuéstrelo con un perfil que solo tenga usted. Una prueba desde dentro de la misma red no demuestra casi nada, así que use un teléfono con datos móviles y pruebe algo que el túnel deba transportar en lugar de un ping al endpoint.

Vigile ambas direcciones durante la ventana. wg show all latest-handshakes en el host nuevo, o el archivo de estado de OpenVPN, le dice cuántos peers se han movido de verdad. Cuando el nuevo endpoint tenga los peers que espera y el viejo solo tenga rezagados, retire el escucha viejo, elimine la regla NAT obsoleta y saque la dirección del cortafuegos del proveedor. Retirar el escucha viejo es el paso que se salta, y cierra el hueco donde un perfil obsoleto aún alcanza la red antigua.

Fije por escrito el disparador de reversión antes de empezar: si el nuevo endpoint no tiene handshake de un solo cliente real tras la ventana acordada, restaure la dirección antigua y deje de distribuir perfiles. Vuelva a ejecutar el barrido después y confirme que ningún escucha sigue ligado a una dirección retirada. Dos cosas pasan a la siguiente mudanza: un nombre de host en el perfil del cliente para que el siguiente cambio sea una edición de DNS, y el inventario guardado junto a las notas de recuperación del servidor.