Por qué un nombre de servidor se resuelve en su dirección VPN tras la conexión telefónica

Un servidor de archivos de oficina responde en su dirección de LAN toda la mañana, y luego un usuario remoto se conecta por teléfono y el nombre empieza a resolverse en una dirección de túnel. No se editó nada en DNS a mano, y esa es la pista: el registro lo publicó la propia máquina. Tres condiciones deciden si corrige el registrador, el registro o la visión del cliente, y equivocarse en el orden hace que el registro vuelva tras la siguiente conexión.

Dos direcciones, un nombre, tres condiciones

Un servidor Windows con varias interfaces puede tener una dirección de LAN, una o más direcciones de conexión telefónica y a veces una segunda tarjeta de red. Cada interfaz puede registrar sus propias direcciones en DNS si se le permite el registro dinámico. Cuando el adaptador PPP se registra, el mismo nombre de host gana una dirección que solo puede alcanzar el par del túnel, y los clientes de la LAN la reciben como una respuesta válida.

Tres condiciones deciden la reparación. Primero, ¿es alcanzable la dirección adicional desde los clientes que la reciben? Segundo, ¿algún consumidor sigue dependiendo de ese registro? Tercero, ¿el registro es dinámico y, por tanto, puede volver, o es estático y, por tanto, una entrada deliberada?

Responda eso antes de tocar nada. Si la dirección no es alcanzable desde la red que consulta, ninguna limpieza de la caché del cliente lo arregla por mucho tiempo. Si algo depende de ella, como una ruta de gestión que usan los propios pares del túnel, quitarla rompe esa ruta en su lugar. Y un registro dinámico borrado sin atender a su publicador reaparecerá en el siguiente evento de registro.

Lea el registro antes de cambiar el registrador

Consulte el nombre completo cualificado exacto desde la red que informa del problema y compare las respuestas con las interfaces y los agentes de escucha reales del servidor. Un solo nombre que devuelve varias direcciones es normal; la cuestión es si cada una es utilizable por el cliente que la recibe.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

La primera consulta usa el resolutor local, la segunda pregunta directamente a un servidor DNS concreto y la tercera hace lo mismo desde PowerShell en Windows. Compararlas separa una caché de cliente obsoleta de una respuesta autoritativa. Si la consulta directa ya devuelve la dirección del túnel, el problema son los datos publicados y no la caché local.

Anote la marca de tiempo del registro y si la consola de DNS lo muestra como dinámico. Ese único atributo le dice cuál de las tres condiciones anteriores se aplica, y es la diferencia entre una limpieza de cinco minutos y una reparación que dura.

Corrija al publicador o corrija el registro, pero sepa cuál

Si el registro es dinámico y no se desea, la solución duradera es impedir que esa interfaz se registre. Windows expone ajustes de registro por interfaz, y el servicio cliente de DNS vuelve a publicar en la siguiente conexión o cambio de dirección. Desactivar el registro del adaptador de conexión telefónica deja intacto el registro del adaptador de LAN, que suele ser lo que se quiere.

Tenga cuidado con los conmutadores de toda la máquina. Un ajuste global que desactiva la actualización dinámica afecta a cada interfaz de ese host, incluida aquella en cuyo registro confían otros clientes. En un controlador de dominio la misma precaución se aplica con más fuerza, porque el host también puede poseer registros de ubicación de servicio de los que dependen los clientes para iniciar sesión.

Si el registro es estático, se colocó ahí a propósito y la conversación es con quien lo colocó. Borrar un registro estático porque hoy resulta inconveniente elimina la única prueba de por qué existe. En ambos casos, borre la respuesta obsoleta solo después de haber atendido al publicador, y anote qué cambió para que la siguiente persona pueda distinguir una entrada deliberada de un accidente.

Verifique desde la red de cliente que falló

La verificación pertenece a la red que informó del síntoma, no al servidor. Limpie la caché del resolutor del cliente mediante su mecanismo admitido y, después, repita la consulta original y la conexión original al servicio por nombre.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

El primer comando limpia la caché del resolutor de Windows, y el segundo muestra si el nombre vuelve a estar en caché y qué dirección se guardó. Una conexión correcta del servidor consigo mismo no demuestra nada sobre un cliente de la LAN, y quitar una ruta hacia la dirección no deseada no corrige lo que publica el DNS.

Por último, repita el evento que antes introducía la dirección: vuelva a conectar el cliente VPN o renueve la sesión de conexión telefónica. Compruebe de nuevo el nombre publicado tras ese cambio de ciclo de vida. Una reparación que solo dura hasta la siguiente conexión fue una limpieza, no una reparación, y saber cuál de las dos hizo es la diferencia entre cerrar el tique y volver a abrirlo la próxima semana.