ولې شخصي DNS نومونه په VPN کلاینټونو کې ناکامېږي او چېرې باید وګورو

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

له دې مخکې چې کوم پروفایل سم کړئ، تایید کړئ چې کلاینټ د نوم سره څه کوي۔ په Linux کې resolvectl query files.corp.example ښیي کومه اړیکه او کوم حل کوونکی ځواب جوړ کړ۔ په Windows کې Resolve-DnsName files.corp.example هغه سرور او هغه پته ښیي چې بېرته یې راوګرځوله۔

ځواب ولولئ له دې مخکې چې څه بدل کړئ

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

دا درې برخې وېش یو ساعت اټکل خوندي کوي۔ دا یې هم وایي چې آیا VPN ته لاس ووهو که نه: هغه نوم چې سمې شخصي پتې ته حل کېږي د حل کوونکي لاره یې دمخه ثابته کړې ده، نو پاتې کار د معلوماتو په لاره کې دی۔

حل کوونکی له تونل دننه ووېشئ

کلاینټونه په دوو ډلو وېشل کېږي۔ یوې ته سرور کولای شي د اړیکې د جوړېدو پر مهال حل کوونکی ورکړي؛ بله تنظیم په یو ځایي فایل کې ساتي چې هېڅ دروازه یې له لارې نه شي بدلولی۔

OpenVPN په لومړۍ ډله کې دی۔ په سرور کې push "dhcp-option DNS 10.8.0.53" او push "dhcp-option DOMAIN corp.example" د کنټرول کانال له لارې ښکته ځي، مګر یوازې هغه وخت چې د کلاینټ په ترتیباتو کې pull لا هم فعال وي۔ هغه کلاینټ چې په لاس سم شوی او pull-filter ignore "dhcp-option" لېږدوي هېڅکله به یې ونه ویني، او هماغه یوه کرښه په حیرانتیا سره ډېرې هغه پېښې تشریح کوي چې «سرور یې ټېل وهي خو زما لپ ټاپ موافق نه دی»۔

WireGuard په دویمه ډله کې دی، ځکه پروتوکول هېڅ د انتخابونو خبرې اترې نه لري۔ حل کوونکی او د لټون ډومین د کلاینټ په خپل [Interface] بلاک کې د DNS = 10.8.0.53, corp.example په توګه ځای پرځای کېږي۔ wg-quick دا د resolvconf یا systemd-resolved له لارې پلي کوي، او په Windows کې رسمي کلاینټ د NRPT هغه مقررات نصبوي چې یوازې تر هغه پورې شته چې تونل ولاړ دی: Get-DnsClientNrptPolicy هغه لیستوي، او دا یې د دې لپاره چټکه لاره جوړوي چې وګورو آیا کلاینټ ستاسو فایل کله هم پلي کړی دی۔

IPsec/IKEv2 په منځ کې دی۔ د strongSwan attr پلگ ان کولای شي له یوې زېرمې اخیستل شوی DNS سرور بېرته راوګرځوي، او Windows کلاینټ معمولاً مني یې، مګر هغه پروفایل چې خپل نوم سرور ټینګوي پر هر هغه څه بریالی کېږي چې دروازه یې وړاندیز کوي۔ په Linux کلاینټ کې معادل لاسي ګام resolvectl dns wg0 10.8.0.53 او بیا resolvectl domain wg0 '~corp.example' دی؛ دواړه د انټرفېس سره یوځای ورکېږي، او دا هغه څه دي چې د تونل پورې تړلي تنظیم لپاره یې غواړئ۔

ضمیمه محدوده کړئ پرځای د دې چې هره پوښتنه تېره کړئ

د کلاینټ ټول حل کوونکو لیست ستاسو کورني سرور ته اړول اسانه او معمولاً غلط دي۔ بیا هر عام نوم ستاسو د معلوماتو مرکز له وتنې حل کېږي، CDNونه لرې پتې بېرته راګرځوي، او د حل کوونکي یوه خنډ د کارن لټون هم له ځانه وړي۔

