Harta e faqes AD kundër fiksimit të një kontrolluesi domeni për klientët VPN

Klientët e aksesit në distancë në një pishinë VPN mund të përfundojnë duke folur me një kontrollues domeni në anën tjetër të botës, dhe kjo rregullohet në dy mënyra: përshkruaj pishinën si një nënrrjet Active Directory të lidhur me faqen që mban kontrolluesit e duhur, ose fikso klientin ose aplikacionin në një kontrollues të caktuar. E para është një deklaratë topologjie mbi të cilën DC Locator mund të veprojë. E dyta është një anulim për çdo aplikacion që e shpërfill topologjinë plotësisht. Kushtojnë gjëra të ndryshme, dhe kapja e më të shpejtës sot është pikërisht mënyra se si një ekip drejtorie përfundon duke mirëmbajtur të dyja.

Çfarë ndryshon vërtet secila qasje

Objekti i nënrrjetit është një regjistrim në drejtori që thotë se cilës faqe i përket një interval adresash. Me modulin Active Directory dhe një faqe ekzistuese, operacioni është mjaft i vogël për t u parapa:

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

-WhatIf parashikon shkrimin në drejtori. Nuk e krijon objektin dhe nuk teston nëse një klient në atë interval mund të arrijë ndonjë gjë, dhe pikërisht kjo është pjesa që njerëzit presin. DC Locator lexon modelin e faqeve kur zgjidh regjistrimet e shërbimit, prandaj një objekt i saktë nënrrjeti ndryshon atë që i ofrohet klientit.

Fiksimi punon në një shtresë tjetër. Një emër i palëvizshëm kontrolluesi në konfigurimin e aplikacionit, një varg LDAP me një host brenda, ose një vlerë regjistri që emërton një server të preferuar, të gjitha e heqin zbulimin nga rruga. Aplikacioni flet me atë kontrollues derisa dikush ta ndryshojë cilësimin, dhe kalimi në rast dështimi është ajo që zbaton vetë aplikacioni.

Ku fiton hartimi i nënrrjetit

Hartimi i pishinës përshkruan vendndodhjen e rrjetit një herë, për çdo klient që përdor DC Locator. Kur pishina rritet nga një /24 në tre, modeli ndryshon në dy ose tre objekte në vend të një inventari aplikacionesh. Ky është i gjithë avantazhi, dhe është i madh kur popullsia e klientëve nuk është nën kontrollin tuaj.

Gracka është se objekti duhet të përputhet me adresën që kontrolluesi sheh vërtet. Nëse porta VPN e përkthen çdo klient në një adresë hub, shtimi i pishinës së papërkthyer përshkruan një vendndodhje rrjeti që asnjë kontrollues nuk e vëzhgon kurrë. Vendosni herët nëse dizajni e ruan adresën burimore të klientit, dhe nëse jo, hartoni intervalin e përkthyer në vend të pishinës që konfiguruat në serverin VPN.

Një kufi i dytë: modeli i faqeve është një preferencë dhe një deklaratë topologjie. Nuk e bën një kontrollues të arritshëm dhe nuk i jep asgjë një përdoruesi. Arritshmërinë e bëjnë rrugët dhe politika e murit të zjarrit; autorizimin e bën politika e llogarive.

Ku fiton fiksimi

Fiksimi është përgjigja e duhur kur zbulimi nuk mund të punojë: një aplikacion i vjetër që zgjidh një kontrollues me një emër që nuk mund ta ndryshoni, një filtër që lejon saktësisht një adresë kontrolluesi, ose një grup i fiksuar serverësh ku kontrolluesi është pjesë e dizajnit të aplikacionit. Në ato raste fiksimi është dokumentim i një kufizimi real, jo shkurtore.

Kostoja e tij është e kundërta e hartimit. Një emër i fiksuar nuk ndjek pishinën, nuk kalon në rast dështimi përveçse aplikacioni e di si, dhe nuk i mbijeton riemërtimit ose heqjes nga shërbimi të një kontrolluesi pa një rishikim inventari. Ai gjithashtu fsheh problemet e topologjisë, sepse çdo klient që fikson duket i shëndetshëm ndërsa modeli i faqeve kalbet në heshtje.

Zëvendësimi i regjistrimeve të zakonshme të adresave të domenit me një server të vetëm të preferuar nuk është një opsion i tretë. Ai thyen çdo konsumator që pret grupin normal të zbulimit, dhe prapë nuk kontrollon se si një klient i vetëdijshëm për drejtorinë zgjedh një faqe.

Zgjidh sipas tre kushteve

Pyeti në këtë rend dhe vendimi zakonisht merret vetë. Së pari, a përdor aplikacioni fare DC Locator, ose tashmë mban një adresë kontrolluesi? Së dyti, a e sheh kontrolluesi adresën e pishinës, apo një të përkthyer? Së treti, sa shpesh ndryshon pishina krahasuar me sa vende do të duhej të përditësohej një fiksim?

Aplikacione të vetëdijshme për drejtorinë plus ushtim që ruan burimin plus një pishinë që ndryshon: harto nënrrjetin. Një aplikacion që nuk mund të zbulojë, ose një filtër që pranon një adresë: fiksoje, dhe shkruaj pse. Gjithçka tjetër është një rast për të rregulluar topologjinë, jo për të shtuar një anulim tjetër.

Verifiko nga klienti VPN dhe mbaj kontratat të ndara

Testo nga rruga reale e largët, jo nga një stacion pune LAN që tashmë ndodhet në faqe. Vetëm pamja e vetë klientit ka rëndësi:

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

Nëse faqja e raportuar është ajo që hartuat, objekti përputhet. Nëse klienti nuk raporton asnjë faqe, adresa që paraqet nuk bie brenda asnjë objekti nënrrjeti, që zakonisht do të thotë një përkthim ose një prefiks i vjetëruar. Pastaj verifiko që kontrolluesi i zgjedhur është ai që kishit ndërmend përpara se të supozoni se hartimi dështoi, sepse klientët ruajnë rezultatet e zbulimit në cache dhe kalimi në rast dështimi mund të zgjedhë ligjërisht një kontrollues tjetër.

Mbaj tri kontratat në një dokument: pishinën dhe objektet e saj të nënrrjetit, kontrolluesit e arritshëm nga rruga VPN, dhe politikën që vendos çfarë mund të bëjë një përdorues i identifikuar. Një faqe nuk është rregull muri zjarri dhe nuk është kufi përmbajtjeje, dhe ndryshimi i ardhshëm i pishinës do t i shkëpusë në heshtje përdoruesit e largët nga modeli i rrjetit të drejtorisë nëse hartimi, rrugët dhe alternativat e dokumentuara nuk lëvizin bashkë.