Մեկ ադապտերի վրա երկու 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 պրոֆիլը կարող է կրել անվանատարածքների կանոնները և ընտրել՝ արդյոք դրանք մնում են միացումից հետո՝ այն կանոնը, որը մնում է, երբ լուծիչն անհասանելի է, ստիպում է հաճախորդներին նախընտրել մեռած սերվեր, իսկ միացմանը սահմանափակված կանոնը անհետանում է թունելի հետ։ Որոշեք, թե այս վարքերից որն է անհրաժեշտ ծառայությանը, նշեք՝ ումն է կանոնը, և լիազորության բաժանումը թողեք փաստագրված պրոֆիլի կողքին, ոչ թե ինչ-որ մեկի լաբորատորիայի հիշողության մեջ։