د خپل Mac په VPN کې کارېدونکي DNS حل کوونکي څنګه وګورئ

scutil --dns هغه د حل کوونکي ترتیبات چاپوي چې macOS واقعاً ورسره مشوره کوي، نه هغه یوازینی DNS سرور چې تاسو په تنظیماتو پینل کې ټایپ کړی و. پایله د ډېرو خلکو له تمې اوږده ده، ځکه چې سیسټم د ډیفالټ لار، د سکاپ شوو انټرفېسونو او د ډومین ځانګړي لېږد لپاره جلا د حل کوونکي بلاکونه ساتي. د پایلې په سر کې بلاک اړینه نه ده چې هغه وي چې پوښتنې ته ځواب ورکوي. که یو شخصي نوم په دفتر کې حل شي او د VPN پورته کېدو سره سم ناکام شي، ناسم والی د میټینګ قواعدو او لارو کې دی، د سرور په پته کې نه. لومړی ترتیب ولګوه، بیا په ریښتیني لټون سره ځواب ثابت کړه.

له پتو مخکې د بلاکونو ترتیب ولګوه

هره ننوتنه په resolver #N پیلېږي او nameserver[0]، کله ناکله if_index، یوه flags کرښه، reach او کله چې بلاک ساده ډیفالټ نه وي، domain او د search domain لیست ښیي. پرته له ډومین 1 نمبر حل کوونکی هغه ډیفالټ دی چې عام نومونه سمبالوي. هر هغه څه چې په خپلو بیرغونو کې Scoped لري له هغه انټرفېس سره تړلی دی چې if_index نوم ورکوي، او هر هغه څه چې په Supplemental نښه شوي یوازې د هغې لاندې لیست شوو ډومینونو لپاره تطبیقېږي.

غوښتنلیک د پایښت میټینګ دی. د intranet.corp.example په څېر نوم لپاره، macOS هغه حل کوونکی غوره کوي چې domain ننوتنه یې تر ټولو اوږده میټه کېدونکې پایښت وي، نو د domain : corp.example لرونکی بلاک حتی د پایلې په ډېره برخه کې وي هم ډیفالټ ته بریالي کېږي. د یوې اندازې ډومینونو ترمنځ برابري order پرېکوي. لومړي کتلو ته ډېر ځله له دې زیات نه وي: ټوله پایله کله چې یو بلاک له سره تر پایه ولګوه، پیل کرښې د بلاکونو ترتیب زده کړې لپاره، او یو فلټرشوی پړاو چې د بلاک سرلیکونه د ساحې کرښو ترڅنګ چاپوي. سکاپ شوي بلاکونه د خپل سرلیک لاندې ښکاري او د پورتنیو لیست د دوام په څېر لوستل کېږي، نو هر کله چې پایله نقل کوئ یو سرلیک په نظر کې وساتئ.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

if_index له تونل انټرفېس سره وتړئ

یو انډېکس یوازې هغه وخت ګټور دی چې د هغه شاته انټرفېس نومولی شئ. scutil --nwi هغه شبکه معلومات لیستوي چې سیسټم ساتي، په شمول لومړني انټرفېس او رسېدنه، په داسې حال کې چې ifconfig -l تاسو ته نومونه درکوي، چېرې چې utun0 تر utun9 هغه تونل نوماندان دي چې یو کلاینت معمولاً جوړوي. Apple scutil --dns د خپل معیار د نمونې په توګه د ځای پرځای کولو لارښود کې کاروي، او مستند کوي چې Network Extension څنګه غوره شوي ډومینونه غوره شوو حل کوونکو ته استولی شي، هماغه میکانیزم چې هغه سکاپ شوي بلاکونه ښکاره کوي.

هغه پلټنه چې پوښتنه پرېکوي دا ده چې آیا حل کوونکی د تونل په نصب کړې لار پروت دی:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

که route -n get داسې دروازه او انټرفېس بېرته راوړي چې د حل کوونکي له ننوتې سره نه ځي، پته کېدای شي کاملاً سمه وي او بیا هم نه رسېدونکې. یو ووېشل شوی تونل چې یوازې شرکتي فرعي شبکې وړي، هغه پوښتنې غورځوي چې د هغوی بهر DNS سرور ته روانې دي، او ناکامي د وخت ختمېدو په بڼه ښکاري، نو ځکه د ترتیباتو پایله لا هم پاکه ښکاري.

له سیسټم حل کوونکي وپوښتئ، بیا له سرور

درې وسایل درې جلا پوښتنو ته ځواب وايي، او د دوی ګډول د دې برخې ډېری غلطې پایلې جوړوي. dscacheutil -q host -a name د هغه هماغه سیسټم حل کوونکي له لارې ځي چې عادي اپلیکیشنونه کاروي، نو سکاپ شوي او بشپړونکي بلاکونه تطبیقېږي. پرته له سرور دلیل dig /etc/resolv.conf لولي، کوم چې په macOS کې د سکاپ شوې حل لپاره د حقیقت سرچینه نه ده، او د هر ډومین قواعد په بشپړه توګه پرېږدي. dig @address په دقیقه توګه یو سرور ته رسېږي او د غوښتنلیک په اړه هېڅ نه وايي.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

