Два DNS-серверы на адным адаптары не падзяляюць прасторы імёнаў
Пералік двух рэзалвераў на адным адаптары не дае кожнаму дамену ўласных паўнамоцтваў. Стварыце два абмежаваныя правілы, праверце выбар і выдаліце менавіта іх.
Пералік двух рэзалвераў на адным адаптары выглядае як спосаб накіраваць адзін дамен на адзін сервер, а іншы дамен — на другі, і нішто ў спісе рэзалвераў так не працуе. Windows развязвае па імені, і рашэнне пра тое, які сервер пытаць, прыходзіць з аб'ектаў палітыкі, а не з упарадкаванага спісу адрасоў. Ментальную мадэль, якую трэба замяніць, — гэта чарга: няма першага сервера для дамена A і другога сервера для дамена B. Ёсць набор правілаў для кожнай прасторы імёнаў, якія відавочна называюць серверы, і калі гэтыя правілы існуюць, спіс адаптара перастае быць цікавым.
Міф: два адрасы падзяляюць два дамены
Гэтае перакананне жыве, бо яно выпадкова працуе, калі адзін сервер адказвае на ўсё, а другі — толькі рэзервовы варыянт. Кліент пытае першы сервер, той сервер перасылае або рэкурсіць, і адказ прыходзіць; ніхто не заўважае, які рэзалвер насамрэч трымаў зону. Ілюзія рассыпаецца ў той момант, калі дзве прасторы імёнаў жывуць у асобных прыватных зонах без перасылкі паміж імі, бо першы сервер тады аўтарытэтна адказвае, што імя не існуе. Адмоўны адказ ад першага сервера не запускае рэзервовы варыянт, бо кліент атрымаў канчатковы адказ, а не збой.
Упарадкаваны спіс не мае паняцця дамена, таму не можа выразіць намер. Спіс насамрэч кіруе тым, які сервер пытаюць першым, а які другім, і абодва гэтыя адказы аднолькава датычаць кожнага імені.
Што Windows насамрэч выкарыстоўвае для выбару
Табліца палітыкі развязання імёнаў супастаўляе імя з наладжанымі прасторамі імёнаў і выбірае серверы і параметры для гэтага супадзення. Правілы можна наладзіць лакальна, даставіць праз групавую палітыку або даць праз профіль VPN, і дзейная палітыка — гэта спалучэнне, а не адзіны спіс. Таму першая дыягностыка заўсёды — дзейны стан: лакальна створанае правіла, якое прайграе кіраванай палітыцы, робіць лабараторыю, што паводзіць сябе зусім не так, як мяркуе яе канфігурацыя. Правілы таксама супастаўляюцца па дакладнасці, таму шырокі запіс прасторы імёнаў можа пераважыць вузкі такім чынам, які нябачны ў спісе наладжаных элементаў. Чытанне дзейнага парадку — адзіны спосаб убачыць, якое правіла перамагае.
Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective
Першая каманда пералічвае тое, што наладжана на машыне; другая паказвае, што кліент фактычна ўжыве, уключаючы запісы, якія прыйшлі з іншага месца. Калі дзейны вывад змяшчае кіраваныя прасторы імёнаў, правільнае месца для запыту змены — уласнік гэтай палітыкі, а не лакальны спіс правілаў. Абедзве каманды толькі чытаюць стан, таму запуск іх да таго, як хто-небудзь пагодзіцца на змену, нічога не каштуе.
Адно правіла на прастору імёнаў, захавайце аб'ект
Калі дзейны стан зразумелы, стварыце адно правіла на прастору імёнаў і захавайце аб'ект, які вяртае кожная каманда. Паказальныя імёны — гэта этыкеткі для людзей, а ўнікальны ідэнтыфікатар у вернутым аб'екце — надзейная цэль для выдалення потым. Запішыце абодва ідэнтыфікатары ў тую ж нататку пра змену, дзе зафіксаваны прасторы імёнаў і рэзалверы, бо сесія, што іх стварыла, не будзе той сесіяй, што прыбірае.
$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers
Вядучая кропка пазначае супадзенне па суфіксе, таму правіла ахоплівае app.svc.internal.example і ўсё астатняе пад ім. Два адрасы тут належаць уласнаму плану маршрутызацыі гэтай лабараторыі; правіла не стварае зону, не ўсталёўвае маршрут і не дазваляе праграме, якая ўрэшце падключаецца, і даведка па Add-DnsClientNrptRule дакладна паказвае, які параметр што робіць.
Звярніце ўвагу, чаго гэтыя каманды не робяць: яны дзейнічаюць на ўсю машыну, не абмежаваныя сесіяй VPN, і яны застаюцца пасля закрыцця акна. Лабараторыя, якая гэта забывае, пакідае палітыку пасля знікнення тунеля.
Дакажыце, што кліент выбраў сервер
Пытанне да пэўнага сервера, ці ведае ён імя, даказвае, што сервер можа адказаць, і гэта не тое ж сцвярджэнне, што кліент выбраў менавіта гэты сервер. Важная праверка развязвае рэальнае імя звычайным шляхам кліента і потым пацвярджае, які рэзалвер з ім меў справу, у ідэале тады, калі тунель, што дае маршрут, узняты. Калі тунель апушчаны, правільна абмежаванае правіла ўсё роўна паказвае на недасягальны сервер, і гэта праблема маршрутызацыі, а не палітыкі. Праверце абодва станы, каб потым іх можна было адрозніць.
Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile
Сачыце за кэшаванымі адказамі з перыяду да з'яўлення правілаў і за праграмамі, якія цалкам абыходзяць сістэмны рэзалвер са сваім шыфраваным DNS. Пошукавыя суфіксы — яшчэ асобная функцыя: правіла можа выбраць рэзалвер для поўнага імені, не навучаючы Windows разгортваць гатольнае імя хаста ў гэтую прастору імёнаў.
Выдаліце менавіта тое, што стварылі
Прыбіранне — гэта месца, дзе лабараторыя становіцца павучальнай гісторыяй. Выдаленне ўсіх правілаў на машыне хуткае і прыбірае палітыку, на якую спадзяецца нехта іншы, таму выкарыстоўвайце ідэнтыфікатары, запісаныя пры стварэнні правілаў, і пасля зноў прачытайце дзейны стан, каб пацвердзіць, што машына вярнулася туды, адкуль пачала. Калі сесія, што іх стварыла, знікла, нататка пра змену — адзінае месца, дзе існуюць ідэнтыфікатары. Вось чаму іх запісваюць да запуску першай каманды, а не пасля.
Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective
Для разгортвання, а не лабараторыі, пытанне пра тэрмін службы важнае не менш за правіла. Профіль VPN можа несці правілы прастор імёнаў і выбіраць, ці застануцца яны пасля злучэння; правіла, якое застаецца, пакуль рэзалвер недасягальны, прымушае кліентаў аддаваць перавагу мёртваму серверу, а правіла, абмежаванае злучэннем, знікае разам з тунелем. Вырашыце, які з гэтых паводзін патрэбны сэрвісу, адзначце, хто валодае правілам, і пакіньце падзел паўнамоцтваў задокументаваным побач з профілем, а не ў чыёйсьці памяці пра лабараторыю.