په یوه اډاپټر کې دوه 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 پروفایل کولای شي د نوم ځای قواعد یوسي او وټاکي چې آیا د نښلونې وروسته پاتې کېږي؛ هغه قاعده چې حل کوونکی نا رسېدونکی وي او بیا هم پاتې کېږي، مراجعین د مړ سرور غوره کولو ته پرېږدي، او د نښلونې پورې محدوده قاعده د تونل سره ورکېږي۔ پریکړه وکړئ چې دغو چلندونو کې کوم یو خدمت ته اړین دی، په نښه کړئ چې قاعده د چا ده، او د واک وېش د چا د لابراتوار په یاد کې نه، بلکې د پروفایل ترڅنګ مستند پرېږدئ۔