AD-ejla mapado kontraŭ fiksado de domajna regilo por VPN-klientoj

Fremdaj alirklientoj en VPN-naĝujo povas fini parolante kun domajna regilo ĉe la alia flanko de la mondo, kaj tio ripareblas duamanire: priskribi la naĝujon kiel Active Directory-subreton ligitan al la ejo, kiu tenas la ĝustajn regilojn, aŭ fiksi la klienton aŭ la aplikaĵon al unu specifa regilo. La unua estas aserto pri topologio, sur kiu DC Locator povas agi. La dua estas anstataŭigo po aplikaĵo, kiu tute ignoras la topologion. Ili kostas malsamajn aferojn, kaj ekkapti hodiaŭ la pli rapidan estas ĝuste kiel domajna teamo finas prizorgante ambaŭ.

Kion ĉiu aliro fakte ŝanĝas

Subreta objekto estas rikordo en la adresaro, kiu diras al kiu ejo apartenas adresaro. Kun la modulo Active Directory kaj ekzistanta ejo, la operacio estas sufiĉe malgranda por antaŭvidi:

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

-WhatIf antaŭvidas la skribon en la adresaron. Ĝi ne kreas la objekton kaj ne testas, ĉu kliento en tiu gamo povas atingi ion, kaj ĝuste tion homoj atendas. DC Locator legas la ejan modelon kiam ĝi solvas servajn rikordojn, do preciza subreta objekto ŝanĝas tion, kio estas proponata al la kliento.

Fiksado laboras en alia tavolo. Fiksa regila nomo en aplikaĵa agordo, LDAP-ĉeno kun gastiganto ene, aŭ registra valoro, kiu nomas preferatan servilon, ĉiuj forigas la malkovron el la vojo. La aplikaĵo parolas kun tiu regilo ĝis iu ŝanĝas la agordon, kaj baskulado estas tio, kion tiu aplikaĵo mem efektivigas.

Kie subreta mapado venkas

Mapi la naĝujon priskribas retan lokon unufoje, por ĉiu kliento, kiu uzas DC Locator. Kiam la naĝujo kreskas de unu /24 al tri, la modelo ŝanĝiĝas en du aŭ tri objektoj anstataŭ en aplikaĵa inventaro. Tio estas la tuta avantaĝo, kaj ĝi estas granda, kiam la klientaro ne estas sub via kontrolo.

La kaŝitaĵo estas, ke la objekto devas kongrui kun la adreso, kiun la regilo fakte vidas. Se la VPN-enirejo tradukas ĉiun klienton al huba adreso, aldoni la netradukitan naĝujon priskribas retan lokon, kiun neniu regilo iam observas. Decidu frue, ĉu la dezajno konservas la fontan adreson de la kliento, kaj se ne, mapu la tradukitan gamon anstataŭ la naĝujo, kiun vi agordis ĉe la VPN-servilo.

Dua limo: la eja modelo estas prefero kaj aserto pri topologio. Ĝi ne igas regilon atingebla kaj donas nenion al uzanto. Itineroj kaj fajroŝirma politiko faras la atingeblon; konta politiko faras la rajtigon.

Kie fiksado venkas

Fiksado estas la ĝusta respondo, kiam malkovro ne povas funkcii: malnova aplikaĵo, kiu solvas regilon per nomo, kiun vi ne povas ŝanĝi, filtrilo, kiu permesas ekzakte unu regilan adreson, aŭ fiksa aro da serviloj, kie la regilo estas parto de la aplikaĵa dezajno. En tiuj kazoj la fikso estas dokumentado de reala limo, ne fuŝsolvo.

Ĝia kosto estas la malo de mapado. Fiksita nomo ne sekvas la naĝujon, ne baskulas krom se la aplikaĵo scias kiel, kaj ne postvivas renomadon aŭ malmuntadon de regilo sen inventara trarigardo. Ĝi ankaŭ kaŝas topologiajn problemojn, ĉar ĉiu fiksita kliento aspektas sana dum la eja modelo silente putriĝas.

Anstataŭigi la ordinarajn adresajn rikordojn de la domajno per unu preferata servilo ne estas tria eblo. Ĝi rompas ĉiun konsumanton, kiu atendas la normalan malkovran aron, kaj ĝi ankoraŭ ne regas kiel adresar-konscia kliento elektas ejon.

Elektu laŭ tri kondiĉoj

Demandu ilin laŭ ĉi tiu ordo kaj la decido kutime faras sin mem. Unue, ĉu la aplikaĵo entute uzas DC Locator, aŭ ĉu ĝi jam portas regilan adreson? Due, ĉu la regilo vidas la naĝujan adreson, aŭ tradukitan? Trie, kiom ofte la naĝujo ŝanĝiĝas kompare kun kiom da lokoj fikso devus esti ĝisdatigita?

Adresar-konsciaj aplikaĵoj plus fontkonserva enkursigado plus ŝanĝiĝanta naĝujo: mapu la subreton. Aplikaĵo, kiu ne povas malkovri, aŭ filtrilo, kiu allasas unu adreson: fiksu ĝin, kaj skribu kial. Ĉio alia estas kazo por ripari la topologion anstataŭ aldoni plian anstataŭigon.

Kontrolu el la VPN-kliento kaj tenu la kontraktojn aparte

Testu el la reala fora vojo, ne el LAN-laborstacio, kiu jam sidas en la ejo. Nur la propra vido de la kliento gravas:

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

Se la raportita ejo estas tiu, kiun vi mapis, la objekto kongruas. Se la kliento raportas neniun ejon, la adreso, kiun ĝi prezentas, falas en neniun subretan objekton, kio kutime signifas tradukon aŭ malnoviĝintan prefikson. Poste kontrolu, ke la elektita regilo estas tiu, kiun vi intencis, antaŭ ol supozi, ke la mapado malsukcesis, ĉar klientoj kaŝmemorigas malkovrajn rezultojn kaj baskulado povas laŭleĝe elekti alian regilon.

Tenu la tri kontraktojn en unu dokumento: la naĝujo kaj ĝiaj subretaj objektoj, la regiloj atingeblaj el la VPN-vojo, kaj la politiko, kiu decidas kion ensalutinta uzanto rajtas fari. Ejo ne estas fajroŝirma regulo kaj ne estas izola limo, kaj la sekva ŝanĝo de la naĝujo silente apartigos forajn uzantojn de la reta modelo de la adresaro, se la mapado, la itineroj kaj la dokumentitaj alternativoj ne moviĝas kune.