د resolv.conf سمون د VPN له نښلولو وروسته DNS نه سموني

تاسو VPN نښلنئ، ping 1.1.1.1 لا هم ځواب ورکوي، او هر د نوم پوښتنه ځوړند پاتې کېږي تر څو چې پاڼه بالاخره تسلیم شي. بیا cat /etc/resolv.conf داسې نوم سرور ښیي چې یوازې د ټنل په داخل کې شتون درلود، معمولاً د لیست په سر کې. هغه کرښه پاکول د لسو دقیقو لپاره یې سمول ښکاري، تر څو چې خوب، د Wi-Fi ګرځېدل یا بیا پیل یې بېرته راوستل. هغه فایل چې تاسو سمولی هغه تنظیم نه دی؛ هغه د اړیکې د حالت انځور دی چې بله برخه یې مالک ده.

ولې یوه زړه ثبتې هرې پوښتنې ته ثانیې لګوي

د glibc حل کوونکی د نوم سرورونو لیست په ترتیب سره ګرځي او د بل هڅولو دمخه د وخت تېرېدو انتظار کوي، او resolv.conf(5) هغه لیست درې ثبتو ته محدودوي. د ټنل له تللو وروسته د ټنل خوا ته حل کوونکی لکه 10.8.0.1 د لیست په سر کېږدئ، نو هره پوښتنه د ځواب ورکوونکي سرور ته له رسېدو دمخه د وخت تېرېدو بیه پرې کوي. دا لامل دی چې نښه د DNS غلطۍ پرځای د مړې اړیکې په څېر ښکاري: براوزرونه بندېږي، وخت ورته تېرېږي او کله ناکله یو کیش شوی پته وړاندې کوي چې وروسته زړېږي.

دا هم روښانه کوي چې ولې شکایت «انټرنیټ خراب شوی» په بڼه راځي. IP پتې ته ping ثابتوي چې اړیکه سمه ده، او دا خرابي د اپلیکیشن په څېر ښکاره کوي. د حل کوونکو لیست لومړی شی دی چې لوستل یې باید او وروستی شی دی چې سمول یې باید.

افسانه: resolv.conf د تنظیماتو فایل دی

د بدلولو دمخه وپوښتئ چې دا لار په رښتیا څه ده:

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

په systemd-resolved کوربه کې دا د 127.0.0.53 ته اشاره کوونکي stub فایل ته سمبولیک تړاو دی، او ریښتیني سرورونه په هرې اړیکې حالت کې ژوند کوي چې resolvectl چاپوي. په NetworkManager کوربه کې دا کېدای شي هغه فایل وي چې NetworkManager د فعالې اړیکې څخه لیکي. په ځینو پلورونکو کلاینټونو کې دا ساده فایل دی چې د نښلېدو پر مهال په هماغه ځای کې بیا لیکل کېږي او، که بختور نه یاست، د نښلونې پر مهال هیڅکله بحال نه کېږي. دا درې جلا مالکان دي، او لومړني دوه په لاس سمول یا هیڅ نه کوي یا تر بلې شبکې پېښې پورې دوام کوي.

resolvectl status هغه لید دی چې رښتیا وایي: د هرې اړیکې DNS سرورونه، د لارښوونې ډومینونه، او ایا د ټنل اړیکه لا شته. resolvectl query example.com نور وړاندې ځي او ښیي چې کومه برخه ځواب ورکړ. فایل ته له لاس وهلو دمخه دواړه وکاروئ، او په یاد ولرئ چې خپل خوندي DNS لرونکی براوزر دا ټول له پامه غورځوي.

د هر څه سمولو دمخه مالک ومومئ

معمولاً درې برخې د یوې تنظیم لپاره سیالي کوي: systemd-resolved، NetworkManager او هغه څه چې VPN کلاینټ نصب کړي. لومړی ژوندی یې وپېژنئ:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

که resolved فعال وي او سمبولیک تړاو د هغه stub ته اشاره کوي، نړیوال فایل جوړ شوی پایله ده او ستاسو سمون یوازې ښکارېدونکی دی. که NetworkManager د اړیکې مالک وي، سرورونه د اړیکې پروفایل پورې اړه لري، نو سمون د فایل سمون نه بلکې د nmcli ځانګړنې بدلون دی. که د پلورونکي ډیمون روان وي، یوازې د هغه خپله بحالي لار تر بلې نښلونې ژوندي پاتې کېږي.