یوازې شخصي ضمیمه دننه ولېږئ۔ په systemd-resolved کې هغه ډومین چې په ~ پیل کېږي یوازې د لارښوونې لپاره دی، نو ~corp.example مانا دا ده چې د هغې ضمیمې لاندې پوښتنې د هماغې اړیکې سرورونو ته ځي او نور ټول بیا هم فزیکي شبکه کاروي۔ Windows هماغه کار د نوم فضا پورې محدودو NRPT مقرراتو سره کوي، او macOS د /etc/resolver/ لاندې اضافي حل کوونکي فایل سره۔

ملټي کاسټ نومونو خپل ځواب ته اړتیا ده۔ .local نومونه د جوړښت له مخې link-local دي (RFC 6762) او نقطه تر نقطې tun انټرفېس هغه ملټي کاسټ ګروپ نه وړي، نو د عام حل کوونکي زیاتول به یې اعلان نه کړي او د کورني unicast حل کوونکي څخه د هغوی په اړه پوښتل NXDOMAIN بېرته راګرځوي۔ د avahi په څېر یو انعکاس کوونکی د انعکاس حالت کې کولای شي دوې برخې یوځای کړي، مګر دا د سرور په اړخ پریکړه ده چې هېڅ کلاینټ یې نه شي غوښتلی۔ که چاپېر کوونکی یا NAS باید په نوم ورسېدلای شي، پرځای یې په خپل زون کې د A ثبت ورکړئ۔

ثابته کړئ چې ځواب بېرته راتلای شي

هغه سم ځواب چې نه رسېدونکې پتې ته اشاره کوي، تر هغه پورې چې لاره وګورئ، سمسم د حل کوونکي د ستونزې په څېر ښکاري۔ له کرنل وپوښتئ چې ځواب به چېرې ځي: ip route get 10.20.5.20 انټرفېس او، په ډېره ګټه، هغه سرچینه پته نوموي چې به یې کاروي۔

د حل کوونکي پته پخپله وګورئ۔ هغه کلاینټ چې DNS = 10.8.0.53 یې څنګ ته AllowedIPs = 10.20.0.0/16 وي پوښتنې خپلې د فزیکي NIC له لارې بهر لېږي، چېرې چې په غلیمانه توګه مري، ځکه حل کوونکی د هغه هېڅ یوې مخکښې دننه نه دی چې تونل یې غواړي۔ دا ناسم والی په ټول دې برخه کې تر ټولو عام یو لامل نیمګړتیا ده، او تر هغه پورې نه لیدل کېږي چې د DNS تنظیم له اجازه ورکړل شوو مخکښو سره کرښه په کرښه پرتله نه کړئ۔

یو پر بل وړاندې ساحې مخالف نیمګړتیا رامنځته کوي۔ ځواب سم دی، لاره شته او ناسم کوربه ته اشاره کوي، ځکه په کور کې 192.168.0.0/24 د تونل له لارې د هماغې ساحې په پرتله ډېره ځانګړې ده۔ یوه خوا بیا نومبر کړئ یا تنګه لاره ټېل وهئ، بیا د خدمت کوربه فایر وال او بېرته لاره تایید کړئ؛ strongSwan یادښتونه د وړاندې لېږلو په اړه د هغې لارې sysctl خوا پوښي۔

سندونه یو جلا هویت تصدیق دی چې خلک یې پر DNS ورټومبي۔ که براوزر د حل تېروتنې پرځای د نوم ناسم والی راپور کړي، لټون دمخه کار کړی او هغه څه چې باید سم شي په سند کې SAN دی۔ HTTPS په نوم وآزموئ، هېڅکله په لوڅ IP نه۔

له کلاینټه بیا وآزموئ، نه له دروازې

هغه اپلیکیشن کې وآزموئ چې کارن يې شکایت کوي، ځکه د کمانډ کرښې لټون نه ثابتوي چې براوزر هماغه لاره اخلي۔ د Chrome خوندي DNS او په Firefox کې network.trr.mode کولای شي د سیستم حل کوونکی په بشپړه توګه تر څنګ کړي، او کله چې داسې وکړي، شخصي نوم یا ناکامېږي یا عام حل کوونکي ته تويېږي۔ resolvectl query د لاسي چلول شوي dig @10.8.0.53 files.corp.example سره پرتله کول درته وایي چې له دواړو کوم یې پېښ شو۔

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

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