Јавни DNS ради, али то не значи да се Active Directory може пронаћи

VPN се повеже, прегледач отвори јавну страницу, а лаптоп се ипак не може пријавити у домен. Уобичајен закључак је да је DNS исправан јер се имена разрешавају. Није исправан, а разлог је да тест у прегледачу проверава само један упит из ланца који клијент придружен домену треба. Откривање домена најпре тражи записе услуга, затим адресе контролера које ти записи именују, а затим руту до портова на којима ти контролери слушају. Јавни одговор не задовољава ниједан од тих корака.

Мит: имена се разрешавају, па је DNS завршен

Јавна страница која се разрешава говори само то да је неки разрешивач одговорио на један A или AAAA упит за име у јавној зони. Active Directory користи исти протокол за друго питање: где су услуге домене и који контролер треба користити овај клијент. Питање се изражава SRV записима у зони названој по домени, а рекурзивни јавни разрешивач нема разлога да их држи.

Када запис недостаје, разрешивач враћа негативан одговор, што је ваљан DNS одговор, а не прекид рада. Клијент се затим враћа на кеширане податке о контролерима ако их има, и управо зато стоно рачунало може сатима изгледати добро, а пасти након поновног покретања или промене лозинке.

Шта клијент домене заиста тражи, по реду

За домену као што је corp.example, општи упит локатора је _ldap._tcp.dc._msdcs.corp.example. SRV одговори именују кандидате за контролере и њихове портове, а клијент затим треба записе адреса за та имена хостова пре него што отвори везу. Откривање свесно локације додаје упите испод поддомене локације, а одговори одређују који су контролери пожељни, а не који је обавезан.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Пратите ланац тим редом, из мреже у којој се проблем јавља. Име хоста које се разрешава на недоступну адресу јест грешка усмеравања, а не DNS грешка. Доступан контролер којем недостају записи локатора јест DNS грешка, а не грешка усмеравања. Обе дају сличне притужбе корисника и посве различите поправке.

Зашто јавни разрешивач одговара, а пријава се ипак квари

Ако адаптер клијенту додели јавни разрешивач, јавна имена раде, а унутрашњи простор имена не. Додавање другог јавног разрешивача не помаже, јер ниједан не држи зону. Ни уобичајен списак „прво унутрашњи, затим јавни“ не понаша се као правило по домени: негативан одговор првог сервера ваљан је одговор, и клијент не покушава други сервер само зато што је одговор био празан.

Оба унутрашња разрешивача, ако их имате два, морају држати AD простор имена и бити доступни из клијентове тренутне мреже. Управо то кваре дизајни раздвојеног тунела: VPN може носити подмрежу тунела док унутрашњи разрешивач стоји на префиксу који тунел не усмерава, па упит одлази разрешивачу који га не може одговорити.

Windows примењује и правило разрешавања имена које може усмерити одређене просторе имена на одређене сервере, а DNS адресе које адаптер приказује нису цела прича. Промена списка адаптера без промене тог правила може оставити стварну конфигурацију нетакнутом, и зато поправка која изгледа примењена нема учинка.

Држите DNS тунела и његове руте усклађеним

VPN профил који гура разрешивач, али не и префикс који га садржи, ствара разрешивач који клијент не може достићи; онај који гура префикс без разрешивача оставља клијента да пита локални. Третирајте пар као једну конфигурацијску ставку и проверите обоје након сваке промене профила, јер преуређено гурање или ново правило раздвојеног тунела може их раздвојити.

Проверите и шта клијент чини с гурнутом поставком. Неки клијенти примењују DNS сервер само на интерфејс тунела и остављају разрешивач физичког адаптера на месту, па о томе који побеђује одлучују метрика интерфејса и име које се пита. Ако унутрашњи одговор долази само кад је физички адаптер онемогућен, то је механизам који треба поправити, а не записи домене.

Прихватите уз позив откривања и једну живу радњу

Користан прихватни тест покреће упит локатора и затим изводи једну стварну аутентификовану радњу, попут отварања мрежног ресурса подржаног имеником или захтева за карту. Учините то пре прелаза на VPN и поново после, на истом рачунару, без поновног покретања између. Кеширани подаци за пријаву и већ отворене сесије радо ће покварен пут приказати здравим, па успешна пријава на радну површину није тест.

Препоруке Microsoft-а за DNS клијента повлаче исту границу између разрешавања унутрашњег простора имена и прослеђивања јавних упита према горе, и то је распоред који треба сачувати кад се уводи VPN.

Ако је квар само спор, а не потпун, држите одгоду одвојено од дијагнозе. Истек времена током откривања може доћи од недоступног контролера, блокираног порта или разрешивача који одговара касно, и ништа од тога не доказује само чекање. Забележите стварни упит, његов одговор и покушај везе пре него што промените поставку разрешивача.