AD-terreinlynkartering of die vaspen van een domeinkontroleerder vir VPN-kliënte

Afgeleë toegang-kliënte op ’n VPN-poel kan uiteindelik met ’n domeinkontroleerder aan die ander kant van die wêreld praat, en daar is twee maniere om dit reg te stel: beskryf die poel as ’n Active Directory-subnet wat aan die terrein met die regte kontroleerders gekoppel is, of pen die kliënt of toepassing aan een spesifieke kontroleerder vas. Die eerste is ’n topologieverklaring waarop DC Locator kan reageer. Die tweede is ’n oorheersing per toepassing wat die topologie heeltemal ignoreer. Hulle kos verskillende dinge, en om vandag na die vinnigste een te gryp, is hoe ’n gidsspan uiteindelik albei onderhou.

Wat elke benadering werklik verander

’n Subnetobjek is ’n gidsrekord wat sê aan watter terrein ’n adresreeks behoort. Met die Active Directory-module en ’n bestaande terrein is die bewerking klein genoeg om vooraf te bekyk:

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

-WhatIf wys ’n voorskou van die gidskryf. Dit skep nie die objek nie en dit toets nie of ’n kliënt in daardie reeks enigiets kan bereik nie, en dit is juis die deel wat mense verwag. DC Locator lees die terreinmodel wanneer dit diensrekords oplos, so ’n akkurate subnetobjek verander wat aan die kliënt gebied word.

Vaspen werk op ’n ander laag. ’n Vaste kontroleerdernaam in ’n toepassingskonfigurasie, ’n LDAP-string met ’n gasheer in, of ’n registerwaarde wat ’n voorkeurbediener noem, verwyder almal die ontdekking uit die pad. Die toepassing praat met daardie kontroleerder totdat iemand die instelling verander, en oorskakeling is wat daardie toepassing ook al implementeer.

Waar subnetkartering wen

Om die poel te karteer beskryf netwerklokasie een keer, vir elke kliënt wat DC Locator gebruik. Wanneer die poel van een /24 na drie groei, verander die model in twee of drie objekte in plaas van in ’n toepassingsinventaris. Dit is die hele voordeel, en dit is groot wanneer die kliëntepopulasie nie onder jou beheer is nie.

Die vangplek is dat die objek moet ooreenstem met die adres wat die kontroleerder werklik sien. As die VPN-grendel elke kliënt na ’n spilpuntadres vertaal, beskryf die toevoeging van die onvertaalde poel ’n netwerklokasie wat geen kontroleerder ooit waarneem nie. Besluit vroeg of die ontwerp die kliënt se bronadres bewaar, en indien nie, karteer die vertaalde reeks in plaas van die poel wat jy op die VPN-bediener opgestel het.

’n Tweede beperking: die terreinmodel is ’n voorkeur en ’n topologieverklaring. Dit maak nie ’n kontroleerder bereikbaar nie, en dit gee niks aan ’n gebruiker nie. Roetes en vuurmuurbeleid sorg vir bereikbaarheid; rekeningbeleid sorg vir magtiging.

Waar vaspen wen

Vaspen is die regte antwoord wanneer ontdekking nie kan werk nie: ’n ou toepassing wat ’n kontroleerder oplos met ’n naam wat jy nie kan verander nie, ’n filter wat presies een kontroleerderadres toelaat, of ’n vaste stel bedieners waar die kontroleerder deel van die toepassingsontwerp is. In daardie gevalle is die pen dokumentasie van ’n werklike beperking eerder as ’n kortpad.

Die koste daarvan is die teenoorgestelde van kartering. ’n Vasgepen naam volg nie die poel nie, skakel nie oor nie tensy die toepassing weet hoe nie, en oorleef nie ’n kontroleerder se hernoeming of uitbedryfstelling sonder ’n inventarisveeg nie. Dit verberg ook topologieprobleme, want elke kliënt wat vaspen lyk gesond terwyl die terreinmodel stilweg verrot.

Om die domein se gewone adresrekords met een voorkeurbediener te vervang is nie ’n derde opsie nie. Dit breek elke verbruiker wat die normale ontdekkingsstel verwag, en dit beheer steeds nie hoe ’n gidsbewuste kliënt ’n terrein kies nie.

Kies op drie voorwaardes

Vra hulle in hierdie volgorde en die besluit maak gewoonlik homself. Eerstens, gebruik die toepassing DC Locator hoegenaamd, of dra dit reeds ’n kontroleerderadres? Tweedens, sien die kontroleerder die poeladres, of ’n vertaalde een? Derdens, hoe dikwels verander die poel vergeleke met hoeveel plekke ’n pen opgedateer sou moes word?

Gidsbewuste toepassings plus bronbewarende roetering plus ’n poel wat verander: karteer die subnet. ’n Toepassing wat nie kan ontdek nie, of ’n filter wat een adres toelaat: pen dit vas, en skryf neer waarom. Alles anders is ’n geval vir die regmaak van die topologie eerder as om nog ’n oorheersing by te voeg.

Verifieer vanaf die VPN-kliënt en hou die kontrakte apart

Toets vanaf die werklike afgeleë pad, nie vanaf ’n LAN-werkstasie wat al in die terrein sit nie. Die kliënt se eie siening is die enigste een wat saak maak:

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

As die gerapporteerde terrein die een is wat jy gekarteer het, pas die objek. As die kliënt geen terrein rapporteer nie, val die adres wat dit voorhou nie binne enige subnetobjek nie, wat gewoonlik ’n vertaling of ’n verouderde voorvoegsel beteken. Kontroleer dan dat die gekose kontroleerder die een is wat jy bedoel het voordat jy aanvaar dat die kartering misluk het, want kliënte kas ontdekkingsresultate en oorskakeling kan wettiglik ’n ander kontroleerder kies.

Hou die drie kontrakte in een dokument: die poel en sy subnetobjekte, die kontroleerders wat vanaf die VPN-pad bereikbaar is, en die beleid wat besluit wat ’n aangemelde gebruiker mag doen. ’n Terrein is nie ’n vuurmuurreël nie en nie ’n inperkingsgrens nie, en die volgende poelverandering sal afgeleë gebruikers stilweg van die gids se netwerkmodel losmaak tensy die kartering, die roetes en die gedokumenteerde alternatiewe saam beweeg.