AD-sitetoewijzing versus het vastpinnen van een domeincontroller voor VPN-clients

Clients voor externe toegang op een VPN-pool kunnen uiteindelijk praten met een domeincontroller aan de andere kant van de wereld, en dat is op twee manieren te verhelpen: beschrijf de pool als een Active Directory-subnet dat aan de site met de juiste controllers is gekoppeld, of pin de client of toepassing vast aan één specifieke controller. Het eerste is een topologieverklaring waarop DC Locator kan handelen. Het tweede is een overschrijving per toepassing die de topologie volledig negeert. Ze kosten verschillende dingen, en vandaag naar de snelste grijpen is precies hoe een directoryteam uiteindelijk beide onderhoudt.

Wat elke aanpak werkelijk verandert

Een subnetobject is een directoryrecord dat zegt bij welke site een adresbereik hoort. Met de Active Directory-module en een bestaande site is de bewerking klein genoeg om vooraf te bekijken:

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

-WhatIf bekijkt de schrijfactie in de directory vooraf. Het maakt het object niet aan en test niet of een client in dat bereik ergens bij kan, en dat is juist het deel dat mensen verwachten. DC Locator leest het sitemodel wanneer het servicerecords omzet, dus een nauwkeurig subnetobject verandert wat de client wordt aangeboden.

Vastpinnen werkt op een andere laag. Een vaste controllernaam in een toepassingsconfiguratie, een LDAP-string met een host erin, of een registerwaarde die een voorkeursserver noemt, halen allemaal de ontdekking uit het pad. De toepassing praat met die controller tot iemand de instelling wijzigt, en failover is wat die toepassing zelf implementeert.

Waar subnettoewijzing wint

De pool toewijzen beschrijft de netwerklocatie één keer, voor elke client die DC Locator gebruikt. Groeit de pool van één /24 naar drie, dan verandert het model in twee of drie objecten in plaats van in een toepassingslijst. Dat is het hele voordeel, en het is groot wanneer de clientpopulatie niet onder uw controle is.

De valkuil is dat het object moet passen bij het adres dat de controller werkelijk ziet. Als de VPN-gateway elke client vertaalt naar een hubadres, beschrijft het toevoegen van de onvertaalde pool een netwerklocatie die geen enkele controller ooit waarneemt. Beslis vroeg of het ontwerp het bronadres van de client behoudt, en zo niet, wijs dan het vertaalde bereik toe in plaats van de pool die u op de VPN-server hebt geconfigureerd.

Een tweede grens: het sitemodel is een voorkeur en een topologieverklaring. Het maakt een controller niet bereikbaar en geeft een gebruiker niets. Routes en firewallbeleid zorgen voor bereikbaarheid; accountbeleid zorgt voor autorisatie.

Waar vastpinnen wint

Vastpinnen is het juiste antwoord wanneer ontdekking niet kan werken: een oude toepassing die een controller omzet via een naam die u niet kunt wijzigen, een filter dat precies één controlleradres toestaat, of een vaste set servers waarin de controller deel uitmaakt van het toepassingsontwerp. In die gevallen is de pin documentatie van een echte beperking, geen snelkoppeling.

De prijs is het omgekeerde van toewijzen. Een vastgepinde naam volgt de pool niet, schakelt niet om bij een storing tenzij de toepassing weet hoe, en overleeft het hernoemen of uit bedrijf nemen van een controller niet zonder inventariscontrole. Het verbergt ook topologieproblemen, want elke client die vastpint ziet er gezond uit terwijl het sitemodel stil wegrot.

De gewone adresrecords van het domein vervangen door één voorkeursserver is geen derde optie. Het breekt elke afnemer die de normale ontdekkingsset verwacht, en het beheerst nog steeds niet hoe een directorybewuste client een site kiest.

Kies op drie voorwaarden

Stel ze in deze volgorde en de beslissing neemt zichzelf meestal. Ten eerste, gebruikt de toepassing DC Locator überhaupt, of draagt zij al een controlleradres? Ten tweede, ziet de controller het pooladres, of een vertaald adres? Ten derde, hoe vaak verandert de pool vergeleken met het aantal plekken waar een pin bijgewerkt zou moeten worden?

Directorybewuste toepassingen plus bronbehoudende routering plus een pool die verandert: wijs het subnet toe. Een toepassing die niet kan ontdekken, of een filter dat één adres toelaat: pin die vast, en schrijf op waarom. Al het andere is een geval om de topologie te repareren in plaats van nog een overschrijving toe te voegen.

Controleer vanaf de VPN-client en houd de contracten apart

Test vanaf het werkelijke externe pad, niet vanaf een LAN-werkstation dat al op de site staat. Alleen de eigen kijk van de client telt:

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

Is de gerapporteerde site degene die u hebt toegewezen, dan past het object. Rapporteert de client geen site, dan valt het adres dat hij presenteert binnen geen enkel subnetobject, wat meestal een vertaling of een verouderd prefix betekent. Controleer dan of de gekozen controller de bedoelde is voordat u aanneemt dat de toewijzing is mislukt, want clients cachen ontdekkingsresultaten en failover mag legitiem een andere controller kiezen.

Houd de drie contracten in één document: de pool en zijn subnetobjecten, de controllers die vanaf het VPN-pad bereikbaar zijn, en het beleid dat bepaalt wat een aangemelde gebruiker mag doen. Een site is geen firewallregel en geen isolatiegrens, en de volgende wijziging van de pool zal externe gebruikers stil loskoppelen van het netwerkmodel van de directory, tenzij de toewijzing, de routes en de gedocumenteerde alternatieven samen bewegen.