AD saidi kaardistamine versus domeenikontrolleri kinnitamine VPN-klientide jaoks

VPN-basseini kaugjuurdepääsu kliendid võivad lõpuks rääkida domeenikontrolleriga maailma teisel poolel ja seda saab parandada kahel viisil: kirjeldada basseini Active Directory alavõrguna, mis on seotud õigeid kontrollereid sisaldava saidiga, või kinnitada klient või rakendus ühe kindla kontrolleri külge. Esimene on topoloogiaväide, mille alusel DC Locator saab tegutseda. Teine on rakendusepõhine tühistus, mis eirab topoloogiat täielikult. Nende hind on erinev ja täna kiirema järele haaramine ongi see, kuidas kataloogimeeskond lõpuks mõlemat hooldab.

Mida kumbki lähenemine tegelikult muudab

Alavõrgu objekt on kataloogikirje, mis ütleb, millisesse saiti aadressivahemik kuulub. Active Directory mooduli ja olemasoleva saidiga on toiming piisavalt väike, et seda eelvaadata:

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

-WhatIf näitab kataloogikirjutust eelvaates. See ei loo objekti ega kontrolli, kas selle vahemiku klient pääseb millegini, ja just seda inimesed ootavad. DC Locator loeb saidimudelit siis, kui lahendab teenusekirjeid, seega täpne alavõrgu objekt muudab seda, mida kliendile pakutakse.

Kinnitamine töötab teisel kihil. Fikseeritud kontrolleri nimi rakenduse konfiguratsioonis, hosti sisaldav LDAP-string või registriväärtus, mis nimetab eelistatud serverit, eemaldavad kõik avastamise teelt. Rakendus räägib selle kontrolleriga, kuni keegi seadet muudab, ja tõrke korral ümberlülitamine on see, mida rakendus ise rakendab.

Kus alavõrgu kaardistamine võidab

Basseini kaardistamine kirjeldab võrgukohta ühe korra, iga kliendi jaoks, kes kasutab DC Locatorit. Kui bassein kasvab ühest /24-st kolmeks, muutub mudel kahes või kolmes objektis, mitte rakenduste loendis. See on kogu eelis ja see on suur, kui klientide hulk pole teie kontrolli all.

Konks on selles, et objekt peab vastama aadressile, mida kontroller tegelikult näeb. Kui VPN-lüüs tõlgib iga kliendi jaoturi aadressiks, kirjeldab tõlkimata basseini lisamine võrgukohta, mida ükski kontroller kunagi ei näe. Otsustage varakult, kas disain säilitab kliendi lähteaadressi, ja kui ei säilita, kaardistage tõlgitud vahemik, mitte bassein, mille seadistasite VPN-serveris.

Teine piirang: saidimudel on eelistus ja topoloogiaväide. See ei tee kontrollerit kättesaadavaks ega anna kasutajale midagi. Kättesaadavuse annavad marsruudid ja tulemüüri poliitika; volituse annab konto poliitika.

Kus kinnitamine võidab

Kinnitamine on õige vastus, kui avastamine ei saa töötada: vana rakendus, mis lahendab kontrolleri nime järgi, mida te ei saa muuta, filter, mis lubab täpselt ühte kontrolleri aadressi, või fikseeritud serverite kogum, kus kontroller on osa rakenduse disainist. Neil juhtudel on kinnitus tõelise piirangu dokumenteerimine, mitte otsetee.

Selle hind on kaardistamise vastand. Kinnitatud nimi ei järgi basseini, ei lülitu tõrke korral ümber, kui rakendus ei oska, ja ei ela üle kontrolleri ümbernimetamist ega kasutusest kõrvaldamist ilma inventuurikontrollita. See varjab ka topoloogiaprobleeme, sest iga kinnitatud klient näib terve, samal ajal kui saidimudel vaikselt mädaneb.

Domeeni tavaliste aadressikirjete asendamine ühe eelistatud serveriga ei ole kolmas valik. See murrab iga tarbija, kes ootab tavalist avastamiskogumit, ja ei kontrolli ikkagi, kuidas kataloogiteadlik klient saiti valib.

Valige kolme tingimuse järgi

Küsige neid selles järjekorras ja otsus teeb enamasti ise enda. Esiteks, kas rakendus üldse kasutab DC Locatorit või kannab juba kontrolleri aadressi? Teiseks, kas kontroller näeb basseini aadressi või tõlgitud aadressi? Kolmandaks, kui tihti bassein muutub võrreldes sellega, mitmes kohas tuleks kinnitust uuendada?

Kataloogiteadlikud rakendused pluss lähteaadressi säilitav marsruutimine pluss muutuv bassein: kaardistage alavõrk. Rakendus, mis ei suuda avastada, või filter, mis lubab ühte aadressi: kinnitage see ja kirjutage põhjus. Kõik muu on juhtum topoloogia parandamiseks, mitte veel ühe tühistuse lisamiseks.

Kontrollige VPN-kliendist ja hoidke lepingud lahus

Testige tegelikult kaugteelt, mitte LAN-töökohast, mis juba saidil asub. Loeb ainult kliendi enda vaade:

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

Kui teatatud sait on see, mille kaardistasite, sobib objekt. Kui klient ei teata ühtegi saiti, ei lange esitatav aadress ühegi alavõrgu objekti sisse, mis tähendab tavaliselt tõlget või aegunud prefiksit. Seejärel kontrollige, et valitud kontroller on see, mida kavatsesite, enne kui eeldate kaardistamise ebaõnnestumist, sest kliendid vahemällu salvestavad avastamistulemusi ja tõrke korral ümberlülitamine võib seaduslikult valida teise kontrolleri.

Hoidke kolme lepingut ühes dokumendis: bassein ja selle alavõrgu objektid, VPN-teelt kättesaadavad kontrollerid ning poliitika, mis otsustab, mida sisse logitud kasutaja tohib teha. Sait ei ole tulemüürireegel ega isoleerimispiir, ja järgmine basseini muudatus lahutab kaugkasutajad vaikselt kataloogi võrgumudelist, kui kaardistamine, marsruudid ja dokumenteeritud alternatiivid ei liigu koos.