هغه دوه لینکس خدمتونه ودروئ چې د /etc/resolv.conf لپاره سیالي کوي

DNS بیا بیا خپل پخواني حالت ته راستنېږي، د VPN بیا نښلېدل ستاسو سمون باطلوي، او په پای کې په ټیم کې څوک د فایل د بندولو وړاندیز کوي. دا ترتیب نښه ده، حل نه: دوه برخې دواړه فکر کوي چې /etc/resolv.conf د دوی دی، او هغه څوک چې وروستی لیکي ګټي. د فایل بندول د مالکیت شخړه نه حل کوي، یوازې یې پټوي او په هماغه وخت کې هغه برخه ماتوي چې تاسو واقعاً غوښتله. لاندې څلور څېړنې په ترتیب سره وکړئ او ترتیب په هغه کچه سم کړئ چې مالکیت یې لري، نه په فایل.

څېړنه 1: آیا دا سمبولیک لینک دی، او چېرته

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

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

د systemd-resolved د stub لارې ته لینک یعنې د فایل منځپانګه جوړېږي، او لاسي سمون به په راتلونکې پېښه کې پرې لیکل شي. nameserver کرښې لرونکی عادي فایل معمولاً هغه کلاینټ یا DHCP هنګ یې لیکي چې د نښلېدو پر مهال چلیږي. دواړه قانوني دي؛ مهمه دا ده چې له هر څه بدلولو مخکې پوه شئ کوم یو لرئ.

څېړنه 2: کوم ډیمون چلیږي

هغه څه ومومئ چې واقعاً فعال دي، نه هغه څه چې نصب دي. په عصري وېش کې څو حل کوونکي کېدای شي وي، او هغه چې په loopback انټرفېس کې پورټ 53 نیسي هغه ځواب ورکوي:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

د حالت پایله د هرې اړیکې DNS سرورونه او د لارښوونې ډومېنونه نوموي، چې د split DNS لپاره اړین نقشه ده. که داخلي نومونه باید داخلي سرور ته لاړ شي او پاتې ټول عمومي سرور ته، نو هغه تګلاره د هرې اړیکې په ډومېنونو کې ژوند کوي، او په فایل کې د ثابت nameserver لیست ته یې برابرول هغه توپیر په خاموشۍ له لاسه ورکوي.

د NetworkManager خپله ترتیبېدنه فیصله کوي چې له دغو backend-ونو کوم یو کاروي. په اصلي ترتیبېدنې فایل کې د هغې dns= ترتیبېدنه د هغې داخلي حل کوونکي، dnsmasq، systemd-resolved او none ترمنځ غوره کوي، او وېش ممکن ستاسو په استازیتوب غوره کړی وي. په دې هوسټ باندې د “DNS سمولو” مانا ټاکلو مخکې هغه ترتیبېدنه ولولئ.

څېړنه 3: VPN کلاینټ ته د څه لیکلو اجازه ده

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

د WireGuard حالت په بڼه ورته دی: د انټرفېس ترتیبېدنه پخپله DNS نه اداره کوي، د هغې شاوخوا وسایل یې کوي، د حل کوونکي مرستندوی یا resolved یوځایوالی له لارې. که دوه داسې مرستندویان نصب وي، دواړه به د نښلېدو پر مهال خپل نړیوال لید تطبیق کړي.

د اټکل کولو پرځای د کلاینټ up او down هنګونه ولولئ. په /etc/openvpn/up.sh یا ورته فولډر کې څو کرښې shell هغه چلند تشریح کوي چې که نه نو تصادفي ښکاري، او هماغه ځای دی چې کلاینټ کولای شئ له سیالۍ پرځای همکارۍ ته اړ کړئ.

څېړنه 4: دا د مالک سره سم کړئ، په فایل کې نه

کله چې مالک وپېژندل، DNS د هغه مالک د ملاتړ شوي انټرفېس له لارې ترتیب کړئ. د systemd-resolved لپاره دا یعنې د ثابت فایل پرځای د هرې اړیکې ترتیبات او د لارښوونې ډومېنونه؛ د NetworkManager لپاره یعنې د نښلېدو پروفایل DNS ترتیبات او غوره شوی backend؛ د resolvconf یوځایوالی کاروونکي وېش لپاره یعنې د هغه مرستندوی له لارې لیکل.

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

چېرته چې دوه برخې واقعاً باید یوځای ژوند وکړي، دواړو ته بېل کارونه ورکړئ. شبکه مدیر ته د انټرفېس کچې ترتیبېدنې مالکیت ورکړئ، VPN کلاینټ ته اجازه ورکړئ چې د هماغه یوځایوالي له لارې د هرې اړیکې DNS او ډومېنونه زیات کړي، او هغه درېیم سکریپټ لرې کړئ چې فایل مستقیم لیکي. د systemd-resolved اسناد هغه حالتونه بیانوي چې ملاتړ یې کوي او هر یو یې په /etc/resolv.conf کې څه ښکاره کوي. هغه حالت وټاکئ چې ستاسو د ساتلو تګلارې اندازې سره سمون لري. که split DNS مهم وي، د هرې اړیکې ډومېنونو سره stub ترتیب هغه ساتي، خو هغه حالت چې upstream سرورونه په فایل کې کاپي کوي هغه په خاموشۍ برابروي.

له بیا نښلېدو وروسته تصدیق کړئ، د سمون وروسته نه

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

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

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

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