ایا ستاسو VPN د DNS معلومات کوډ کوي، که یوازې بل هاپ؟

په VPN سرور کې د کوډ شوي DNS فعالول اکثرا د یوې لیکنې د بندولو په توګه تشریح کېږي، او دا تشریح پټوي چې کومه اړیکه بدله شوه. له کلینټ څخه تر ریزالور پورې هاپ او له ریزالور څخه تر پورتنۍ جریان پورې هاپ جلا مالکان لرونکې جلا اړیکې دي. د دوی یو کوډ کول بل هغه په هماغه حالت کې پریږدي چې و.

مخکې له دې چې د ترتیباتو فایل ته لاس ووهئ، ولیکئ چې په هر پړاو کې پوښتنه څوک ترلاسه کوي.

دوه ترتیبات په تنظیماتو پاڼه کې ورته ښکاري

په لومړي ترتیب کې وسیله پخپله DNS over TLS چلوي، او ټنل یوازې هغه اړیکه ستاسو ټاکل شوي ریزالور ته رسوي. TLS غونډه په ریزالور کې پای ته رسېږي، یعني ریزالور پوښتنه ویني او د VPN وتل هغه کوډ شوی متن ویني چې نشي لوستلی. په دویم ترتیب کې وسیله عادي DNS د ټنل له لارې په VPN هوسټ کې فوروارډر ته لیږي، او هغه فوروارډر پورتنۍ ریزالور ته خپله کوډ شوې اړیکه پرانیزي. په ځانګړتیاوو لیست کې دواړه "له VPN سره کوډ شوی DNS" ښکاري، خو لوستل کېدونکې پوښتنه په بېلو ودانیو کې ږدي.

توپیر فلسفي نه، د اندازې وړ دی. په کلینټ یا سرور کې TLS غونډه وپلټئ، او پوه به شئ چې په رښتیا کوم ترتیب لرئ.

مخکې له بدلون څخه د ریزالورونو زنځیر نقشه کړئ

په لاره کې ریزالورونه وشمېرئ او د هر یو رول ونوموئ. د فوروارډینګ برخه غوښتنه بل ریزالور ته سپاري، خو تکرارېدونکی ریزالور د ځواب موندلو کار کوي او کولای شي له واکمنو سرورونو سره مستقیمه خبرې وکړي. دا رولونه په همدې دلیل جلا تعریف شوي دي، او د RFC 9076 ریزالور تعریفونه د دې له مخې لوستل ارزښت لري چې یوازې یو پورتنۍ منزل شته. هغه هوسټ چې خپل تکرارېدونکی ریزالور چلوي، د کوډ کولو لپاره یوازې یو "پورتنۍ جریان" نلري، چې ټوله پلان باطلوي.

بیا وپوښتئ چې کلینټ کومه برخه کارولو ته ترتیب شوی. د VPN پروفایل ورکړل شوی DNS پته وایي چې پوښتنې چېرته ځي، نه دا چې کوم بهیر ځواب ورکوي.

د ناکامۍ چلند هم په پام کې ونیسئ. که کوډ شوې پورتنۍ جریان نه شي رسېدلی، ایا فوروارډر بند حالت کې ناکامېږي، روښانه متن ته ګرځي، که بل ریزالور ته اوړي؟ دا پرېکړه باید په ثبت کې وي، ځکه د ټنل تر ټولو ناوړه حالت کې د محرمیت تضمین بدلوي.

وګورئ چې کوم هاپ کوډ شوی

له کلینټ پیل کړئ او تایید کړئ چې ایا 853 پورت ته TLS غونډه لري. هغه پوښتنه چې د 53 پورت له لارې سمه حل کېږي، د کوډ کولو په اړه هېڅ نه ثابتوي.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

بیا VPN هوسټ ته لاړ شئ او هغه بهر روانه کوډ شوې اړیکه وپلټئ چې فوروارډر پرانیستې. د سوکټ جدول وایي چې پورتنۍ TLS غونډه شته که نه، او کوم بهیر یې مالک دی:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

که کلینټ TLS غونډه ښکاره کړي او سرور هېڅ نه، تاسو په لومړي ترتیب کې یاست او سرور هغه پوښتنې نشي لوستلی چې په IP طبقه کې لیږدوي. که سرور TLS غونډه ښکاره کړي او کلینټ په ټنل کې دننه د 53 پورت عادي ترافیک، تاسو په دویم ترتیب کې یاست: بل هاپ ساتل شوی، خو فوروارډر بیا هم هر هغه نوم لولي چې وسیله یې غواړي. هغه دویمه پایله ناکامي نه ده، خو د هغې سر-تر-سره کوډ کول بلل غلط دي.

مالک او د ناکامۍ چلند ثبت کړئ

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

مخکې له دې چې څه فعال کړئ، داخلي نومونه وګورئ. د سازمان نومونه عامه ریزالور ته لیږل مساوي ډیزاین نه دی، او هغه split-horizon زون چې یوازې د شبکې په داخل کې شته، په پورتنۍ جریان کې هېڅ حل نه کېږي. له بدلون وروسته یو داخلي او یو عام نوم وآزمویئ، او پایله د ترتیباتو بدلون سره یوځای وساتئ. که کوډ شوې لاره د داخلي هوسټونو حل مات کړي، سمون د پراخ ټنل نه، بلکې د محدودې پوښتنې ریزالور قاعده ده.

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