Публічны 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.

Калі збой толькі павольны, а не поўны, трымайце затрымку асобна ад дыягностыкі. Тайм-аўт падчас выяўлення можа паходзіць ад недасяжнага кантролера, заблакаванага порта або рэзалвера, які адказвае позна, і ні адзін з іх не даказваецца самім чаканнем. Зафіксуйце фактычны запыт, яго адказ і спробу злучэння, перш чым змяняць наладу рэзалвера.