Assignació de lloc d AD enfront de fixar un controlador de domini per als clients VPN

Els clients d’accés remot en un pool VPN poden acabar parlant amb un controlador de domini a l’altre costat del món, i hi ha dues maneres d’arreglar-ho: descriure el pool com una subxarxa d Active Directory lligada al lloc que té els controladors correctes, o fixar el client o l’aplicació a un controlador concret. La primera és una declaració de topologia sobre la qual DC Locator pot actuar. La segona és una anul·lació per aplicació que ignora la topologia del tot. Costen coses diferents, i abraçar avui la més ràpida és com un equip de directori acaba mantenint les dues.

Què canvia realment cada enfocament

Un objecte de subxarxa és un registre del directori que diu a quin lloc pertany un rang d’adreces. Amb el mòdul d Active Directory i un lloc existent, l’operació és prou petita per previsualitzar-la:

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

-WhatIf previsualitza l’escriptura al directori. No crea l’objecte ni comprova si un client d’aquell rang pot arribar a res, que és justament la part que la gent espera. DC Locator llegeix el model de llocs quan resol els registres de servei, així que un objecte de subxarxa precís canvia què se li ofereix al client.

Fixar funciona en una altra capa. Un nom de controlador fix a la configuració d’una aplicació, una cadena LDAP amb un amfitrió a dins o un valor de registre que anomena un servidor preferit treuen el descobriment del camí. L aplicació parla amb aquell controlador fins que algú canvia el paràmetre, i la commutació per error és el que implementi aquella aplicació.

On guanya l’assignació de subxarxa

Assignar el pool descriu la ubicació de xarxa una vegada, per a cada client que fa servir DC Locator. Quan el pool creix d’una /24 a tres, el model canvia en dos o tres objectes en lloc d’en un inventari d’aplicacions. Aquest és tot l’avantatge, i és gran quan la població de clients no està sota el teu control.

La trampa és que l’objecte ha de coincidir amb l’adreça que el controlador veu realment. Si la passarel·la VPN tradueix cada client a una adreça de concentrador, afegir el pool no traduït descriu una ubicació de xarxa que cap controlador no observa mai. Decideix aviat si el disseny conserva l’adreça d’origen del client, i si no ho fa, assigna el rang traduït en lloc del pool que vas configurar al servidor VPN.

Un segon límit: el model de llocs és una preferència i una declaració de topologia. No fa que un controlador sigui accessible ni atorga res a cap usuari. Les rutes i la política de tallafocs fan l’accessibilitat; la política de comptes fa l’autorització.

On guanya fixar

Fixar és la resposta correcta quan el descobriment no pot funcionar: una aplicació antiga que resol un controlador per un nom que no pots canviar, un filtre que permet exactament una adreça de controlador, o un conjunt fix de servidors on el controlador forma part del disseny de l’aplicació. En aquests casos la fixació és documentació d’una restricció real, no un drecera.

El seu cost és el contrari de l’assignació. Un nom fixat no segueix el pool, no commuta per error tret que l’aplicació sàpiga com fer-ho, i no sobreviu a un canvi de nom o a una retirada d’un controlador sense una revisió d’inventari. També amaga problemes de topologia, perquè cada client que fixa sembla sa mentre el model de llocs es podreix en silenci.

Substituir els registres d’adreces ordinaris del domini per un sol servidor preferit no és una tercera opció. Trenca tots els consumidors que esperen el conjunt de descobriment normal, i encara no controla com un client conscient del directori tria un lloc.

Tria amb tres condicions

Pregunta-les en aquest ordre i la decisió sol prendre es tota sola. Primer, l’aplicació fa servir DC Locator o ja porta una adreça de controlador? Segon, el controlador veu l’adreça del pool o una de traduïda? Tercer, quant sovint canvia el pool en comparació amb quantes ubicacions caldria actualitzar amb una fixació?

Aplicacions conscients del directori més encaminament que conserva l’origen més un pool que canvia: assigna la subxarxa. Una aplicació que no pot descobrir, o un filtre que admet una adreça: fixa-la, i escriu per què. Tota la resta és un cas per arreglar la topologia en lloc d’afegir una altra anul·lació.

Verifica des del client VPN i manté els contractes separats

Prova des del camí remot real, no des d’una estació de treball LAN que ja és al lloc. Només compta la visió del propi client:

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

Si el lloc informat és el que has assignat, l’objecte coincideix. Si el client no informa cap lloc, l’adreça que presenta no cau dins de cap objecte de subxarxa, cosa que normalment vol dir una traducció o un prefix obsolet. Després comprova que el controlador triat és el que volies abans de suposar que l’assignació ha fallat, perquè els clients fan memòria cau dels resultats de descobriment i la commutació per error pot triar legítimament un altre controlador.

Manté els tres contractes en un sol document: el pool i els seus objectes de subxarxa, els controladors accessibles des del camí VPN, i la política que decideix què pot fer un usuari autenticat. Un lloc no és una regla de tallafocs ni una frontera de contenció, i el proper canvi de pool desconnectarà en silenci els usuaris remots del model de xarxa del directori tret que l’assignació, les rutes i les alternatives documentades es moguin juntes.