ولې ستاسو د /etc/hosts ننوتنه د VPN DNS ته نه رسیږي

تاسو /etc/hosts ته یو نوم اضافه کړ، VPN ته و نښلیدل او تمه مو درلوده چې ریکارډ به هر چا ته ښکاره شي۔ داسې نه کیږي، او حیرانتیا معمولاً د دویمې نښې سره راځي: نوم ستاسو په ماشین کې حل کیږي او د همکار په ماشین کې ناکام کیږي، چې د خراب VPN DNS خدمت په څیر ښکاري او په حقیقت کې hosts فایل هغه څه کوي چې د هغې لپاره جوړ شوی و۔ hosts فایل د نوم د حل محلي ترتیب دی، نه د زون تازه کول، او په نورمال VPN اړیکه کې هیڅ شی هغه نه پورته کوي۔

Hosts محلي پوښ دی، نه د زون تازه کول

فایل د نقشو هغه لیست دی چې د نوم خدمت کتابتونونه یې د DNS سرور څخه د پوښتنې دمخه یا د هغې پرځای ګوري۔ 10.40.0.20 build.corp.example په څیر کرښه بدلوي چې په هماغه یو ماشین کې غوښتنلیکونه څه پایله کوي۔ هغه ریکارډ نه جوړوي، د تونل له لارې نه ځي، او هغه DNS سرور چې تونل ورته اشاره کوي د هغې د شتون هیڅ خبر نه لري۔

له همدې امله ناکامي غیر متوازنه ده۔ ستاسو کلاینټ له فایل څخه ځواب ترلاسه کوي۔ بل کلاینټ د VPN DNS سرور څخه پوښتنه کوي، چې هیڅ نه بېرته ورکوي، او غوښتنلیک راپور ورکوي چې نوم شتون نه لري۔ دواړه ماشینونه سم چلند کوي؛ یوازې یو یې داسې پوښ لري چې بل هیڅکله نه دی لیدلی۔

دوه کمانډونه، دوه جلا برخې

د دې بحث د بندولو ترټولو ګړندې لاره دا ده چې توپیر په دوو کمانډونو کې ښکاره کړئ، دواړه د hosts ننوتنې لرونکي کلاینټ په سر چلیږي:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

لومړی د سیستم خپل د لټون لاره پوښتنه کوي، چې په عادي glibc سیستم کې د DNS څخه دمخه محلي فایلونه لولي۔ دویم په مستقیم ډول هغه آدرس ته DNS پوښتنه لیږي او محلي فایلونه هیڅ نه ګوري۔ کله چې لومړی ستاسو ننوتنه بېرته راوړي او دویم NXDOMAIN راوړي، تاسو ثابته کړې چې ریکارډ په DNS کې نشته او ستاسو ماشین له محلي پوښ څخه ځواب ورکوي۔

ترتیب د تنظیم وړ دی، او د یوې ځانګړې وېشنس په اړه د هر څه پایله کولو دمخه یې کتل ارزښت لري۔ /etc/nsswitch.conf کې hosts: کرښه وګورئ؛ hosts: files dns لومړی فایلونه ګوري۔ یوازې د ترتیب د بدلولو لپاره هغه بېلګه په کار کوونکي ترتیب باندې کاپي مه کوئ، ځکه چې ریښتیني سیستمونه ډیری وخت هغه اضافي سرچینې او شرطي خدمت ننوتنې لیستوي چې بېلګه یې نه لري۔

systemd-resolved ازموینه خړوبوي

په داسې سیستم کې چې systemd-resolved کاروي، محلي stub هم له hosts ډیټابیس څخه نومونه وړاندې کوي۔ له همدې امله 127.0.0.53 ته پوښتنه د لیرې سرور خپلواکه ازموینه نه ده، که څه هم د DNS پوښتنې په څیر ښکاري او همداسې چلند کوي۔ تاسو کولی شئ تصدیق کړئ چې حل کوونکی څه پوهیږي او کوم سرورونو ته به پوښتنه وکړي په دې سره:

resolvectl query build.corp.example
resolvectl status