هغه اړیکه حالت پاک کړئ چې کلاینټ پرېښی دی

وژل شوی کلاینټ نشي کولی خپل پاکولو هنګ وګرځوي. SIGKILL په بشپړه توګه نه نیول کېږي، خو SIGINT او SIGTERM نیول کېږي، نو هغه ټنل چې د زورواکي وژنې وروسته «یوازې ودرېد» ډېری وخت د برخې ثبت او د حل کوونکي ثبت دواړه په خپل ځای پرېږدي. ځانګړی PID ومومئ او سیګنال یوازې هغه ته ولېږئ:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

د بشپړې سمون لیست لوستلو دمخه pkill -f vpn یا killall vpn ته لاس مه غځوئ. -f د ټولې کمانډ کرښې سره سمون خوري، نو کېدای شي د پوښ سکریپټ، د سمونگر غونډه یا بې اړیکې بهیر چې په لار کې یې هغه تار وي پای ته ورسوي. د کار په مینځ کې ناسم بهیر پای ته رسول هغه لاره ده چې د حل کوونکي ستونزه ورکه فایل ګرځي.

resolvectl revert د هغې اړیکې د چلېدو پر مهال DNS ترتیب بیا تنظیموي، چې له حل کوونکي بیا پیلولو تنګتر او له نړیوال فایل سمون څخه ډېر تنګتر دی. که د ټنل اړیکه بشپړه ورکه شوې وي، systemctl restart NetworkManager د اړیکې حالت بیا جوړوي او دا هغه ګام دی چې د سرچینې تارونه یې په تکرار بېرته راځي. له Restart=always سره د خدمت مدیر ته پام کوئ، ځکه کېدای شي وژل شوی کلاینټ او د هغه DNS تنظیمات سيدهاً بېرته کېږدي.

بل لوری: هڅول شوی DNS چې هیڅکله ونه رسېد

د زړې ثبتې هنداره انځور هغه ټنل دی چې هیڅ د کار وړ حل کوونکی نلري. په پروفایل کې DNS انتخاب یوه غوښتنه ده؛ د اړیکې مدیریت کوونکې برخه باید هغه حل کوونکي ته وسپاري. که لاګ ښیي چې سرور ترلاسه شو خو د ټنل اړیکه هیڅ DNS تنظیم نه لېږدوي، کمه یې یوځایوالی دی، نه سرور.

سپارل په لاس ترسره کولو ازموئ، دا «سرور غلط دی» له «چا هغه نه دی پلي کړی» بېلوي:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

ټول نیوونکی د لارښوونې ډومین هر نوم هغې اړیکې ته لېږي، چې بشپړ ټنل کلاینټ یې غواړي او ویسړی DNS یې نه باید وکاروي. دا تنظیمات په بلې نښلونې کې ورکېږي. په NetworkManager کې دوی تلپاتې کولو لپاره اتوماتیک DNS بند کړئ، سرور پر اړیکه وټاکئ او ډومین ورزیات کړئ:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

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

هغه لارې چې بله خرابي کېږي

د نښلېدو دمخه resolv.conf کاپي کول او وروسته یې بحالول په runbook کې قانوني کرښه ده، او دا ترمیم نه دی بلکې لنډمهاله لار ده. دا هغه وخت ناکامېږي چې اړینه وي، ځکه نړېدل یا زورواکی بیا پیل بحالي پرېږدي. دا د لنډمهالې لارې په توګه ولیکئ تر څو بل کس پرې ونه جوړوي.

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

دوامداره سمون د هرې طبقې لپاره یو مالک دی: پریکړه وکړئ چې د ټنل اړیکې DNS د کومې برخې دی او نړیوال تلوالی د چا، دا ولیکئ او نور له لارې لرې کړئ. بیا له نښلونې وروسته د هغه نوم سره وګورئ چې یوازې VPN یې حل کوي. که خصوصي نوم لا هم ځواب ووایي، ثبت نه دی لرې شوی؛ که هیڅ نه حل کېږي، فایل هغه سرور ته اشاره کوي چې نور نه شته. دواړه د براوزر خلاصولو دمخه په resolvectl کې ښکاري.