Maparea sitului AD versus fixarea unui controler de domeniu pentru clienții VPN

Clienții de acces la distanță dintr-un pool VPN pot ajunge să vorbească cu un controler de domeniu de cealaltă parte a lumii, iar asta se remediază în două feluri: descrieți pool-ul ca o subrețea Active Directory legată de situl care are controlerele corecte, sau fixați clientul sau aplicația la un controler anume. Prima este o declarație de topologie pe care DC Locator poate acționa. A doua este o suprascriere pe aplicație care ignoră complet topologia. Costă lucruri diferite, iar grabarea celei mai rapide astăzi este exact felul în care o echipă de director ajunge să întrețină ambele.

Ce schimbă de fapt fiecare abordare

Un obiect de subrețea este o înregistrare din director care spune cărei locații îi aparține un interval de adrese. Cu modulul Active Directory și un sit existent, operația este destul de mică pentru a fi previzualizată:

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

-WhatIf previzualizează scrierea în director. Nu creează obiectul și nu testează dacă un client din acel interval poate ajunge la ceva, iar aceasta este exact partea pe care oamenii o așteaptă. DC Locator citește modelul siturilor când rezolvă înregistrările de serviciu, așa că un obiect de subrețea exact schimbă ce i se oferă clientului.

Fixarea funcționează la alt nivel. Un nume de controler fix în configurația unei aplicații, un șir LDAP cu un host în el sau o valoare de registry care numește un server preferat elimină toate descoperirea din cale. Aplicația vorbește cu acel controler până când cineva schimbă setarea, iar comutarea la eșec este ceea ce implementează aplicația însăși.

Unde câștigă maparea subrețelei

Maparea pool-ului descrie locația în rețea o dată, pentru fiecare client care folosește DC Locator. Când pool-ul crește de la o /24 la trei, modelul se schimbă în două sau trei obiecte în loc de un inventar de aplicații. Acesta este tot avantajul, și este mare când populația de clienți nu este sub controlul dumneavoastră.

Problema este că obiectul trebuie să corespundă adresei pe care controlerul o vede efectiv. Dacă gateway-ul VPN translatează fiecare client într-o adresă de hub, adăugarea pool-ului netranslat descrie o locație de rețea pe care niciun controler nu o observă vreodată. Decideți devreme dacă designul păstrează adresa sursă a clientului și, dacă nu, mapați intervalul translatat în locul pool-ului configurat pe serverul VPN.

O a doua limită: modelul siturilor este o preferință și o declarație de topologie. Nu face un controler accesibil și nu acordă nimic unui utilizator. Accesibilitatea o fac rutele și politica de firewall; autorizarea o face politica de conturi.

Unde câștigă fixarea

Fixarea este răspunsul corect când descoperirea nu poate funcționa: o aplicație veche care rezolvă un controler după un nume pe care nu îl puteți schimba, un filtru care permite exact o adresă de controler, sau un set fix de servere în care controlerul face parte din designul aplicației. În acele cazuri fixarea este documentarea unei constrângeri reale, nu o scurtătură.

Costul ei este opusul mapării. Un nume fixat nu urmează pool-ul, nu comută la eșec decât dacă aplicația știe cum, și nu supraviețuiește unei redenumiri sau scoateri din uz a unui controler fără o verificare a inventarului. Ascunde și problemele de topologie, pentru că fiecare client care fixează pare sănătos în timp ce modelul siturilor putrezește în liniște.

Înlocuirea înregistrărilor obișnuite de adresă ale domeniului cu un singur server preferat nu este o a treia opțiune. Rupe fiecare consumator care așteaptă setul normal de descoperire și tot nu controlează modul în care un client conștient de director alege un sit.

Alegeți după trei condiții

Întrebați-le în această ordine și decizia se ia de obicei singură. Întâi, aplicația folosește deloc DC Locator, sau poartă deja o adresă de controler? Al doilea, controlerul vede adresa pool-ului sau una translatată? Al treilea, cât de des se schimbă pool-ul comparativ cu câte locuri ar trebui actualizată o fixare?

Aplicații conștiente de director plus rutare care păstrează sursa plus un pool care se schimbă: mapați subrețeaua. O aplicație care nu poate descoperi, sau un filtru care admite o adresă: fixați-o și scrieți de ce. Orice altceva este un caz pentru repararea topologiei, nu pentru adăugarea unei alte suprascrieri.

Verificați din clientul VPN și țineți contractele separat

Testați din calea reală de la distanță, nu dintr-o stație de lucru LAN care stă deja în sit. Contează doar vederea clientului însuși:

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

Dacă situl raportat este cel pe care l-ați mapat, obiectul corespunde. Dacă clientul nu raportează niciun sit, adresa pe care o prezintă nu cade în niciun obiect de subrețea, ceea ce de obicei înseamnă o traducere sau un prefix învechit. Apoi verificați că controlerul ales este cel pe care l-ați intenționat înainte de a presupune că maparea a eșuat, pentru că clienții memorează rezultatele descoperirii, iar comutarea la eșec poate alege în mod legitim alt controler.

Țineți cele trei contracte într-un singur document: pool-ul și obiectele sale de subrețea, controlerele accesibile din calea VPN, și politica ce decide ce poate face un utilizator autentificat. Un sit nu este o regulă de firewall și nu este o graniță de izolare, iar următoarea schimbare a pool-ului va detașa în liniște utilizatorii de la distanță de modelul de rețea al directorului dacă maparea, rutele și alternativele documentate nu se mișcă împreună.