Pagmamapa ng site ng AD kumpara sa pag-pin ng isang domain controller para sa mga kliyente ng VPN

Ang mga kliyente ng remote access sa isang pool ng VPN ay maaaring mauwi sa pakikipag-usap sa isang domain controller sa kabilang dulo ng mundo, at ito ay naaayos sa dalawang paraan: ilarawan ang pool bilang isang subnet ng Active Directory na nakaugnay sa site na may tamang mga controller, o i-pin ang kliyente o aplikasyon sa isang partikular na controller. Ang una ay isang pahayag ng topolohiya na maaaring kilosan ng DC Locator. Ang pangalawa ay isang pag-override kada aplikasyon na tuluyang binabalewala ang topolohiya. Magkaiba ang kanilang gastos, at ang pagsunggab sa mas mabilis ngayon ay siya mismong dahilan kung bakit ang isang pangkat ng direktoryo ay nauuwi sa pagpapanatili ng dalawa.

Ano ang tunay na binabago ng bawat paraan

Ang object ng subnet ay isang talaan sa direktoryo na nagsasabi kung aling site nabibilang ang isang saklaw ng address. Sa module ng Active Directory at isang umiiral na site, ang operasyon ay sapat na maliit upang i-preview:

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

-WhatIf ay nagpapakita ng preview ng pagsulat sa direktoryo. Hindi ito gumagawa ng object at hindi nito sinusubukan kung ang isang kliyente sa saklaw na iyon ay makakaabot sa anuman, at iyon mismo ang bahaging inaasahan ng mga tao. Binabasa ng DC Locator ang modelo ng site kapag nilulutas nito ang mga talaan ng serbisyo, kaya binabago ng tumpak na object ng subnet ang iniaalok sa kliyente.

Ang pag-pin ay gumagana sa ibang antas. Isang nakapirming pangalan ng controller sa config ng aplikasyon, isang string ng LDAP na may host sa loob, o isang halaga ng registry na nagngangalan ng gustong server, lahat ay nag-aalis ng pagtuklas sa landas. Nakikipag-usap ang aplikasyon sa controller na iyon hanggang may magbago ng setting, at ang paglipat kapag nabigo ay siyang ipinapatupad ng aplikasyong iyon.

Saan nananalo ang pagmamapa ng subnet

Ang pagmamapa ng pool ay naglalarawan ng lokasyon sa network nang isang beses, para sa bawat kliyenteng gumagamit ng DC Locator. Kapag lumaki ang pool mula sa isang /24 patungong tatlo, nagbabago ang modelo sa dalawa o tatlong object sa halip na sa isang imbentaryo ng aplikasyon. Iyon ang buong bentahe, at malaki ito kapag ang populasyon ng kliyente ay wala sa iyong kontrol.

Ang problema ay kailangang tumugma ang object sa address na aktuwal na nakikita ng controller. Kung isinasalin ng gateway ng VPN ang bawat kliyente sa isang address ng hub, ang pagdaragdag ng hindi isinaling pool ay naglalarawan ng lokasyon sa network na hindi kailanman naoobserbahan ng anumang controller. Magpasya nang maaga kung pinapanatili ng disenyo ang source address ng kliyente, at kung hindi, imapa ang isinaling saklaw sa halip na ang pool na na-configure mo sa server ng VPN.

Pangalawang hangganan: ang modelo ng site ay isang preperensya at isang pahayag ng topolohiya. Hindi nito ginagawang maabot ang isang controller at wala itong ibinibigay sa isang user. Ang maabot ay gawa ng mga ruta at patakaran ng firewall; ang pahintulot ay gawa ng patakaran ng account.

Saan nananalo ang pag-pin

Ang pag-pin ang tamang sagot kapag hindi makagana ang pagtuklas: isang lumang aplikasyon na nilulutas ang isang controller sa pamamagitan ng pangalang hindi mo mababago, isang filter na pumapayag ng eksaktong isang address ng controller, o isang nakapirming hanay ng server kung saan bahagi ng disenyo ng aplikasyon ang controller. Sa mga kasong iyon, ang pag-pin ay dokumentasyon ng tunay na hadlang, hindi ng shortcut.

Ang gastos nito ay kabaligtaran ng pagmamapa. Ang naka-pin na pangalan ay hindi sumusunod sa pool, hindi lumilipat kapag nabigo maliban kung alam ng aplikasyon kung paano, at hindi nakakaligtas sa pagpapalit ng pangalan o pagtanggal ng controller nang walang pagsusuri ng imbentaryo. Itinatago rin nito ang mga problema sa topolohiya, dahil ang bawat kliyenteng nag-pin ay mukhang malusog habang tahimik na nabubulok ang modelo ng site.

Ang pagpapalit ng karaniwang mga talaan ng address ng domain ng isang gustong server ay hindi pangatlong opsyon. Sinisira nito ang bawat konsumer na umaasa sa normal na hanay ng pagtuklas, at hindi pa rin kinokontrol kung paano pumipili ng site ang isang kliyenteng may kamalayan sa direktoryo.

Pumili batay sa tatlong kondisyon

Itanong ang mga ito sa ayos na ito at kadalasan ay kusang nagpapasya ang desisyon. Una, gumagamit ba ang aplikasyon ng DC Locator, o may dala na itong address ng controller? Ikalawa, nakikita ba ng controller ang address ng pool, o isang isinalin? Ikatlo, gaano kadalas nagbabago ang pool kumpara sa ilang lugar na kailangang i-update ng isang pin?

Mga aplikasyong may kamalayan sa direktoryo at routing na nagpapanatili ng pinagmulan at pool na nagbabago: imapa ang subnet. Isang aplikasyon na hindi makapagtuklas, o isang filter na tumatanggap ng isang address: i-pin ito, at isulat kung bakit. Ang lahat ng iba pa ay kaso ng pag-aayos ng topolohiya sa halip na pagdaragdag ng isa pang override.

I-verify mula sa kliyente ng VPN at panatilihing hiwalay ang mga kontrata

Subukan mula sa aktuwal na malayong landas, hindi mula sa isang workstation ng LAN na nakaupo na sa site. Tanging ang pananaw ng kliyente mismo ang mahalaga:

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

Kung ang iniulat na site ay ang iminapa mo, tumutugma ang object. Kung walang iniulat na site ang kliyente, ang address na inihaharap nito ay hindi nahuhulog sa anumang object ng subnet, na karaniwang nangangahulugan ng pagsasalin o lipas na prefix. Pagkatapos ay tiyakin na ang napiling controller ay ang nilalayon mo bago ipagpalagay na nabigo ang pagmamapa, dahil nagka-cache ang mga kliyente ng resulta ng pagtuklas at ang paglipat kapag nabigo ay lehitimong makakapili ng ibang controller.

Panatilihin ang tatlong kontrata sa isang dokumento: ang pool at ang mga object ng subnet nito, ang mga controller na maabot mula sa landas ng VPN, at ang patakaran na nagpapasya kung ano ang maaaring gawin ng naka-sign in na user. Ang site ay hindi patakaran ng firewall at hindi hangganan ng pagpigil, at ang susunod na pagbabago ng pool ay tahimik na maghihiwalay sa mga malalayong user mula sa modelo ng network ng direktoryo maliban kung ang pagmamapa, mga ruta at mga dokumentadong alternatibo ay gumalaw nang sama-sama.