AD-sideynkartering fersus it fêstsetten fan ien domeinkontrôler foar VPN-klanten

Klanten foar fergewarber tagong op in VPN-pool kinne einigje mei praten tsjin in domeinkontrôler oan de oare kant fan de wrâld, en dat is op twa manieren op te lossen: beskriuw de pool as in Active Directory-subnet ferbûn oan it plak dêr’t de goede kontrôlers binne, of set de klant of de applikaasje fêst op ien spesifike kontrôler. It earste is in topologyske ferklearring dêr’t DC Locator op wurkje kin. It twadde is in oerskriuwing per applikaasje dy’t de topology hielendal negearret. Se kostje ferskate dingen, en hjoed nei de fluchste gripe is krekt hoe’t in katalogusteam op it lêst beide ûnderhâldt.

Wat elke oanpak echt feroaret

In subnetobjekt is in katalogusrecord dat seit by hokker plak in adresberik heart. Mei de Active Directory-module en in besteand plak is de operaasje lyts genôch om foarôf te besjen:

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

-WhatIf besjocht de katalogusskriuwing foarôf. It makket it objekt net oan en test net oft in klant yn dat berik eat berikke kin, en dat is krekt it part dat minsken ferwachtsje. DC Locator lêst it plakmodel as it tsjinstrecords oplost, dus in krekt subnetobjekt feroaret wat de klant bean wurdt.

Fêstsetten wurket op in oare laach. In fêste kontrôlernamme yn in applikaasjekonfiguraasje, in LDAP-string mei in host der yn, of in registerwearde dy’t in foarkarsserver neamt, helje allegear de ûntdekking fan it paad. De applikaasje praat mei dy kontrôler oant immen de ynstelling feroaret, en oerskeakelje by falen is wat dy applikaasje sels ymplementearret.

Wêr’t subnetkartering wint

De pool kartearje beskriuwt de netwurkposysje ien kear, foar elke klant dy’t DC Locator brûkt. As de pool fan ien /24 nei trije groeit, feroaret it model yn twa of trije objekten yn stee fan yn in applikaasjelist. Dat is it hiele foardiel, en it is grut as de klantpopulaasje net ûnder jo kontrôle is.

De hake is dat it objekt oerienkomme moat mei it adres dat de kontrôler wirklik sjocht. As de VPN-poarte elke klant oerset nei in hubadres, beskriuwt it tafoegjen fan de net-oersette pool in netwurkposysje dy’t gjin inkele kontrôler ea sjocht. Beslis betiid oft it ûntwerp it boarneadres fan de klant behâldt, en sa net, kartearje dan it oersette berik yn stee fan de pool dy’t jo op de VPN-server ynsteld hawwe.

In twadde grins: it plakmodel is in foarkar en in topologyske ferklearring. It makket in kontrôler net berikber en it jout in brûker neat. Rûtes en fjoermuorrebelied dogge de berikberens; akkountbelied docht de autorisaasje.

Wêr’t fêstsetten wint

Fêstsetten is it goede antwurd as ûntdekking net wurkje kin: in âlde applikaasje dy’t in kontrôler oplost mei in namme dy’t jo net feroarje kinne, in filter dy’t krekt ien kontrôleradres tastean, of in fêste set servers wêr’t de kontrôler part fan it applikaasjeûntwerp is. Yn dy gefallen is it fêstsetten dokumintaasje fan in echte beheining yn stee fan in flugge wei.

De kosten binne it tsjinoerstelde fan kartering. In fêstsette namme folget de pool net, skeakelet by falen net oer útsein as de applikaasje wit hoe, en oerlibbet in werneamme of ôftanke fan in kontrôler net sûnder in ynhâldsopname. It ferberget ek topologyproblemen, want elke klant dy’t fêstset wurdt liket sûn wylst it plakmodel stilwei ferrottelet.

De gewoane adresrecords fan it domein ferfange troch ien foarkarsserver is gjin tredde opsje. It brekt elke konsumint dy’t de normale ûntdekkingsset ferwachtet, en it kontrolearret noch hieltyd net hoe’t in katalogusbewuste klant in plak kiest.

Kies op trije betingsten

Freegje se yn dizze folchoarder en de beslissing nimt himsels meastentiids. Earst, brûkt de applikaasje DC Locator hielendal, of draacht er al in kontrôleradres? Twadde, sjocht de kontrôler it pooladres, of in oersetten ien? Tredde, hoe faak feroaret de pool ferlike mei hoefolle plakken in fêstsetting bywurke wurde moatte soe?

Katalogusbewuste applikaasjes plus boarnebehâldende routing plus in pool dy’t feroaret: kartearje it subnet. In applikaasje dy’t net ûntdekke kin, of in filter dy’t ien adres talit: set it fêst, en skriuw op wêrom. Al it oare is in gefal om de topology te reparearjen yn stee fan noch in oerskriuwing ta te foegjen.

Ferklearje fan de VPN-klant en hâld de kontrakten apart

Test fan it echte fiere paad, net fan in LAN-wurkstasjon dy’t al op it plak sit. Allinnich de eigen werjeft fan de klant jildt:

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

As it rapportearre plak dat is dat jo karteare hawwe, past it objekt. As de klant gjin plak rapportearret, falt it adres dat er presintearret net yn in subnetobjekt, wat meastentiids in oersetting of in ferâldere foarheaksel betsjut. Kontrolearje dan dat de keazen kontrôler de iene is dy’t jo bedoelden foar’t jo oannimme dat de kartering mislearre is, want klanten cacheje ûntdekkingsresultaten en oerskeakelje by falen kin legitym in oare kontrôler kieze.

Hâld de trije kontrakten yn ien dokumint: de pool en syn subnetobjekten, de kontrôlers dy’t fan it VPN-paad berikber binne, en it belied dat beslút wat in oanmelde brûker dwaan mei. In plak is gjin fjoermuorrelsregel en gjin grins fan isolaasje, en de folgjende poolferoaring sil fiere brûkers stilwei loskeppelje fan it netwurkmodel fan de katalogus, útsein as de kartering, de rûtes en de dokumintearre alternativen tegearre bewege.