Съпоставяне на AD сайт и фиксиране на домейн контролер за VPN клиенти

Клиентите за отдалечен достъп в пул за VPN могат в крайна сметка да говорят с домейн контролер от другата страна на света и има два начина да се поправи това: пулът да се опише като подмрежа в Active Directory, свързана със сайта с правилните контролери, или клиентът или приложението да се фиксира към един конкретен контролер. Първото е твърдение за топологията, с което DC Locator може да работи. Второто е замяна на ниво приложение, която напълно игнорира топологията. Те струват различно и точно бързането към по-бързото днес води до това екипът по директорията да поддържа и двете.

Какво всъщност променя всеки подход

Обектът на подмрежа е запис в директорията, който казва към кой сайт принадлежи диапазон от адреси. С модула Active Directory и съществуващ сайт операцията е достатъчно малка, за да се прегледа:

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

-WhatIf преглежда записа в директорията. Той не създава обекта и не проверява дали клиент от този диапазон може да достигне нещо, а точно това хората очакват. DC Locator чете модела на сайтовете, когато разрешава записи за услуги, така че точният обект на подмрежа променя това, което се предлага на клиента.

Фиксирането работи на друго ниво. Фиксирано име на контролер в конфигурация на приложение, LDAP низ с хост в него или стойност в регистъра, която посочва предпочитан сървър, всички премахват откриването от пътя. Приложението говори с този контролер, докато някой промени настройката, а превключването при отказ е това, което приложението реализира.

Къде съпоставянето на подмрежа печели

Съпоставянето на пула описва мрежовото местоположение веднъж, за всеки клиент, който използва DC Locator. Когато пулът нарасне от една /24 до три, моделът се променя в два или три обекта вместо в инвентар на приложения. Това е цялото предимство и то е голямо, когато популацията от клиенти не е под ваш контрол.

Уловката е, че обектът трябва да съответства на адреса, който контролерът наистина вижда. Ако VPN шлюзът преобразува всеки клиент към адрес на концентратор, добавянето на непреобразувания пул описва мрежово местоположение, което никой контролер не наблюдава. Решете рано дали дизайнът запазва изходния адрес на клиента и ако не, съпоставете преобразувания диапазон вместо пула, който сте конфигурирали на VPN сървъра.

Второ ограничение: моделът на сайтовете е предпочитание и твърдение за топологията. Той не прави контролера достъпен и не дава нищо на потребителя. Достъпността се осигурява от маршрути и политика на защитната стена; оторизацията — от политиката на акаунтите.

Къде фиксирането печели

Фиксирането е правилният отговор, когато откриването не може да работи: старо приложение, което разрешава контролер по име, което не можете да промените, филтър, който разрешава точно един адрес на контролер, или фиксиран набор сървъри, където контролерът е част от дизайна на приложението. В тези случаи фиксацията е документиране на реално ограничение, а не заобиколен път.

Цената ѝ е обратната на съпоставянето. Фиксираното име не следва пула, не превключва при отказ, освен ако приложението знае как, и не оцелява при преименуване или извеждане от експлоатация на контролер без проверка на инвентара. То също скрива проблеми с топологията, защото всеки фиксиран клиент изглежда здрав, докато моделът на сайтовете тихо гние.

Замяната на обичайните адресни записи на домейна с един предпочитан сървър не е трети вариант. Това чупи всеки консуматор, който очаква нормалния набор за откриване, и все още не контролира как клиент, който познава директорията, избира сайт.

Избирайте по три условия

Питайте ги в този ред и решението обикновено се взема само. Първо, използва ли приложението изобщо DC Locator или вече носи адрес на контролер? Второ, вижда ли контролерът адреса на пула или преобразуван? Трето, колко често се променя пулът в сравнение с това колко места трябва да се обновят при фиксация?

Приложения, които познават директорията, плюс маршрутизация, запазваща източника, плюс пул, който се променя: съпоставете подмрежата. Приложение, което не може да открие, или филтър, който допуска един адрес: фиксирайте го и запишете защо. Всичко останало е случай за поправяне на топологията, а не за добавяне на още една замяна.

Проверявайте от VPN клиента и дръжте договорите отделно

Тествайте от реалния отдалечен път, а не от работна станция в LAN, която вече е в сайта. Важна е единствено гледната точка на самия клиент:

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

Ако отчетеният сайт е този, който сте съпоставили, обектът съвпада. Ако клиентът не отчете сайт, адресът, който представя, не попада в нито един обект на подмрежа, което обикновено означава преобразуване или остарял префикс. След това проверете, че избраният контролер е този, който сте имали предвид, преди да приемете, че съпоставянето се е провалило, защото клиентите кешират резултатите от откриването и превключването при отказ може законно да избере друг контролер.

Дръжте трите договора в един документ: пулът и неговите обекти на подмрежи, контролерите, достъпни от пътя на VPN, и политиката, която решава какво може да прави влязъл потребител. Сайтът не е правило на защитната стена и не е граница на изолация и следващата промяна на пула тихо ще отдели отдалечените потребители от мрежовия модел на директорията, освен ако съпоставянето, маршрутите и документираните алтернативи не се движат заедно.