AD-stadskartlegging kontra å feste ein domenekontrollør for VPN-klientar

Fjernåtkomstklientar på eit VPN-utval kan enda med å snakke med ein domenekontrollør på den andre sida av verda, og det kan rettast på to måtar: skildre utvalet som eit Active Directory-subnett knytt til staden som har dei rette kontrollørane, eller feste klienten eller applikasjonen til éin bestemd kontrollør. Den fyrste er ei topologifråsegn som DC Locator kan handle på. Den andre er ei overstyring per applikasjon som ignorerer topologien heilt. Dei kostar ulike ting, og å gripe etter den snøggaste i dag er nettopp korleis eit katalogteam endar med å vedlikehalde båe.

Kva kvar tilnærming faktisk endrar

Eit subnettobjekt er ein katalogoppføring som seier kva stad eit adresseområde høyrer til. Med Active Directory-modulen og ein stad som finst frå før er operasjonen liten nok til å førehandsvisast:

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

-WhatIf førehandsvisar skrivinga til katalogen. Det opprettar ikkje objektet og testar ikkje om ein klient i det området kan nå noko, og det er nettopp den delen folk ventar. DC Locator les stadmodellen når han løyser opp tenesteoppføringar, så eit nøyaktig subnettobjekt endrar kva klienten vert tilboden.

Festing verkar i eit anna lag. Eit fast kontrollørnamn i ein applikasjonskonfigurasjon, ein LDAP-streng med ein vert i, eller ein registerverdi som nemner ein føretrekt tenar, fjernar alle oppdaginga frå vegen. Applikasjonen snakkar med den kontrolløren til nokon endrar innstillinga, og failover er det applikasjonen sjølv implementerer.

Kor subnettkartlegging vinn

Å kartleggje utvalet skildrar nettverksplasseringa éin gong, for kvar klient som brukar DC Locator. Når utvalet veks frå eitt /24 til tre, endrar modellen seg i to eller tre objekt i staden for i ei applikasjonsliste. Det er heile fordelen, og han er stor når klientmassen ikkje er under din kontroll.

Haka er at objektet må svare til adressa kontrolløren faktisk ser. Viss VPN-gatewayen omset kvar klient til ei hubadresse, skildrar det å leggje til det uomsette utvalet ein nettverksplassering som ingen kontrollør nokon gong observerer. Avgjer tidleg om designet bevarar kjeldeadressa til klienten, og viss ikkje, kartlegg det omsette området i staden for utvalet du konfigurerte på VPN-tenaren.

Ei anna grense: stadmodellen er ei preferanse og ei topologifråsegn. Han gjer ikkje ein kontrollør tilgjengeleg og gjev ikkje ein brukar noko. Ruter og brannmurpolitikk gjev tilgjengelegheiten; kontopolitikk gjev autorisasjonen.

Kor festing vinn

Festing er det rette svaret når oppdaging ikkje kan verke: ein gamal applikasjon som løyser opp ein kontrollør via eit namn du ikkje kan endre, eit filter som tillèt nøyaktig éi kontrolløradresse, eller eit fast sett tenarar der kontrolløren er ein del av applikasjonsdesignet. I dei tilfella er festinga dokumentasjon av ei reell avgrensing, ikkje ein snøggveg.

Prisen er det motsette av kartlegging. Eit festa namn følgjer ikkje utvalet, vekslar ikkje ved feil med mindre applikasjonen veit korleis, og overlever ikkje at ein kontrollør får nytt namn eller vert avvikla utan ein gjennomgang av oversikta. Det løyner òg topologiproblem, fordi kvar klient som festar ser sunn ut medan stadmodellen stille råtna.

Å byte ut dei vanlege adresseoppføringane til domenet med éin føretrekt tenar er ikkje eit tredje alternativ. Det bryt kvar forbrukar som ventar det normale oppdagingssettet, og det styrer framleis ikkje korleis ein katalogmedveten klient vel ein stad.

Vel etter tre vilkår

Spør i denne rekkjefølgja, og avgjerda tek seg som regel sjølv. Fyrst, brukar applikasjonen DC Locator i det heile, eller ber han alt ei kontrolløradresse? Dernest, ser kontrolløren adressa til utvalet, eller ei omsett? Til sist, kor ofte endrar utvalet seg samanlikna med kor mange stader ei festing måtte oppdaterast?

Katalogmedvetne applikasjonar pluss kjeldebevarande ruting pluss eit utval som endrar seg: kartlegg subnettet. Ein applikasjon som ikkje kan oppdage, eller eit filter som slepp inn éi adresse: fest han, og skriv ned kvifor. Alt anna er ei sak for å rette topologien i staden for å leggje til endå ei overstyring.

Stadfest frå VPN-klienten og hald kontraktane åtskilde

Test frå den faktiske fjernvegen, ikkje frå ein LAN-arbeidsstasjon som alt sit på staden. Berre synet til klienten sjølv tel:

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

Er staden som vert rapportert den du kartla, stemmer objektet. Rapporterer klienten ingen stad, fell adressa han legg fram utanfor kvart subnettobjekt, noko som vanlegvis tyder på ei omsetjing eller eit utdatert prefiks. Kontroller deretter at den valde kontrolløren er den du hadde tenkt, før du reknar med at kartlegginga feila, fordi klientar bufrer oppdagingsresultat, og failover kan lovleg velje ein annan kontrollør.

Hald dei tre kontraktane i eitt dokument: utvalet og subnettobjekta, kontrollørane som er tilgjengelege frå VPN-vegen, og politikken som avgjer kva ein innlogga brukar får gjere. Ein stad er ikkje ei brannmurregel og ikkje ei isolasjonsgrense, og den neste endringa i utvalet vil stille kople fjernbrukarar frå nettverksmodellen til katalogen med mindre kartlegginga, rutene og dei dokumenterte alternativa flyttar seg saman.