Публичното 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.

Ако провалът е само бавен, а не неуспешен, дръжте забавянето отделно от диагнозата. Изтичане на времето по време на откриване може да дойде от недостижим контролер, блокиран порт или резолвер, който отговаря късно, и нито едно от тях не се доказва само от чакането. Запишете действителната заявка, отговора ѝ и опита за връзка, преди да промените настройка на резолвера.