AD-stedskartlegging kontra å feste en domenekontroller for VPN-klienter

Fjernadgangsklienter på et VPN-utvalg kan ende med å snakke med en domenekontroller på den andre siden av verden, og det kan rettes på to måter: beskriv utvalget som et Active Directory-subnett knyttet til stedet som har de riktige kontrollerne, eller fest klienten eller applikasjonen til én bestemt kontroller. Den første er en topologierklæring som DC Locator kan handle på. Den andre er en overstyring per applikasjon som ignorerer topologien helt. De koster forskjellige ting, og å gripe etter den raskeste i dag er nettopp hvordan et katalogteam ender med å vedlikeholde begge.

Hva hver tilnærming faktisk endrer

Et subnettobjekt er en katalogoppføring som sier hvilket sted et adresseområde tilhører. Med Active Directory-modulen og et eksisterende sted er operasjonen liten nok til å forhåndsvises:

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

-WhatIf forhåndsviser skrivingen til katalogen. Den oppretter ikke objektet og tester ikke om en klient i det området kan nå noe, og det er nettopp den delen folk forventer. DC Locator leser stedsmodellen når den løser opp tjenesteoppføringer, så et nøyaktig subnettobjekt endrer hva klienten tilbys.

Festing virker i et annet lag. Et fast kontrollernavn i en applikasjonskonfigurasjon, en LDAP-streng med en vert i, eller en registerverdi som navngir en foretrukket server, fjerner alle oppdagelsen fra veien. Applikasjonen snakker med den kontrolleren til noen endrer innstillingen, og failover er det den applikasjonen selv implementerer.

Hvor subnettkartlegging vinner

Å kartlegge utvalget beskriver nettverksplasseringen én gang, for hver klient som bruker DC Locator. Når utvalget vokser fra ett /24 til tre, endres modellen i to eller tre objekter i stedet for i en applikasjonsliste. Det er hele fordelen, og den er stor når klientmassen ikke er under din kontroll.

Haken er at objektet må samsvare med adressen kontrolleren faktisk ser. Hvis VPN-gatewayen oversetter hver klient til en hubadresse, beskriver det å legge til det uoversatte utvalget en nettverksplassering som ingen kontroller noen gang observerer. Bestem tidlig om designet bevarer klientens kildeadresse, og hvis ikke, kartlegg det oversatte området i stedet for utvalget du konfigurerte på VPN-serveren.

En annen grense: stedsmodellen er en preferanse og en topologierklæring. Den gjør ikke en kontroller tilgjengelig og gir ikke en bruker noe. Ruter og brannmurpolitikk gir tilgjengeligheten; kontopolitikk gir autorisasjonen.

Hvor festing vinner

Festing er det riktige svaret når oppdagelse ikke kan virke: en gammel applikasjon som løser opp en kontroller via et navn du ikke kan endre, et filter som tillater nøyaktig én kontrolleradresse, eller et fast sett med servere der kontrolleren er en del av applikasjonsdesignet. I de tilfellene er festingen dokumentasjon av en reell begrensning, ikke en snarvei.

Prisen er det motsatte av kartlegging. Et festet navn følger ikke utvalget, veksler ikke ved feil med mindre applikasjonen vet hvordan, og overlever ikke at en kontroller får nytt navn eller avvikles uten en gjennomgang av oversikten. Det skjuler også topologiproblemer, fordi hver klient som festes ser sunn ut mens stedsmodellen stille råtner.

Å erstatte domenets vanlige adresseoppføringer med én foretrukket server er ikke et tredje alternativ. Det bryter hver forbruker som forventer det normale oppdagelsessettet, og det styrer fortsatt ikke hvordan en katalogbevisst klient velger et sted.

Velg etter tre betingelser

Spør i denne rekkefølgen, og avgjørelsen tar seg som regel selv. For det første, bruker applikasjonen DC Locator i det hele tatt, eller bærer den allerede en kontrolleradresse? For det andre, ser kontrolleren utvalgets adresse, eller en oversatt? For det tredje, hvor ofte endres utvalget sammenlignet med hvor mange steder en festing måtte oppdateres?

Katalogbevisste applikasjoner pluss kildebevarende ruting pluss et utvalg som endres: kartlegg subnettet. En applikasjon som ikke kan oppdage, eller et filter som slipper inn én adresse: fest den, og skriv ned hvorfor. Alt annet er en sak for å rette topologien i stedet for å legge til nok en overstyring.

Verifiser fra VPN-klienten og hold kontraktene atskilt

Test fra den faktiske fjernveien, ikke fra en LAN-arbeidsstasjon som allerede sitter på stedet. Bare klientens eget syn teller:

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

Er stedet som rapporteres det du kartla, stemmer objektet. Rapporterer klienten ingen sted, faller adressen den presenterer ikke innenfor noe subnettobjekt, noe som vanligvis betyr en oversettelse eller et utdatert prefiks. Kontroller deretter at den valgte kontrolleren er den du hadde tenkt, før du antar at kartleggingen feilet, fordi klienter bufrer oppdagelsesresultater, og failover kan lovlig velge en annen kontroller.

Hold de tre kontraktene i ett dokument: utvalget og subnettobjektene, kontrollerne som er tilgjengelige fra VPN-veien, og politikken som avgjør hva en innlogget bruker får gjøre. Et sted er ikke en brannmurregel og ikke en isolasjonsgrense, og den neste endringen i utvalget vil stille koble fjernbrukere fra katalogens nettverksmodell med mindre kartleggingen, rutene og de dokumenterte alternativene beveger seg sammen.