ولې resolv.conf ستاسو د VPN DNS ښیي خو پوښتنې یې له پامه غورځوي

په لاګونو کې هیڅ غلط نه ښکاري: انټرفیس فعال دی، حل کوونکی د VPN د DNS سرور راپور ورکوي، او په ډیسک کې فایل هغه لیست کوي۔ بیا هم یو داخلي کوربه نوم لاهم د سیمه ایز روټر له لارې حل کیږي۔ دا درې بیانونه یو بل سره متناقض نه دي، ځکه چې فایل، د هرې نښلنې حالت او د پوښتنې لاره بېل شیان دي چې په تصادفي ډول یو نوم شریکوي۔ لاندې هغه لاره ده چې پوښتنه په systemd-resolved لرونکي کوربه کې په رښتیا تېروي۔

درې شیان چې resolv.conf نومیږي

د resolved لرونکي کوربه په /etc/resolv.conf معمولاً د /run/systemd/resolve/stub-resolv.conf لپاره سمبولیک لینک وي۔ هغه هدف د سیمه ایز stub اورېدونکي پته، 127.0.0.53، او د resolved لخوا حساب شوي لټون ډومینونه لري۔ دا د حالت انځور دی، نه خپله حالت۔

حالت د resolved په هرې نښلنې کنفیګریشن کې ژوند کوي، ځکه نو resolvectl status له فایل سره اختلاف کولی شي او بیا هم سم وي۔ هره نښلنه خپل سرورونه او خپل د لارښوونې ډومینونه لري، او کله چې پوښتنه راشي stub هغه معلومات ګوري۔ د systemd-resolved لارښود جوړ شوي فایلونه او د هرې نښلنې ماډل بیانوي؛ د انځور او حالت جلا کول هغه برخه ده چې په یاد ساتلو ارزي۔ د سمبولیک لینک هدف بدلول هغه څه بدلوي چې دودیز کلاینټونه یې لولي، نه هغه څه چې حل کوونکی یې پېژني۔

دریم شی، /run/systemd/resolve/resolv.conf، هره نښلنه په یوه سرور لیست کې هواروي۔ هغه فایل ته اشاره کوونکی پروګرام پوښتنې مستقیم لیست شوو سرورونو ته لیږي او stub پرېږدي، نو د هرې نښلنې پالیسي نور پر هغه نه تطبیق کیږي۔ ځکه نو په یوه ماشین کې دوه پروګرامونه کولی شي یو نوم بېل ځواب کړي، او هیڅ یو یې خراب نه دی۔

د NSS له لارې یوه پوښتنه تعقیب کړئ

glibc د /etc/nsswitch.conf لوستي تر څو پریکړه وکړي چې نوم ته څوک ځواب وایي۔ هغه hosts کرښه چې resolve لري پوښتنه nss-resolve ته لیږي، هغه له resolved څخه د D-Bus له لارې پوښتنه کوي او د هرې نښلنې ځواب ترلاسه کوي۔ یوازې files dns لرونکې کرښه پوښتنه هغه پتې ته لیږي چې /etc/resolv.conf یې لري۔

همدا یوه کرښه د براوزر او dig ترمنځ ډېری اختلافونه تشریح کوي۔ dig په مستقیم ډول resolv.conf لولي او هیڅکله NSS ته نه ورسیږي، نو د اپلیکیشن کارول شوې لارې پرځای stub یا پورتنۍ سرور ازموي۔ getent hosts internal.example د NSS له لارې تېریږي، او د هغې ځواب د dig له ځواب سره پرتله کول لومړنی ګټور اندازه کول دي۔

هغه اپلیکیشنونه چې خپل حل کوونکی لري، یا له ثابت پای ټکي سره د HTTPS له لارې DNS وایي، دواړه لارې پرېږدي۔ په resolv.conf یا د resolved په حالت کې هیڅ شی دوی محدود نه کوي۔

وګورئ فایل د چا دی او چېرته اشاره کوي

له هر څه بدلولو مخکې د لینکونو زنځیر ولولئ، ځکه مالکیت ټاکي چې کوم فایل معتبر دی۔ لاندې هر حکم یوازې حالت لولي۔

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

لومړی کرښه لینک او د هغې هدف یو ځای چاپوي، او د VPN سکریپټ مالکیت لرونکی عادي فایل معنا دا ده چې حل کوونکی هغه لیکنه هیڅکله د ننوتلو په توګه نه ګڼي۔ د حالت پایله د هرې نښلنې سرورونه او هغه د لارښوونې ډومینونه لیست کوي چې ټاکي هره پوښتنه چېرته ځي۔ د nsswitch کرښه وایي چې stub ته په بشپړ ډول مراجعه کیږي که نه، نو په فایل کې stub پته او هلته resolve نه وي معنا دا ده چې پوښتنې سیمه ایز اورېدونکي ته رسيږي خو تقسیم هیڅوک نه مدیریتوي۔ هغه وروستی لیست هم مهم دی، ځکه پرته له stub-resolv.conf کوربه دې ته ورته ترتیب نه چلوي۔

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

د لینک د مالک په خوا کې سمول

VPN نښلون باید خپل سرورونه او ډومینونه په خپله نښلنه کې ثبت کړي، بیا یې د قطع کېدو پر مهال بیرته واخلي۔ د NetworkManager resolved ادغام او د کلاینټ خپل مرستندوی دواړه همداسې کار کوي؛ یوازې resolv.conf بیا لیکونکی سکریپټ داسې نه کوي۔

په لا دمخه موجوده نښلنه کې د چلېدو وخت تنظیمات میکانېزم ښیي۔ resolvectl dns tun0 10.40.0.53 یو سرور نښلوي، او resolvectl domain tun0 '~corp.example' یو د لارښوونې ډومین نښلوي۔ ټیلډا (~) هغه توری دی چې بار وړي: د هغه پسوند پوښتنې یوازې دې نښلنې ته محدودوي او نور هر څه په ارامه پرېږدي، خو پرته له هغې هماغه ارزښت د لټون ډومین کیږي او تقسیم بخاریږي۔ هغه پتې د لابراتوار بېلګې دي، نه تلپاتې تنظیم۔ د resolvectl query host.corp.example سره تایید کړئ او ولولئ کومه نښلنه ځواب ورکړ۔

ثبت شوی سرور بیا هم لار ته اړتیا لري۔ کله چې پوښتنه سمې نښلنې ته ورسیږي او وخت یې پای ته ورسیږي، نو نقص د حل کوونکي په مالکیت کې نه، بلکې د تونل له لارې د رسېدو توان کې دی۔

کاري حالت څنګه ښکاري

روغه پایله په درېیو انځورونو کې سره سمه ده: د هرې نښلنې سرورونه د VPN له خوا ورکړل شوو سره سمون لري، د لارښوونې ډومینونه یوازې داخلي پسوندونه پوښي، او مهم اپلیکیشن داخلي نوم حلوي خو عامي نوم لا هم سیمه ایزه لاره تعقیبوي۔ یوه بریالۍ پوښتنه له دې همغږۍ څخه کم څه ثابتوي۔

بیا قطع کړئ او دواړه پوښتنې تکرار کړئ۔ هغه کلاینټ چې له مینځه وړلو وروسته خپل ډومینونه ثبت پاتې کوي ماشین جوړوي چې څو ساعته وروسته په داخلي لټونونو کې ناکاميږي، پرته له خلاص تونل او پرته له ښکاره لامل۔