کله چې لومړی امر ځواب وايي او دویم NXDOMAIN بېرته راوړي، تاسو هغه ووېش چې لټوئ وموند او هېڅ خراب نه دی. کله چې لومړی د وخت ختمېدو ته رسېږي او dig @10.20.0.53 ځواب وايي، حل کوونکی کار کوي خو د تونل په غوره شوې لار کې نه رسېدونکی دی، نو بل ګام د DNS تنظیماتو بدلول نه، بلکې route -n get دی. شخصي نومونه له هر هغه څه بهر وساتئ چې په ټیکټ یا شریک یادښت کې یې ږدوئ.

پایله څه نه شي کولی تاسو ته وښیي

د حل کوونکو لیست له پورته یا څنګ څو طبقې ناستې دي، او هر یو کېدای شي پوښتنه هغې ځای ته واستوي چې پایله یې هېږه نه یادوي. د خوندي DNS سره براوزر کېدای شي د خپل کوډ شوي چینل له لارې حل کړي، نو هغه پاڼه چې د dscacheutil د وخت ختمېدو پر مهال لوړېږي تناقض نه دی. د امنیتي سافټویر لخوا نصب شوی DNS پراکسي د Network Extension برابرونکي په توګه ځي او پوښتنې پخپله لېږدوي، او scutil --dns ښیي چې څه تنظیم شوي وو، نه هغه پورتني پته چې پراکسي په پای کې کارولې وه. د لټون ډومینونه درېیم چینج ورزیاتوي: نیمګړي نوم ته هره لیست شوې پایښت په ترتیب سره ورزیاتېږي، نو ځواب ورکوونکی بلاک کېدای شي هغه وي چې تاسو هېږه شک نه ورباندې کړی.

زاړه ځوابونه تر ټولو ارزانه څه دي چې وایستل شي او تر ټولو زیات پریښودل کېږي:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

که له فلش وروسته پایله بدله شي، حالت په کیش کې و او پخوانۍ پایله داسې تونل بیانوه چې نور نه و. که بدله نه شي، ترتیبات هماغه دي چې دي، او پوښتنه لارو او د اپلیکیشن پالیسۍ ته ځي.

د مخکې او وروسته لپاره لنډ لارښود

بېسلاین یوازې هغه ځای واخلئ چې پالیسي اجازه ورکوي، او فایلونه له هرې همغږې شوې پوښۍ بهر وساتئ. لاندې ترتیب هماغه دی چې زه په کلاینت ماشینونو کې چلوونکی یم: بېسلاین واخلئ، وصل شئ، بیا واخلئ، بیا پرتله او پلټنه وکړئ.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

توپیر د کرښو پر ځای د بلاکونو له مخې ولګوه. نوی سکاپ شوی حل کوونکی چې د تونل انټرفېس انډېکس او د شخصي پایښت لپاره domain ننوتنه وړي هغه تمه شوې بڼه ده. نوی ډیفالټ حل کوونکی چې عام پتې ته اشاره کوي هغه موندنه ده چې د کلاینت پروفایل مالک ته د راپور ورکولو ارزښت لري. بیا لټون په هغه اپلیکیشن کې تکرار کړئ چې واقعاً ناکام شو، نه یوازې په شیل کې، او د پایلې ترڅنګ د route -n get انټرفېس ولیکئ.

د بدلون بېرته اخیستلو لپاره قطع کړئ او د بېسلاین اخیستل تکرار کړئ. که سکاپ شوی بلاک ولاړ، کلاینت خپل ځان پاک کړ. که بلاک لا هم د هغه انټرفېس پر وړاندې لیست شوی وي چې نور نه دی، حالت زاړه دی، او مخکې له دې چې یو څوک پروفایل ته لاس وروړي، فلش او بیاځلي نښلول تر ټولو نرم سمون دی.

په دې ترتیب څلور پلټنې: آیا یو حل کوونکي بلاک د نوم تر ټولو اوږدې پایښت سره ځي؛ آیا هغه بلاک د تونل نصب کړي انټرفېس سره تړلی دی؛ آیا د هغه د نوم سرور ته لار تونل کاروي؛ او آیا د سیسټم حل کوونکی، نه dig، ځواب بېرته راوړي. لومړۍ ناکامه پلټنه تاسو ته وايي چې DNS پالیسي، د تونل لارې که اپلیکیشن بدل کړئ. که څلور واړه تېر شي او نوم بیا هم ناکام شي، ستونزه د DNS له پاسه ده، او بل څه چې باید وکتل شي هغه هر څه دي چې د هغه مخ ته پورټ 53 ته ځواب وايي.