Asignación de sitio de AD frente a fijar un controlador de dominio para clientes VPN

Los clientes de acceso remoto de un grupo VPN pueden acabar hablando con un controlador de dominio al otro lado del mundo, y eso se corrige de dos maneras: describir el grupo como una subred de Active Directory vinculada al sitio que tiene los controladores correctos, o fijar el cliente o la aplicación a un controlador concreto. La primera es una declaración de topología sobre la que DC Locator puede actuar. La segunda es una anulación por aplicación que ignora la topología por completo. Cuestan cosas distintas, y echar mano hoy de la más rápida es justo cómo un equipo de directorio termina manteniendo las dos.

Qué cambia realmente cada enfoque

Un objeto de subred es un registro del directorio que dice a qué sitio pertenece un rango de direcciones. Con el módulo de Active Directory y un sitio existente, la operación es lo bastante pequeña para previsualizarla:

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

-WhatIf previsualiza la escritura en el directorio. No crea el objeto ni comprueba si un cliente de ese rango puede alcanzar algo, que es justo la parte que la gente espera. DC Locator lee el modelo de sitios cuando resuelve los registros de servicio, así que un objeto de subred exacto cambia lo que se le ofrece al cliente.

Fijar funciona en otra capa. Un nombre de controlador fijo en la configuración de una aplicación, una cadena LDAP con un host dentro o un valor de registro que nombra un servidor preferido eliminan el descubrimiento del camino. La aplicación habla con ese controlador hasta que alguien cambia el ajuste, y la conmutación por error es lo que implemente esa aplicación.

Dónde gana la asignación de subred

Asignar el grupo describe la ubicación de red una vez, para cada cliente que usa DC Locator. Cuando el grupo pasa de una /24 a tres, el modelo cambia en dos o tres objetos en lugar de en un inventario de aplicaciones. Esa es toda la ventaja, y es grande cuando la población de clientes no está bajo tu control.

La trampa es que el objeto tiene que coincidir con la dirección que el controlador ve de verdad. Si la pasarela VPN traduce cada cliente a una dirección de concentrador, añadir el grupo sin traducir describe una ubicación de red que ningún controlador observa jamás. Decide pronto si el diseño conserva la dirección de origen del cliente y, si no lo hace, asigna el rango traducido en lugar del grupo que configuraste en el servidor VPN.

Un segundo límite: el modelo de sitios es una preferencia y una declaración de topología. No hace que un controlador sea alcanzable ni concede nada a un usuario. Las rutas y la política de cortafuegos dan la alcanzabilidad; la política de cuentas da la autorización.

Dónde gana fijar

Fijar es la respuesta correcta cuando el descubrimiento no puede funcionar: una aplicación antigua que resuelve un controlador por un nombre que no puedes cambiar, un filtro que permite exactamente una dirección de controlador, o un conjunto fijo de servidores en el que el controlador forma parte del diseño de la aplicación. En esos casos la fijación es documentación de una restricción real, no un atajo.

Su costo es lo contrario de la asignación. Un nombre fijado no sigue al grupo, no conmuta por error salvo que la aplicación sepa hacerlo, y no sobrevive a un cambio de nombre ni a la retirada de un controlador sin un repaso de inventario. También esconde problemas de topología, porque cada cliente que fija parece sano mientras el modelo de sitios se pudre en silencio.

Sustituir los registros de dirección ordinarios del dominio por un solo servidor preferido no es una tercera opción. Rompe a todo consumidor que espera el conjunto de descubrimiento normal, y además no controla cómo un cliente consciente del directorio elige un sitio.

Elige con tres condiciones

Pregúntalas en este orden y la decisión suele tomarse sola. Primero, ¿usa la aplicación DC Locator, o ya lleva una dirección de controlador? Segundo, ¿ve el controlador la dirección del grupo o una traducida? Tercero, ¿con qué frecuencia cambia el grupo comparado con cuántos lugares habría que actualizar con una fijación?

Aplicaciones conscientes del directorio más enrutamiento que conserva el origen más un grupo que cambia: asigna la subred. Una aplicación que no puede descubrir, o un filtro que admite una dirección: fíjala, y escribe por qué. Todo lo demás es un caso para arreglar la topología en lugar de añadir otra anulación.

Verifica desde el cliente VPN y mantén los contratos separados

Prueba desde el camino remoto real, no desde una estación de trabajo LAN que ya está en el sitio. Solo cuenta la visión del propio cliente:

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

Si el sitio informado es el que asignaste, el objeto coincide. Si el cliente no informa ningún sitio, la dirección que presenta no cae dentro de ningún objeto de subred, lo que suele significar una traducción o un prefijo obsoleto. Luego comprueba que el controlador elegido es el que pretendías antes de suponer que la asignación falló, porque los clientes cachean los resultados de descubrimiento y la conmutación por error puede elegir legítimamente otro controlador.

Mantén los tres contratos en un solo documento: el grupo y sus objetos de subred, los controladores alcanzables desde el camino VPN y la política que decide qué puede hacer un usuario autenticado. Un sitio no es una regla de cortafuegos ni una frontera de contención, y el próximo cambio de grupo desconectará en silencio a los usuarios remotos del modelo de red del directorio salvo que la asignación, las rutas y las alternativas documentadas se muevan juntas.