Un registro DDNS obsoleto frente a un extremo VPN roto: cómo distinguirlos

Desde fuera, un nombre de host obsoleto y una VPN rota parecen idénticos. El cliente resuelve un nombre, el nombre apunta a algún sitio y la conexión expira o se rechaza. Uno es un problema de actualización de DNS y el otro es un problema de autenticación o de reenvío, y la diferencia solo se vuelve evidente cuando compara la dirección publicada con la dirección que su línea tiene en realidad.

Dos fallos que se presentan igual

El primer fallo es que el registro todavía lista la dirección WAN de ayer. El segundo es que el registro es correcto y el túnel lo rechaza por motivos propios. Ambos producen el mismo mensaje en el cliente, y la tentación es empezar a regenerar certificados.

El orden importa aquí. Comprobar el DNS lleva un minuto y es reversible. Regenerar una CA no es ni una cosa ni la otra.

Compare las direcciones antes que nada

Pregunte al propietario de la red qué dirección tiene la línea ahora mismo y luego pregunte al DNS qué publica. dig +short vpn.example.com da la respuesta que recibirá su cliente, y dig @1.1.1.1 vpn.example.com muestra si otro resolutor ve algo distinto. Si esos dos no coinciden, está viendo comportamiento de caché y no un actualizador roto.

Una respuesta recursiva puede quedarse atrás respecto a una actualización por su TTL, así que mantenga el registro autoritativo y lo que su portátil haya almacenado en cajas separadas.

Qué es realmente la credencial del actualizador

Los dispositivos DDNS antiguos suelen autenticarse con la propia contraseña de la cuenta, y por eso cambiarla los rompe en silencio. Siguen reintentando con el valor antiguo y no informan de nada útil. La guía de contraseñas de dispositivo de No-IP documenta exactamente este problema de compatibilidad en hardware antiguo, y la respuesta sensata es una credencial de actualización de alcance limitado en lugar de una contraseña de cuenta más débil.

Los mecanismos más nuevos emiten un token o clave de actualización aparte con su propio ciclo de vida. Ese es el valor que hay que rotar en el router y el que hay que registrar en su inventario de credenciales. Tampoco es el valor que conviene pegar en un hilo de chat mientras depura.

Revise el estado no secreto del actualizador: hora del último éxito, categoría de respuesta y el nombre de host que cree poseer. Un rechazo de credencial y un fallo de conectividad necesitan correcciones distintas.

Qué no puede hacer una corrección de DNS

Corregir el registro no crea accesibilidad entrante. Si la línea está detrás de NAT de nivel de operador, ningún nombre de host hará que funcione una conexión entrante. Tampoco abre una regla de cortafuegos ni reenvía un puerto. Y nunca es una razón para desactivar la verificación del servidor en el cliente, que es el movimiento que hace la gente cuando decide que el certificado debe ser el problema.

A la inversa, cambiar la contraseña de la VPN no es una corrección para un DNS obsoleto. Solo añade un segundo fallo al mismo tíquet.

Reconecte y demuéstrelo de extremo a extremo

Cuando el registro autoritativo sea correcto, el cliente puede conservar aún una consulta antigua. Use su reconexión o refresco de extremo compatible y déle un momento en lugar de machacar conectar. Después demuestre la ruta en cuatro pasos: resuelva el nombre, confirme la dirección, compruebe que se alcanza el receptor y autentíquese. Cuatro resultados separados, cuatro respuestas separadas.

Mantenga el actualizador en la lista de verificación de rotación junto a la cuenta de la VPN. Un propietario de registro previsto, una credencial válida y un éxito observable es lo que evita la siguiente versión de este tíquet.