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

Klienter for ekstern tilgang i en VPN-pulje kan ende opp med å snakke med en domenekontroller på den andre siden av kloden, og det lar seg rette på to vis: beskrive puljen som et Active Directory-subnett knyttet til stedet som huser de riktige kontrollerne, eller feste klienten eller applikasjonen til én bestemt kontroller. Det første er en topologierklæring som DC Locator kan forholde seg til. Det andre er en tilsidesettelse per applikasjon som ser helt bort fra topologien. De koster ulike ting, og å gripe etter den raskeste i dag er nettopp måten et katalogteam til slutt vedlikeholder begge.

Hva hver tilnærming egentlig endrer

Et subnettobjekt er en katalogoppføring som sier hvilket sted et adresseområde hører til. 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. Det oppretter ikke objektet og tester ikke om en klient i det området kan nå noe som helst, og det er nettopp den delen folk forventer. DC Locator leser stedsmodellen når den slår opp tjenesteposter, så et presist subnettobjekt endrer hva klienten blir tilbudt.

Festing virker i et annet lag. Et fast kontrollernavn i en applikasjonskonfigurasjon, en LDAP-streng med en vert inni, eller en registerverdi som navngir en foretrukket tjener, fjerner all oppdagelse fra veien. Applikasjonen snakker med den kontrolleren til noen endrer innstillingen, og failover er det applikasjonen selv legger til rette for.

Hvor subnettkartlegging vinner

Å kartlegge puljen beskriver nettverksplasseringen én gang, for hver klient som bruker DC Locator. Når puljen vokser fra ett /24 til tre, endres modellen i to eller tre objekter i stedet for i en applikasjonsoversikt. 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. Dersom VPN-gatewayen oversetter hver klient til en hubadresse, beskriver det å legge til den uoversatte puljen en nettverksplassering som ingen kontroller noen gang observerer. Bestem tidlig om designet bevarer kildeadressen til klienten, og hvis ikke, kartlegg det oversatte området i stedet for puljen du satte opp på VPN-tjeneren.

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

Hvor festing vinner

Festing er det riktige svaret når oppdagelse ikke kan fungere: en eldre applikasjon som slår opp en kontroller via et navn du ikke kan endre, et filter som tillater nøyaktig én kontrolleradresse, eller et fast sett tjenere 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 puljen, 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 forfaller.

Å erstatte domenets vanlige adresseposter med én foretrukket tjener 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 puljeadressen, eller en oversatt en? For det tredje: hvor ofte endres puljen sammenlignet med hvor mange steder en festing måtte oppdateres?

Katalogbevisste applikasjoner pluss kildebevarende ruting pluss en pulje 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 tilsidesettelse.

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 steder, faller adressen den presenterer utenfor 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: puljen og subnettobjektene, kontrollerne som er tilgjengelige fra VPN-veien, og politikken som avgjør hva en innlogget bruker får lov til. Et sted er ikke en brannmurregel og ikke en isolasjonsgrense, og den neste endringen i puljen vil stille koble fjernbrukere fra nettverksmodellen til katalogen med mindre kartleggingen, rutene og de dokumenterte alternativene beveger seg sammen.