ერთ ადაპტერზე ორი 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 პროფილს შეუძლია სახელთა სივრცის წესების ტარება და არჩევა, დარჩება თუ არა ისინი კავშირის შემდეგ; წესი, რომელიც რჩება, სანამ გადამწყვეტი მიუწვდომელია, კლიენტებს მკვდარი სერვერის უპირატესობას უტოვებს, ხოლო კავშირზე შემოსაზღვრული წესი გვირაბთან ერთად ქრება. გადაწყვიტეთ, ამ ქცევათაგან რომელი სჭირდება სერვისს, მონიშნეთ ვის ეკუთვნის წესი, და დატოვეთ უფლებამოსილების დაყოფა დოკუმენტირებული პროფილის გვერდით და არა ვიღაცის ლაბორატორიის მეხსიერებაში.