Tres editores pueden publicar la dirección VPN de un controlador de dominio en DNS

Tres componentes distintos de un controlador de dominio con varias interfaces pueden meter la misma dirección VPN en DNS, y fallan de forma independiente. Compara lo que publica cada uno en lugar de fiarte de la casilla del adaptador, que solo controla uno de ellos. El síntoma es idéntico en todos los casos: un cliente resuelve el nombre, recibe la dirección del túnel y no puede llegar al controlador de dominio. Quién la publicó decide cómo detenerlo.

Un ajuste, un servicio y un rol; tres editores, tres interruptores.

Empieza por el registro, no por la casilla

Consulta el nombre completo del servidor afectado a través del servidor DNS que los clientes usan de verdad, y anota todas las direcciones devueltas. Contrasta cada dirección devuelta con las interfaces LAN y de túnel reales del servidor y con las redes en las que están los clientes. Una dirección puede ser perfectamente válida en local e inalcanzable para los clientes que importan. Los fallos de autenticación intermitentes son un síntoma habitual, porque los clientes reciben o eligen direcciones distintas en intentos distintos.

Que la máquina resuelva bien su propio nombre demuestra muy poco. La prueba que importa se ejecuta desde las redes de los clientes.

El adaptador es solo uno de los editores

Las propiedades TCP/IP del adaptador tienen una casilla para registrar la dirección de esa conexión, y desmarcarla silencia exactamente a un editor. No detiene a los demás, y por eso el registro puede reaparecer tras un reinicio. Si el controlador de dominio también ejecuta el servicio DNS, ese servicio tiene su propia configuración de escucha y sus propios registros de servidor de nombres. La guía de Microsoft para entornos con varias interfaces trata el comportamiento de la interfaz, el servicio DNS y Netlogon como editores relevantes separados.

Tres interruptores, tres propietarios, y solo uno de ellos vive en la página de propiedades del adaptador.

El servicio DNS tiene sus propias direcciones

Un servidor DNS al que se le dice que escuche en una dirección VPN sigue publicándola en sus propios registros, diga lo que diga la casilla del adaptador. Alinea las direcciones de escucha del servicio con las interfaces previstas y revisa al mismo tiempo las entradas de servidor de nombres de la zona. Cambiar las escuchas puede interrumpir a clientes que usan ahora mismo una dirección que retiras, así que establece primero quién depende de cada una. Borrar una escucha solo porque es una dirección VPN puede cortar a los clientes que querías ayudar.

Netlogon, y el descubrimiento de controladores de dominio en general, también registran direcciones como parte de sus propias funciones. No suprimas registros en todo el dominio ni copies un apaño antiguo de registro de acceso remoto sin confirmar que se aplica a tu versión y rol.

Propiedad antes de la limpieza

Arregla al editor antes de quitar el registro, o el siguiente evento de registro lo volverá a poner y el ejercicio se repetirá. Elimina las entradas obsoletas mediante el proceso del propietario del DNS y ten en cuenta la caché y el envejecimiento. Comprueba desde las redes de los clientes, cubriendo el descubrimiento de dominio y la aplicación que falló originalmente, y luego provoca el mismo evento VPN que produjo la dirección la primera vez.

Lo que quieres al final es un conjunto conocido de direcciones y escuchas publicadas, con el registro de dominio cotidiano haciendo todavía su trabajo. Una máquina cuyo nombre casualmente se resuelve bien justo después de una limpieza manual no es eso.

Anota qué editor era el responsable, qué registros cambiaron y qué clientes se probaron. El siguiente servidor con varias interfaces tendrá los mismos tres sospechosos.