Јавниот 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.

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