د Pritunl شخصي DNS ناکام دی؟ یو تنګ resolver لاره اضافه کړئ

شخصي نومونه په کارپوریټ شبکه کې د هر چا لپاره حل کیږي او په VPN کې د هر چا لپاره وخت ختمیږي۔ Resolver ګیټوې ته ځواب ورکوي، هغې ته لاره شته، او پوښتنه بیا هم هیڅکله ځواب نه ترلاسه کوي۔ هغه څه چې نشته بل عام resolver یا پراخه لاره نه ده: یو سرچینه پته ده چې شخصي DNS سرور یې ځواب ورکولو ته تیار دی۔

تایید کړئ چې resolver ستاسو د کلینټ حوض ردوي

د دې په ثابتولو سره پیل وکړئ چې ناکامي د سرچینې په اړه ده، نه د لاسرسي۔ له وصل شوي کلینټ څخه شخصي resolver ته مستقیمه پوښتنه وکړئ او وګورئ چې غوښتنه وخت ختمیږي که د رد په توګه بیرته راځي۔ dig @10.40.0.53 intranet.example.net +time=2 +tries=1 وخت ختمیږي پداسې حال کې چې له ګیټوې څخه ورته پوښتنه بریالۍ کیږي، دا resolver کې د لاسرسي پالیسۍ ته اشاره کوي۔ SERVFAIL ځواب بل بشپړ ځای، معمولا زون یا پورتنۍ فوروارډر ته اشاره کوي۔

د ازموینې دمخه د کلینټ پته یادښت کړئ۔ په کلینټ کې ip -4 addr show tun0، یا په کنسول کې ښودل شوی اجاره، تاسو ته وایي چې resolver کوم حوض ویني۔

بیا تایید کړئ چې لاره په بشپړ ډول شته۔ هغه لاره چې د resolver پته تونل ته لیږي یو شرط دی، نه حل؛ که پاکټونه هیڅکله ونه رسیږي، د سرچینې پالیسي هیڅکله نه ګړندي کیږي۔ په کلینټ کې د ip route get 10.40.0.53 سره یې وګورئ۔

د هر څه ژباړلو پرځای یوه هوسټ لاره اضافه کړئ

د Pritunl شخصي DNS لارښود تنګ درمل تشریح کوي: د resolver پتې لپاره د NAT سره /32 لاره، او هغه پته د کلینټانو DNS سرور په توګه ټاکل شوې۔ لاره یوازې د DNS ترافیک لپاره هغه سرچینه بدلوي چې resolver یې ویني۔ د اپلیکیشن ترافیک هغه سرچینه ساتونکی ډیزاین ساتي چې تاسو د هغې لپاره غوره کړی و۔

د موجودو لارو د تداخل له کتنې وروسته، د سرور د ملاتړ شوي لار مالک له لارې یې تنظیم کړئ۔ پورته مثال کې هدف د NAT سره 10.40.0.53/32 دی، او د کلینټ حوض 10.90.0.0/24 پاتې کیږي۔ د یو خدمت د سمولو لپاره ټوله شخصي حد مه ژباړئ، ځکه هر ښکته پالیسي چې د کلینټ ریښتیني پتې پورې تړلې ده به پرځای یې ګیټوې وویني۔ د ازموینې پلټنې په جریان کې د resolver د پوښتنې لاګ کتلو سره تایید کړئ چې هغه واقعیا کومه پته ترلاسه کوي۔ یوازې یوه هوسټ لاره د ژباړې یا اجازې په اړه هیڅ نه ثابتوي۔

Resolver لا هم باید ژباړل شوې سرچینې ته په UDP او TCP اجازه ورکړي، او ځوابونه یې باید بیرته راتللای شي۔ د سرچینې بدلول نشي کولای نیمګړی زون یا ریکارډ جوړ کړي۔

پریکړه وکړئ چې پوښتنه سرور لیږي که کلینټ

Pritunl د VPN Client DNS Mapping سره تړلې DNS-پروکسي ترتیب هم مستند کوي، چېرې چې سرور د کلینټانو لپاره پورتنۍ پوښتنې فوروارډ کوي۔ په هغه ماډل کې پورتنۍ سرچینه د سرور خپل شبکه یي شرایطو پورې اړه لري، او د کلینټ خوا استثنا غلطه حل ده۔

د هر څه اضافه کولو دمخه وپیژنئ چې کوم ماډل فعال دی۔ درې تداخل کوونکې ترمیمونه، یوه پروکسي، په کلینټ کې د resolver بدلول او یو لاسي NAT سکریپټ معمولا معنی لري چې هیچا نه دی ټاکلی: کوم برخه باید پوښتنه ولیږي۔ bootstrap هم وګورئ: یوازې شخصي resolver نشي کولای د تونل تر شتون دمخه د پای ټکي موندلو یوازینۍ لاره وي، او تلپاتې resolver بدلون باید له اړیکې څخه زیات ژوند ونه کړي۔

عام وېب پاڼه نه، شخصي پلټنه وآزمویئ

د بدلون له پلي کولو او بیا وصلیدو وروسته، د کلینټ اغیزمن resolver ترتیبات وګورئ، بیا هغه نوم حل کړئ چې تاسو پوهیږئ یوازې شخصي زون کې شته۔ پرته له څرګند سرور dig intranet.example.net ښیي چې کلینټ واقعیا څه کاروي۔ بیا هغې پتې ته غوښتنه ولیږئ چې هغې پلټنې بیرته راوړې وه، ځکه حل او خدمت ته لاسرسی جلا ګامونه دي۔ هغه براوزر چې عام سایټونه د DNS-over-HTTPS له لارې باروي د آپریټینګ سیسټم شخصي resolver لارې په اړه هیڅ نه ثابتوي۔ عام ثانوي resolver هم د داخلي زون لپاره واک نه دی۔

د resolver پته، /32 لاره او د کلینټ DNS تنظیم یوځای د سرور یادښتونو کې ثبت کړئ۔ د هغې ترتیباتو نیمه برخه یوازې بیا رغول شوې اصلي ناکامي تکراروي۔

په پای کې، تایید کړئ چې تونل د DNS له بریالیتوب وروسته لا هم د اپلیکیشن هدف ته لاره ورکوي۔ لاره، خدمت ته لاسرسی او تصدیق د نوم حل څخه خپلواک پاتې کیږي، او کار کوونکې پلټنه د تولید وړتیا په اړه هیڅ نه وایي۔ که شخصي پاڼه ورو ده خو حل کیږي، resolver خپله دنده ترسره کړې او ستونزه لارې ته تللې ده۔