د status پایله د هرې اړیکې لپاره DNS سرورونه نوموي، او په دې توګه پوهیږئ چې VPN اړیکې په اصل کې حل کوونکی ترلاسه کړی که نه۔ هغه پوښتنه له hosts ننوتنې جلا ده او هغه پوښتنه ده چې د پوښتنې وړ ده کله چې شخصي نوم یو کس ته نه بلکې هر کارونکي ته ناکام شي۔

غوښتنلیکونه کولی شي بله طبقه هم اضافه کړي۔ هغه براوزر چې خپله DNS-over-HTTPS ترتیب لري، هغه کنټینر چې خپل حل کوونکي ترتیب لري، یا هغه چلند چاپیریال چې د پروسې په ټول ژوند کې لټونونه کاش کوي، هر یو کولی شي د سیستم څخه توپیر لرونکی ځواب ورکړي۔ د دې پرځای چې فرض کړئ یو کمانډ په ماشین کې هر پروګرام بیانوي، هغه غوښتنلیک وازموئ چې تاسو ته مهم دی۔

په VPN کې نوم په حقیقت کې څه شریکوي

که شخصي نوم باید د هر چا لپاره کار وکړي، نو داسې مالک ته اړتیا لري چې د هر چا حل کوونکی ورته ورسي۔ پاک ځواب دا دی چې ریکارډ په مدیریت شوې زون کې خپور کړئ او هغه زون د VPN د پام شوي DNS لارې له لارې د حل وړ کړئ۔ بیا ریکارډ یو حقیقت سرچینه، د پوښتنې تعقیب او ژوند دوره لري، او هیڅوک باید یاد نه کړي چې کوم لیپ ټاپ محلي پوښ لري۔

hosts فایلونه توزیع کول قانوني بدیل دی، او دا د نوم خدمت نه بلکې د پای نقطو مدیریت دی۔ که تاسو هغه غوره کړئ، فایل باید د فلیټ مدیریت کوونکي لخوا ځای پرځای، نسخه بندي او لرې شي، او په ډیزاین کې باید همداسې بیان شي۔ «VPN یې سمبالوي» د هغه بهیر بیان نه دی۔

ډینامیک DNS ثبت دریم میکانیزم دی، چې خپلې اجازې، د تازه کولو تصدیق او د ریکارډ ژوند لري۔ هغه له hosts ننوتنې څخه نه راځي، او یوازې د کلاینټ له نښلیدو هم نه راځي، پرته لدې چې سرور او کلاینټ دواړه د دې لپاره تنظیم شوي وي۔ هغه ریکارډ چې پخپله ښکاري د دې نښه ده چې یو چا خوندي تازه کول فعال کړي او یو کلاینټ ځان ثبتوي، او هغه ترتیب د ستونزې حل تار ته نه بلکې د ډیزاین ریکارډ ته اړه لري۔ که هیڅوک ونه تواني ووايي چې د هغه ترتیب مالک څوک دی، اتوماتیک ریکارډ غیر تایید شوی وګڼئ او مدیریت شوې زون د حقیقت سرچینه وساتئ۔

حل شوی نوم لار نه ده

د نومونو حل او د رسیدو وړتیا جلا دي، او زوړ محلي نقش د دوی د ګډولو کلاسیکه لاره ده۔ هغه hosts ننوتنه چې لیږدول شوي آدرس ته اشاره کوي، به د DNS له سمولو وروسته هم اوږد وخت زوړ کوربه غوره کوي، او نښه د ښه حل کیدونکي نوم په اړه د لارښوونې ناکامۍ په څیر ښکاري۔

نو کله چې راپور «نوم حل کیږي خو خدمت ته رسیدل ناشونې ده» وي، د سیستم لټون د VPN DNS سرور ته د یوې ښکاره پوښتنې سره پرتله کړئ، بیا هغه آدرس چې ترلاسه کړی یې د هغه آدرس سره وګورئ چې خدمت واقعاً کاروي۔ د systemd-resolved حواله هغه محلي سرچینې مستند کوي چې هغه ګوري، او د دې پرتلې لپاره اړین نقشه هماغه ده۔

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