د VPN DNS کار کوي، خو .local نومونه لا هم ناکامېږي: څوک یې حل کوي؟

په یوه VPN کې دوه ماشینونه، یو شان کوربه نوم، او یوازې یو یې حل کوي: توپیر معمولاً په تونل کې نه دی، بلکې په دې کې دی چې کوم حلونکی ځواب ورکړ. د Linux په ډیسکټاپ کې دا نوم د نوم خدمت سویچ، د systemd-resolved stub، یا د هغه حلونکي له لارې تېرېدلی شي چې اپلیکیشن له ځان سره راوړی، او هر یو یې پر هماغه سافکس خپله قاعده پلي کوي. قواعد په هماغه سافکس کې جلا کېږي، ځکه .local بې طرفه لیبل نه دی. د دې مخکې چې د هر څه د چلېدو ترتیب بدل کړئ، ومومئ چې ناکامه پروګرام واقعاً کومه لاره نیسي.

دوه حلونکي، دوه مختلف ځوابونه

دودیز glibc لټون د nsswitch.conf د hosts: کرښې له لارې ځي او هر ماډل په نوبت پوښتنه کوي تر څو یو ځواب ورکړي. هغه کلاینټ چې د stub اورېدونکي له لارې له systemd-resolved سره خبرې کوي، پر ځای یې یوازې یوه پروسه پوښتنه کوي، او هغه پروسه د هر تړون لپاره تګلاره او خپل ځانګړي حالتونه پلي کوي. هغه اپلیکیشن چې خپل حلونکی راوړي یا داسې کتابتون تړي چې دا کار کوي، کولی شي دواړه له پامه وغورځوي. نو یو کوربه نوم کولی شي په یوه ماشین کې درې مالکان ولري، او یوازې یو یې پوهېږي چې VPN څه غوښتل.

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

کوم حکم واقعاً ستاسو حلونکی وپوښت

دوه یوازې لوستلو حکمونه اړوندو پوښتنو ته ځواب ورکوي، او د دوی پرتله کول ستونزه له ترتیب لوستلو څخه ژر ځای پر ځای کوي. ریښتینی داخلي نوم وکاروئ او پایله خصوصي وساتئ، ځکه داخلي ریکارډونه داخلي پاتې کېږي. دواړه په هماغه غونډه کې چل کړئ چې ناکامه پروګرام پکې چلېږي:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

لومړی د ترتیب شوو ماډلونو له لارې پوښتنه کوي، چې عادي پروګرام همدا تجربه کوي. دویم په مستقیم ډول systemd-resolved پوښتنه کوي او هغه تړون، پروتوکول او سرور راپور کوي چې ځواب یې ورکړ. سرور ته د پتې له مخې پوښتنه یوازې دا ثابتوي چې سرور ریکارډ لري، ځکه د دې په اړه څه نه وایي چې اپلیکیشن کله هم پوښتلی که نه. هغه تړون چې VPN وړونکی دی او هغه ډومینونه چې ادعا یې کوي ولولئ، بیا هغه لیست له ناکام نوم سافکس سره پرتله کړئ.

ولې .local ستاسو unicast زون پرېږدي

د systemd-resolved حواله وایي چې د .local سره پای ته رسېدونکي څو لیبله نومونه، کله چې mDNS فعال وي، معمولاً عادي unicast DNS ته نه، بلکې multicast DNS ته ځي. RFC 6762 هغه نوم ځای link-local multicast لپاره بېل ساتي، نو یو شرکت زون کولی شي سم ریکارډ ولري چې د هغه سافکس لپاره هیڅکله نه پوښتل کېږي. تونل کولی شي حلونکی په بشپړ ډول لارښوونه کړي او بیا هم سیالۍ وبایلي. له کاش څخه بریالی ping د هماغه لټون په اړه چې اوس وشو، هیڅ نه وایي.

یو مستند استثنا شته، او د دې ډېری حالتونه حل کوي: کله چې تړون هغه سافکس د لټون ډومین یا لارښوونې ډومین اعلان کړي، ډیمون یې پر unicast لاره ساتي او د multicast ځانګړی حالت پرېږدي. دا د هر تړون تګلاره ده، نړیواله غوره توب نه. دوه ماشینونه چې یو شان VPN سرور لري کولی شي بېل چلند وکړي کله چې یو شبکه یی پروفایل ډومین اعلان کړي او بل یې نه، نو هغه پروفایل ولولئ چې فعال دی، نه هغه چې په یاد لدئ مو سم کړی.

تنگ استثنا نړیوال بیا ترتیب ته ماتې ورکوي

د یوه موجود زون لپاره چې نوم یې نشئ بدلولی، له حلونکي او VPN مالکانو وغواړئ چې ډومین په هغه اړیکه کې اعلان کړي چې دا یې وړي. د هماغه یوه سافکس لپاره د لارښوونې ډومین ننوتل او د ټاکل شوي سرور پته د نوم لرونکي مالک سره کوچنی بدلون دی، او له تړون سره ژوند کوي، نه په لاسي سم شوي فایل کې.

دا له قطعېدو هم ژغورل کېږي، ځکه د تړون تګلاره بیا پلي کېږي کله چې تړون بېرته راشي. د شریک nsswitch.conf سمول هغه هڅوونکې او ګرانه لاره ده، ځکه دا په ماشین کې د هر نوم لپاره د لټون چلند بدلوي، په شمول د سیمه ییز کشف. د multicast ډیمون غیر فعالول هم سره برابر نه دي: دا سیمه ییز چلند لرې کوي پر هیڅ حلونکي ته شرکت زون نه ښیي. که خدمت نوی وي نه میراثي، دا د خپل سازمان تر کنټرول لاندې فرعي ډومین لاندې کېږدئ او سیالۍ په بشپړه توګه پرېږدئ. تنگ استثنا هغه وخت وټاکئ چې نوم په فرم ویر کې ټینګ یا پر لیبل چاپ شوی وي، او نوی فرعي ډومین هغه وخت وټاکئ چې لا هم کلاینټ کنټرولوئ.

له بدلون وروسته څه باید ثابت شي

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

سمه پته له غلط سند سره لا هم سخت کلاینټ ناکاموي، نو کله چې حل کار وکړ، هغه نوم چې اپلیکیشن یې تمه لري وګورئ. تایید کړئ چې خدمت اړیکې نه یوازې د دفتر له حد څخه، بلکې د VPN له پتې هم مني. د ډومین حد، سرور او مالک د تړون په اسنادو کې ولیکئ. که نه، بل څوک چې له دې ناکامۍ سره مخ شي هماغه نړیوال سمون غواړي چې تاسو همدا اوس ترې ډډه وکړه.