Mapeamento de site do AD contra fixar um controlador de domínio para clientes VPN

Clientes de acesso remoto num pool VPN podem acabar falando com um controlador de domínio do outro lado do mundo, e isso se corrige de duas maneiras: descrever o pool como uma sub-rede do Active Directory vinculada ao site que tem os controladores certos, ou fixar o cliente ou a aplicação a um controlador específico. A primeira é uma declaração de topologia sobre a qual o DC Locator pode agir. A segunda é uma substituição por aplicação que ignora a topologia por completo. Custam coisas diferentes, e recorrer hoje à mais rápida é exatamente como uma equipa de diretório acaba a manter as duas.

O que cada abordagem realmente muda

Um objeto de sub-rede é um registo do diretório que diz a que site pertence um intervalo de endereços. Com o módulo Active Directory e um site existente, a operação é suficientemente pequena para pré-visualizar:

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

-WhatIf pré-visualiza a escrita no diretório. Não cria o objeto e não testa se um cliente desse intervalo consegue alcançar algo, e é justamente essa a parte que as pessoas esperam. O DC Locator lê o modelo de sites quando resolve os registos de serviço, por isso um objeto de sub-rede exato muda o que é oferecido ao cliente.

A fixação funciona noutra camada. Um nome de controlador fixo na configuração de uma aplicação, uma cadeia LDAP com um host dentro, ou um valor de registo que nomeia um servidor preferido retiram toda a descoberta do caminho. A aplicação fala com esse controlador até alguém mudar a definição, e a comutação por falha é o que essa aplicação implementar.

Onde o mapeamento de sub-rede ganha

Mapear o pool descreve a localização de rede uma vez, para cada cliente que usa o DC Locator. Quando o pool cresce de uma /24 para três, o modelo muda em dois ou três objetos em vez de num inventário de aplicações. É toda a vantagem, e é grande quando a população de clientes não está sob o seu controlo.

O senão é que o objeto tem de corresponder ao endereço que o controlador vê de facto. Se o gateway VPN traduzir cada cliente para um endereço de concentrador, acrescentar o pool não traduzido descreve uma localização de rede que nenhum controlador observa jamais. Decida cedo se o desenho preserva o endereço de origem do cliente e, se não preservar, mapeie o intervalo traduzido em vez do pool configurado no servidor VPN.

Um segundo limite: o modelo de sites é uma preferência e uma declaração de topologia. Não torna um controlador alcançável nem concede nada a um utilizador. As rotas e a política de firewall fazem a alcançabilidade; a política de contas faz a autorização.

Onde a fixação ganha

A fixação é a resposta certa quando a descoberta não pode funcionar: uma aplicação antiga que resolve um controlador por um nome que não pode mudar, um filtro que permite exatamente um endereço de controlador, ou um conjunto fixo de servidores em que o controlador faz parte do desenho da aplicação. Nesses casos a fixação é documentação de uma restrição real, não um atalho.

O seu custo é o oposto do mapeamento. Um nome fixado não segue o pool, não comuta por falha a menos que a aplicação saiba como, e não sobrevive a uma mudança de nome ou desativação de controlador sem uma revisão de inventário. Também esconde problemas de topologia, porque cada cliente que fixa parece saudável enquanto o modelo de sites apodrece em silêncio.

Substituir os registos de endereço normais do domínio por um único servidor preferido não é uma terceira opção. Quebra todos os consumidores que esperam o conjunto de descoberta normal, e continua a não controlar como um cliente ciente do diretório escolhe um site.

Escolha com três condições

Pergunte-as nesta ordem e a decisão costuma tomar-se sozinha. Primeiro, a aplicação usa o DC Locator de todo, ou já transporta um endereço de controlador? Segundo, o controlador vê o endereço do pool, ou um traduzido? Terceiro, com que frequência o pool muda em comparação com quantos lugares uma fixação teria de ser atualizada?

Aplicações cientes do diretório mais encaminhamento que preserva a origem mais um pool que muda: mapeie a sub-rede. Uma aplicação que não consegue descobrir, ou um filtro que admite um endereço: fixe-a, e escreva porquê. Tudo o resto é um caso para corrigir a topologia em vez de acrescentar outra substituição.

Verifique a partir do cliente VPN e mantenha os contratos separados

Teste a partir do caminho remoto real, não de uma estação de trabalho LAN que já está no site. Só conta a visão do próprio cliente:

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

Se o site reportado for o que mapeou, o objeto corresponde. Se o cliente não reportar site nenhum, o endereço que apresenta não cai dentro de qualquer objeto de sub-rede, o que normalmente significa uma tradução ou um prefixo desatualizado. Depois verifique que o controlador escolhido é o que pretendia antes de assumir que o mapeamento falhou, porque os clientes colocam os resultados de descoberta em cache e a comutação por falha pode legitimamente escolher outro controlador.

Mantenha os três contratos num único documento: o pool e os seus objetos de sub-rede, os controladores alcançáveis a partir do caminho VPN, e a política que decide o que um utilizador autenticado pode fazer. Um site não é uma regra de firewall nem uma fronteira de contenção, e a próxima mudança do pool vai desligar em silêncio os utilizadores remotos do modelo de rede do diretório, a menos que o mapeamento, as rotas e as alternativas documentadas se movam juntos.