Router nuevo, mismo servidor VPN: mueva su entrada pública

Conecte el router nuevo, vuelve internet y el cliente VPN del teléfono sigue apuntando a una dirección que ya no responde. En el servidor VPN no ha cambiado nada, porque el servidor nunca se movió. El router era el punto de entrada público, y sustituirlo sustituyó la dirección, la regla de reenvío y quizá el actualizador de DNS dinámico al mismo tiempo.

Trate el cambio como dos traspasos, no uno, y mantenga una vía local a la interfaz de administración mientras trabaja.

Anote el traspaso antes de desenchufar

Registre el prefijo de LAN, la dirección del servidor y cómo se asigna, el escucha y el transporte que el VPN usa en realidad, la regla de entrada que lo publica y el nombre que han guardado los clientes. Luego anote qué máquina actualiza hoy el registro de DNS dinámico: puede ser el router, el propio servidor o un agente aparte en otro host. Hágalo mientras las páginas de administración antiguas todavía cargan. Una captura de pantalla de la regla de entrada vale más que un número de puerto recordado.

Añada los prefijos privados a los que los clientes deben llegar y cómo los dispositivos de la LAN les envían las respuestas de vuelta. Los dos se olvidan con facilidad porque el asistente de sustitución habla de acceso a internet, no de caminos de vuelta. Exporte también la configuración antigua si el fabricante admite restaurarla, aceptando que una copia de un modelo rara vez se importa limpia en otro.

Guarde ese registro en un lugar protegido. Una copia de seguridad del router puede contener credenciales del enlace WAN. Trate el archivo exportado como una contraseña y no como una nota de ajustes.

Mueva primero la dirección y después el reenvío

Si el router nuevo conserva el mismo prefijo de LAN, dé al servidor la reserva que tenía o una asignación estática equivalente. Si el prefijo cambia, actualice primero la dirección del servidor y cualquier vinculación de escucha que la nombre, porque un reenvío hacia la dirección antigua enviará el tráfico en silencio a ninguna parte.

Después recree exactamente una regla de entrada para el transporte que usa el VPN. Las guías de fabricante que describen el reenvío a un servidor local muestran el mecanismo, no una receta universal, así que adapte la regla a su protocolo y puerto reales y no a una lista de un blog. Un reenvío en el router nuevo no puede eliminar el NAT de nivel de operador que está por encima, y ninguna regla local hará que una dirección privada sea accesible desde internet si el proveedor ya comparte una con usted.

Confirme que el cortafuegos del propio servidor sigue permitiendo ese tráfico. Compruebe si entre el router e internet hay una segunda puerta de enlace, porque muchos proveedores entregan módem y router combinados. Lea la dirección WAN del dispositivo nuevo y compárela con la dirección que resuelven los clientes. Si difieren, su reenvío está aterrizando en algo que no es el borde.

Decida quién actualiza el nombre público

Las actualizaciones del punto final necesitan un propietario y solo uno. Si el router antiguo publicaba el nombre, configure un actualizador compatible en el sustituto y confirme que el registro cambió de verdad. Si el servidor ya lo publicaba, deje esa disposición tranquila en lugar de añadir un actualizador rival que oscila entre dos direcciones.

Cuando el despliegue publica las dos familias de direcciones, lea tanto el registro A como el AAAA. Cada uno tiene que apuntar a un servicio que escuche de verdad y que esté permitido por su propio camino de cortafuegos, y una asignación IPv4 que funciona no dice nada del lado IPv6. Mantenga también las comprobaciones de identidad en el perfil del cliente: una dirección pública cambiada no es motivo para aceptar un certificado o una clave de par que no coincida.

Demuestre el cambio desde fuera

Pruebe con una conexión externa autorizada y una sesión nueva, no desde dentro de la LAN. Una prueba interna contra la dirección pública depende del comportamiento de retorno hacia la misma dirección y recorre un camino distinto del que hará un cliente real.

Siga la secuencia que sigue un cliente: resuelva el nombre, negocie el túnel, autentíquese y después realice una operación contra un recurso privado. Ese último paso es el que la gente se salta, y es el único que demuestra el camino de vuelta. Si el inicio de sesión funciona pero la operación privada falla, compare el prefijo de LAN nuevo, las rutas que eligió el cliente y el camino de respuesta del recurso con sus notas de traspaso.

Solo cuando pasan los cuatro pasos el router antiguo se puede retirar con seguridad. Desenchúfelo y repita la prueba externa una vez más. Un registro obsoleto que todavía resuelve a la dirección antigua falla ya en el primer paso, y eso es más fácil de diagnosticar mientras el dispositivo antiguo sigue en la estantería.

Guarde la nueva asignación con sus notas de recuperación

Archive la asignación final del servidor, la regla de entrada y el nombre del propietario de la actualización junto al procedimiento para llegar al router localmente. El siguiente cambio debería empezar en esa página y no en un traceroute.

Si el túnel sigue fallando desde fuera después de todo lo anterior, compruebe si la dirección pública que informa el router coincide con la que resuelven los clientes. Esa única comparación separa un problema de DNS de un problema de reenvío, y lleva menos tiempo que leer otra guía de reenvío de puertos.