AD-stedsmapping kontra fastgørelse af en domænecontroller til VPN-klienter

Fjernadgangsklienter på en VPN-pulje kan ende med at tale med en domænecontroller på den anden side af kloden, og det kan rettes på to måder: beskriv puljen som et Active Directory-undernet knyttet til det sted, der har de rigtige controllere, eller fastgør klienten eller applikationen til én bestemt controller. Den første er en topologierklæring, som DC Locator kan handle på. Den anden er en tilsidesættelse pr. applikation, der ignorerer topologien helt. De koster forskellige ting, og at gribe efter den hurtigste i dag er netop, hvordan et katalogteam ender med at vedligeholde begge.

Hvad hver tilgang reelt ændrer

Et undernetsobjekt er en katalogpost, der siger, hvilket sted et adresseområde hører til. Med Active Directory-modulet og et eksisterende sted er operationen lille nok til at blive forhåndsvist:

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

-WhatIf forhåndsviser skrivningen til kataloget. Det opretter ikke objektet og tester ikke, om en klient i det område kan nå noget, og det er netop den del, folk forventer. DC Locator læser stedsmodellen, når den opløser serviceposter, så et præcist undernetsobjekt ændrer, hvad klienten tilbydes.

Fastgørelse virker i et andet lag. Et fast controller-navn i en applikationskonfiguration, en LDAP-streng med en vært i eller en registreringsværdi, der navngiver en foretrukken server, fjerner alle opdagelsen fra vejen. Applikationen taler med den controller, indtil nogen ændrer indstillingen, og failover er, hvad den applikation selv implementerer.

Hvor undernetsmapping vinder

At mappe puljen beskriver netværksplacering én gang for hver klient, der bruger DC Locator. Når puljen vokser fra et /24 til tre, ændres modellen i to eller tre objekter i stedet for i en applikationsliste. Det er hele fordelen, og den er stor, når klientbestanden ikke er under din kontrol.

Hagen er, at objektet skal matche den adresse, controlleren faktisk ser. Hvis VPN-gatewayen oversætter hver klient til en hub-adresse, beskriver tilføjelsen af den uoversatte pulje en netværksplacering, som ingen controller nogensinde ser. Beslut tidligt, om designet bevarer klientens kildeadresse, og hvis ikke, skal du mappe det oversatte område i stedet for den pulje, du konfigurerede på VPN-serveren.

En anden grænse: stedsmodellen er en præference og en topologierklæring. Den gør ikke en controller tilgængelig og giver ikke en bruger noget. Ruter og firewallpolitik giver tilgængeligheden; kontopolitik giver autorisationen.

Hvor fastgørelse vinder

Fastgørelse er det rigtige svar, når opdagelse ikke kan virke: en gammel applikation, der opløser en controller via et navn, du ikke kan ændre, et filter, der tillader præcis én controlleradresse, eller et fast sæt servere, hvor controlleren er en del af applikationsdesignet. I de tilfælde er fastgørelsen dokumentation af en reel begrænsning frem for en genvej.

Dens pris er det modsatte af mapping. Et fastgjort navn følger ikke puljen, skifter ikke ved fejl, medmindre applikationen ved hvordan, og overlever ikke en omdøbning eller nedlæggelse af en controller uden en gennemgang af oversigten. Den skjuler også topologiproblemer, fordi hver klient, der fastgøres, ser sund ud, mens stedsmodellen stille rådner.

At erstatte domænets almindelige adresseposter med én foretrukken server er ikke en tredje mulighed. Det bryder enhver forbruger, der forventer det normale opdagelsessæt, og det styrer stadig ikke, hvordan en katalogbevidst klient vælger et sted.

Vælg ud fra tre betingelser

Stil dem i denne rækkefølge, og beslutningen træffer som regel sig selv. For det første, bruger applikationen DC Locator overhovedet, eller bærer den allerede en controlleradresse? For det andet, ser controlleren puljens adresse eller en oversat? For det tredje, hvor ofte ændrer puljen sig sammenlignet med, hvor mange steder en fastgørelse skulle opdateres?

Katalogbevidste applikationer plus kildebevarende routing plus en pulje, der ændrer sig: map undernettet. En applikation, der ikke kan opdage, eller et filter, der tillader én adresse: fastgør den, og skriv hvorfor. Alt andet er en sag for at rette topologien frem for at tilføje endnu en tilsidesættelse.

Verificer fra VPN-klienten og hold kontrakterne adskilt

Test fra den faktiske fjernvej, ikke fra en LAN-arbejdsstation, der allerede sidder på stedet. Klientens eget syn er det eneste, der tæller:

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

Er det rapporterede sted det, du mappede, stemmer objektet. Rapporterer klienten intet sted, falder den adresse, den fremlægger, ikke inden for noget undernetsobjekt, hvilket normalt betyder en oversættelse eller et forældet præfiks. Kontroller derefter, at den valgte controller er den, du havde tænkt på, før du antager, at mappingen fejlede, fordi klienter cacher opdagelsesresultater, og failover kan med rette vælge en anden controller.

Hold de tre kontrakter i ét dokument: puljen og dens undernetsobjekter, de controllere, der kan nås fra VPN-vejen, og den politik, der afgør, hvad en logget ind bruger må gøre. Et sted er ikke en firewallregel og ikke en isolationsgrænse, og den næste ændring af puljen vil stille koble fjernbrugere fra katalogets netværksmodel, medmindre mappingen, ruterne og de dokumenterede alternativer flytter sig sammen.