د OpenVPN DNS په ګیټوې کې: dnsmasq او د فایر وال حد

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

اورېدونکی دوه لوري لرونکی ځایي خدمت دی

د ننه په لوري کلاینټ د ګیټوې د تونل پتې ته په پورت 53 پوښتنه لېږي۔ د باندې په لوري ډیمون هغه پوښتنه خپل تنظیم شوي پورت ته لېږي۔ دواړه نیمايي باید کار وکړي، او دوی په بېلو لارو ناکامېږي۔

هغه وخت چې کلاینټ راپور ورکوي او هغه وخت چې په ګیټوې کې لیدل کېږي یو ډول خرابي نه ده۔

د تونل پته وتړئ، نه هره پته

د دې کار لپاره ځانګړی dnsmasq باید روښانه اورېدلو پته، د وتلو وروسته د تونل ښکارېدو ته زغمونکی تړلو حالت، او یو روښانه پورت ولري۔ دا هغه تر ټولو کوچنی بڼه ده چې زه یې کاروم:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic جلا پتې تړي او tun0 چې وروسته ښکاره شي هغه سره مخ کېږي، چې په هغه هوسټ کې مهم دی چېرې چې VPN خدمت بیا پیلېږي۔ loopback لیستول پرته له عامه اورېدونکي څخه ځایي وسایل فعال ساتي۔ no-resolv ډیمون له هوسټ د ریزالور تنظیماتو څخه د پورتونو میراث نیول منع کوي، او no-hosts دا بڼه له دې چې د ګیټوې hosts فایل خپور کړي منع کوي۔ له دې انتخابونو هیڅ یو هم چا ته د خدمت پوښتنې اجازه نه ورکوي۔

دوهم ډیمون پیلولو دمخه وګورئ چې آیا په پورت 53 کې لا دمخه اورېدونکی شته، او په غلط فولډر کې د ورک شوي فایل پر ځای د ویش د تنظیماتو مالک وکاروئ۔

د DNS ننوتلو ته اجازه ورکړئ، نه د تونل تېرېدو ته

هغه فایر وال قواعد چې دا کار کوي ځایي-ننوتلو قواعد دي، د تونل انټرفیس، کلاینټې ټولګې، ګیټوې پتې او پورت 53 پورې محدود۔ دوه قواعد، هر پروتوکول لپاره یو، بس دي:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS د UDP تر څنګ د TCP له مخې هم کار کوي، نو یوازې د UDP قاعده لوی ځوابونه په داسې ډول ناکام پرېږدي چې وخت ناوخت ښکاري۔ دا ufw route اجازې نه دي، او باید tun0 باندې پراخه اجازه نه شي۔ ترتیب د منځپانګې په اندازه مهم دی: tun0 څخه ټول ننوتل غورځوونکی پخوانی قاعده بیا هم ګټي، او د وروستي غورځولو لاندې اجازه زیاتول هېڅ نه جوړوي۔

که د ګیټوې DNS اوس د ډیزاین برخه ده، هغه پخوانۍ پالیسي په قصد سره بیاکتنه کړئ او ولیکئ ولې۔

د پورت نیمایي جلا لاره ده

پوښتنې ګیټوې له خپلې پتې څخه د پورت ریزالور په لور پرېږدي، نو د ګیټوې لاره او دې ریزالور ته د وتلو پالیسي باید تبادله اجازه کړي۔ دا هغه قاعده نه ده چې کلاینټونه اورېدونکي ته رسوي، او په بله نښه ناکامېږي۔

د ځوابونو د کار کولو لپاره بې حده د تونل وتل مه زیاتوئ؛ تعقیب شوي ځوابونه دې ته اړ نه دي۔

انتخاب پوش کړئ، بیا سپارل وګورئ

سرور کولای شي ریزالور کلاینټونو ته په پوش شوي انتخاب سره اعلان کړي۔ دا انتخاب دی، نه هغه لارښوونه چې عملیاتي سیستم یې باید ومني:

push "dhcp-option DNS 10.90.0.1"

د Linux کمانډ لاین کلاینټ کېدای شي د خپل اړیکو مدیر د ریزالور یوځای والی ته اړ وي، او مدیریت شوی وسیله کېدای شي تازه شوي مدیریت پروفایل ته اړ وي۔ له نښلېدو وروسته په کلاینټ کې فعال ریزالور تایید کړئ، د دې پر ځای چې پوش شوی وي فرض کړئ۔ کله چې دوه میکانیزمونه په یو وخت DNS ټاکلو هڅه کوي، داسې سیالي پیدا کېږي چې د رپېدونکي حل په څېر ښکاري۔

هدف د کلاینټ د ریزالور تنظیماتو لپاره یو مالک دی، او پوش معمولاً هغه مالک یوازې هغه وخت وي چې د کلاینټ پلیټفارم سره موافق وي۔

هغه څه وازموئ چې واقعاً مو جوړ کړل

یو خصوصي بشپړ وړ نوم او یو اجازه شوی بهرنی نوم مستقیم د تونل پتې پر وړاندې، د UDP او TCP دواړو له مخې پوښتنه کړئ۔ بیا د اپلیکیشن د عادي لټون له لارې تکرار کړئ۔

که مستقیمې پوښتنې کار وکړې او اپلیکیشن لا هم ناکام شي، خرابي په سرور نه، په سپارلو کې ده:

• کلاینټ هغه پوش شوی انتخاب هېڅکله نه دی تطبیق کړی۔
• وروسته بل ریزالور وټاکل شو او سیالي یې وګټله۔
• اپلیکیشن خپله ریزالور کتابخانه یا کاش شوی ځواب کاروي۔

په دې پای ته ورسېږئ چې تایید کړئ د منل شوې VPN لارې بهر سرچینه اورېدونکی هېڅکله نه شي کارولای۔ بریالی حل هغه پتې ته واک نه ورکوي چې بیرته یې راوړی، نو دا دوه پوښتنې جلا وساتئ۔