Два 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 профил може да носи правилата за пространства от имена и да избере дали те да останат след връзката; правило, което остава, докато резолверът е недостижим, оставя клиентите да предпочитат мъртъв сървър, а правило, ограничено до връзката, изчезва заедно с тунела. Решете кое от тези поведения е нужно на услугата, отбележете кой притежава правилото и оставете разделението на правомощията документирано до профила, а не в нечия памет за лаборатория.

Подобни статии