Asignación de sitio de AD fronte a fixar un controlador de dominio para clientes VPN

Os clientes de acceso remoto dun pool VPN poden acabar falando cun controlador de dominio na outra punta do mundo, e iso corríxese de dúas maneiras: describir o pool como unha subrede de Active Directory vinculada ao sitio que ten os controladores correctos, ou fixar o cliente ou a aplicación a un controlador concreto. A primeira é unha declaración de topoloxía sobre a que DC Locator pode actuar. A segunda é unha anulación por aplicación que ignora a topoloxía por completo. Custan cousas distintas, e botar man hoxe da máis rápida é xusto como un equipo de directorio acaba mantendo as dúas.

Que cambia realmente cada enfoque

Un obxecto de subrede é un rexistro do directorio que di a que sitio pertence un rango de enderezos. Co módulo de Active Directory e un sitio existente, a operación é o bastante pequena para previsualizala:

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

-WhatIf previsualiza a escritura no directorio. Non crea o obxecto nin comproba se un cliente dese rango pode alcanzar algo, que é xusto a parte que a xente espera. DC Locator le o modelo de sitios cando resolve os rexistros de servizo, así que un obxecto de subrede exacto cambia o que se lle ofrece ao cliente.

Fixar funciona noutra capa. Un nome de controlador fixo na configuración dunha aplicación, unha cadea LDAP cun host dentro ou un valor de rexistro que nomea un servidor preferido eliminan o descubrimento do camiño. A aplicación fala con ese controlador ata que alguén cambia o axuste, e a conmutación por erro é o que implemente esa aplicación.

Onde gaña a asignación de subrede

Asignar o pool describe a localización de rede unha vez, para cada cliente que usa DC Locator. Cando o pool pasa dunha /24 a tres, o modelo cambia en dous ou tres obxectos en lugar de nun inventario de aplicacións. Esa é toda a vantaxe, e é grande cando a poboación de clientes non está baixo o teu control.

A trampa é que o obxecto ten que coincidir co enderezo que o controlador ve de verdade. Se a pasarela VPN traduce cada cliente a un enderezo de concentrador, engadir o pool sen traducir describe unha localización de rede que ningún controlador observa xamais. Decide cedo se o deseño conserva o enderezo de orixe do cliente e, se non o fai, asigna o rango traducido en lugar do pool que configuraches no servidor VPN.

Un segundo límite: o modelo de sitios é unha preferencia e unha declaración de topoloxía. Non fai que un controlador sexa alcanzable nin lle concede nada a un usuario. As rutas e a política de cortalumes dan a alcanzabilidade; a política de contas dá a autorización.

Onde gaña fixar

Fixar é a resposta correcta cando o descubrimento non pode funcionar: unha aplicación antiga que resolve un controlador por un nome que non podes cambiar, un filtro que permite exactamente un enderezo de controlador, ou un conxunto fixo de servidores no que o controlador forma parte do deseño da aplicación. Neses casos a fixación é documentación dunha restrición real, non un atallo.

O seu custo é o contrario da asignación. Un nome fixado non segue o pool, non conmuta por erro salvo que a aplicación saiba facelo, e non sobrevive a un cambio de nome nin á retirada dun controlador sen un repaso de inventario. Tamén agocha problemas de topoloxía, porque cada cliente que fixa parece san mentres o modelo de sitios podrece en silencio.

Substituír os rexistros de enderezo ordinarios do dominio por un único servidor preferido non é unha terceira opción. Rompe todo consumidor que espera o conxunto de descubrimento normal, e ademais non controla como un cliente consciente do directorio escolle un sitio.

Escolle con tres condicións

Pregúntaas nesta orde e a decisión adoita tomarse soa. Primeiro, usa a aplicación DC Locator, ou xa leva un enderezo de controlador? Segundo, ve o controlador o enderezo do pool ou un traducido? Terceiro, con que frecuencia cambia o pool comparado con cantos lugares habería que actualizar cunha fixación?

Aplicacións conscientes do directorio máis encamiñamento que conserva a orixe máis un pool que cambia: asigna a subrede. Unha aplicación que non pode descubrir, ou un filtro que admite un enderezo: fíxaa, e escribe por que. Todo o demais é un caso para arranxar a topoloxía en lugar de engadir outra anulación.

Verifica desde o cliente VPN e mantén os contratos separados

Proba desde o camiño remoto real, non desde unha estación de traballo LAN que xa está no sitio. Só conta a visión do propio cliente:

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

Se o sitio informado é o que asignaches, o obxecto coincide. Se o cliente non informa ningún sitio, o enderezo que presenta non cae dentro de ningún obxecto de subrede, o que adoita significar unha tradución ou un prefixo obsoleto. Despois comproba que o controlador elixido é o que pretendías antes de supoñer que a asignación fallou, porque os clientes cachéan os resultados de descubrimento e a conmutación por erro pode elixir lexitimamente outro controlador.

Mantén os tres contratos nun só documento: o pool e os seus obxectos de subrede, os controladores alcanzables desde o camiño VPN e a política que decide que pode facer un usuario autenticado. Un sitio non é unha regra de cortalumes nin unha fronteira de contención, e o próximo cambio de pool desconectará en silencio os usuarios remotos do modelo de rede do directorio salvo que a asignación, as rutas e as alternativas documentadas se movan xuntas.