AD-helyhozzárendelés vagy tartományvezérlő rögzítése VPN-kliensekhez

Egy VPN-pool távoli hozzáférésű kliensei végül a világ túlsó felén lévő tartományvezérlővel beszélgethetnek, és ezt kétféleképpen lehet orvosolni: a poolt a megfelelő vezérlőket tartalmazó helyhez kötött Active Directory-alhálózatként leírni, vagy a klienst vagy alkalmazást egyetlen adott vezérlőhöz rögzíteni. Az első topológiai állítás, amelyre a DC Locator tud építeni. A második alkalmazásonkénti felülírás, amely teljesen figyelmen kívül hagyja a topológiát. Másképp kerülnek pénzbe, és ha ma a gyorsabbhoz nyúlunk, abból lesz, hogy a címtárcsapat végül mindkettőt fenntartja.

Mit változtat meg ténylegesen az egyes megközelítés

Az alhálózati objektum egy címtárrekord, amely megmondja, melyik helyhez tartozik egy címartomány. Az Active Directory modullal és egy meglévő hellyel a művelet elég kicsi az előzetes megtekintéshez:

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

-WhatIf előzetesen megmutatja a címtárba írást. Nem hozza létre az objektumot, és nem vizsgálja, hogy az adott tartomány kliensе elér-e bármit, pedig épp ezt szokták várni. A DC Locator akkor olvassa a helymodellt, amikor feloldja a szolgáltatásrekordokat, ezért egy pontos alhálózati objektum megváltoztatja, mit kínálnak a kliensnek.

A rögzítés más rétegben működik. Egy alkalmazás konfigurációjában szereplő rögzített vezérlőnév, egy hosztot tartalmazó LDAP-karakterlánc vagy egy előnyben részesített kiszolgálót megnevező beállításjegyzék-érték mind kiveszi a felderítést az útból. Az alkalmazás addig beszél azzal a vezérlővel, amíg valaki meg nem változtatja a beállítást, a hibafallback pedig az, amit az alkalmazás maga megvalósít.

Ahol az alhálózat-leképezés nyer

A pool leképezése egyszer írja le a hálózati helyet, minden kliens esetében, amely DC Locatort használ. Amikor a pool egy /24-ről háromra nő, a modell két vagy három objektumban változik, nem egy alkalmazásleltárban. Ez az egész előny, és nagy, amikor a kliensek száma nincs az irányításod alatt.

A horog az, hogy az objektumnak meg kell felelnie annak a címnek, amelyet a vezérlő valóban lát. Ha a VPN-átjáró minden klienst egy hubcímre fordít, a fordítatlan pool hozzáadása olyan hálózati helyet ír le, amelyet egyetlen vezérlő sem figyel meg. Döntsd el korán, hogy a tervezés megőrzi-e a kliens forráscímét, és ha nem, a VPN-kiszolgálón beállított pool helyett a fordított tartományt képezd le.

Második korlát: a helymodell preferencia és topológiai állítás. Nem teszi elérhetővé a vezérlőt, és nem ad semmit a felhasználónak. Az elérhetőséget az útvonalak és a tűzfal-szabályzat adják; az engedélyezést a fiókszabályzat.

Ahol a rögzítés nyer

A rögzítés akkor a helyes válasz, amikor a felderítés nem tud működni: egy örökölt alkalmazás, amely olyan névvel oldja fel a vezérlőt, amelyet nem tudsz megváltoztatni, egy szűrő, amely pontosan egy vezérlőcímet engedélyez, vagy egy rögzített kiszolgálókészlet, ahol a vezérlő az alkalmazástervezés része. Ezekben az esetekben a rögzítés valódi korlát dokumentálása, nem rövidítés.

Az ára a leképezés ellentéte. A rögzített név nem követi a poolt, nem vált hibánál, hacsak az alkalmazás nem tudja, és nem éli túl egy vezérlő átnevezését vagy kivonását leltárátvizsgálás nélkül. Elrejti a topológiai problémákat is, mert minden rögzítő kliens egészségesnek látszik, miközben a helymodell csendben rohad.

A tartomány szokásos címrekordjait egyetlen előnyben részesített kiszolgálóra cserélni nem harmadik lehetőség. Ez megtöri minden fogyasztót, amely a normál felderítési készletet várja, és továbbra sem szabályozza, hogyan választ helyet egy címtárat ismerő kliens.

Három feltétel alapján válassz

Ebben a sorrendben kérdezd meg őket, és a döntés általában magától megszületik. Először: használ-e az alkalmazás egyáltalán DC Locatort, vagy már hordoz vezérlőcímet? Másodszor: a vezérlő a pool címét látja, vagy egy fordítottat? Harmadszor: milyen gyakran változik a pool ahhoz képest, hány helyen kellene egy rögzítést frissíteni?

Címtárat ismerő alkalmazások plusz forrást megőrző útvonalválasztás plusz változó pool: képezd le az alhálózatot. Olyan alkalmazás, amely nem tud felderíteni, vagy szűrő, amely egy címet enged, rögzítsd, és írd le, miért. Minden más eset a topológia javítására, nem újabb felülírás hozzáadására.

Ellenőrizd a VPN-kliensből, és tartsd külön a szerződéseket

A tényleges távoli útvonalról tesztelj, ne egy LAN-munkaállomásról, amely már a helyen van. Csak a kliens saját nézete számít:

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

Ha a jelentett hely az, amelyet leképeztél, az objektum illeszkedik. Ha a kliens nem jelent helyet, az általa bemutatott cím nem esik egyetlen alhálózati objektumba sem, ami általában fordítást vagy elavult előtagot jelent. Ezután ellenőrizd, hogy a választott vezérlő az, amelyet szándékoltál, mielőtt azt feltételeznéd, hogy a leképezés hibázott, mert a kliensek gyorsítótárazzák a felderítési eredményeket, és a hibafallback jogosan választhat másik vezérlőt.

Tartsd a három szerződést egy dokumentumban: a poolt és alhálózati objektumait, a VPN-útvonalról elérhető vezérlőket, és a szabályzatot, amely eldönti, mit tehet egy bejelentkezett felhasználó. A hely nem tűzfalszabály és nem elkülönítési határ, és a következő poolváltozás csendben leválasztja a távoli felhasználókat a címtár hálózati modelljéről, hacsak a leképezés, az útvonalak és a dokumentált alternatívák nem mozdulnak együtt.