د OpenVPN کلینټونه بل هوسټ کې Pi-hole ریزارور ته استول

د Pi-hole پته په OpenVPN پروفایل کې اېښودل هغې ته لار نه جوړوي، د پوښتنې اجازه نه ورکوي او نه تضمینوي چې کلینټ به یې وکاروي۔ کله چې Pi-hole په جلا LAN ماشین کې وي، څلور شیان باید سمون وخورې: له کلینټ څخه لار، له ګېټوې څخه لېږد، پول ته د بېرته راتلو لار او په خپله Pi-hole کې د منلو تګلاره۔ هر ناکامي په لاګ کې بېله ښکاري۔ په دې ترتیب سره ورسره معامله کول له وروستي څخه لومړي سمولو څخه ګړندي دي۔ معمول لنډه لار، هرې سرچینې ته د recursion پرانیستل، یوه کوچنۍ ستونزه په یوه دايمي ستونزه بدلوي۔

ټېله شوې DNS اختیار څه کوي او څه نه کوي

سرور لاندې لارښوونې سره یو ریزارور اعلانوي، په دې فرض چې 192.168.50.53 د Pi-hole هوسټ دی۔ کلینټ اختیار ترلاسه کوي او، د خپل پلیټ فارم او د ریزارور د یوځای کېدو له مخې ، هغه د تونل انټرفېس باندې پلي کوي یا د یوه سیمه ییز stub په خاطر له پامه غورځوي۔ د لارې کرښه د DNS کرښې په څېر مهمه ده، ځکه هغه ریزارور چې کلینټ ورته نه رسېږي هېڅ ریزارور نه دی۔ له دې ټولو څخه هیڅ هم د سرور له خوا نه ښکاري۔

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

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

اختیار د سرور اړخ په اړه هم هېڅ نه وایي۔ DNS ترافیک لا هم باید له کلینټ څخه ګېټوې ته او له ګېټوې څخه Pi-hole ته سفر وکړي مخکې له دې چې هر اختیار معنا ولري۔ ورکه لار او رد شوې پوښتنه د کلینټ له اړخه یو ډول ښکاري، نو لومړی په ګېټوې باندې لېږد تایید کړئ۔

له Pi-hole څخه پول ته د بېرته راتلو لار

که د کلینټ د سرچینې پته وساتل شي، Pi-hole د VPN پول دننه یوې پتې ته ځواب ورکوي۔ د هغې خپله د لارښوونې جدول شاید د دې پول په اړه هېڅ نه پوهېږي، نو ځواب د هغې اصلي ګېټوې ته ځي او ورکېږي۔ د پوښتنو لاګ یوه غوښتنه پرته له سم ځوابه ښيي، چې فایر وال ستونزه ګڼل اسانه دي۔

LAN روټر ته د پول لپاره ثابته لار ورکړئ چې OpenVPN ګېټوې بل ګام وي، یا مخکې له Pi-hole ته لېږدولو سرچینه په ګېټوې باندې وژباړئ۔ لومړی د هر کلینټ پتې د Pi-hole د پوښتنو په لاګ کې لیدل کېدونکې ساتي۔ دویم د بېرته راتلو لارې شرط لرې کوي خو هر پوښتنه د ګېټوې څخه راغلې ښيي۔ هېڅ یوه هم غلطه نه ده؛ دوی بېلو پوښتنو ته ځواب وایي۔

که د هر کلینټ راپور یا تګلاره مهمه وي، ثابته لار غوره سودا ده۔ که LAN بل څوک سمبالوي او لار نه وي، ژباړه عملي انتخاب دی، د کلینټ د هویت له لاسه ورکولو سره ثبت شوی۔ ولیکئ کومه مو غوره کړه، ځکه هر وروستی لاګ پوښتنه پرې تکیه ده۔

د لارښوول شوو کلینټونو لپاره د Pi-hole د اورېدو حالت

د DNS لاندې د تنظیماتو په پاڼه کې د انټرفېسونو د اورېدو د چلند ښکته لیست ټاکي چې Pi-hole کومو سرچینو ته ځواب وایي۔ تر ټولو سخت اختیار یوازې په مستقیم ډول نښلو شوو شبکو کې کلینټونه مني؛ هغه اختیار چې وسایلو ته تر یوې څپې پورې اجازه ورکوي هغه د ګاونډي روټر شاته فرعي شبکو ته غځوي، او لارښوول شوی VPN کلینټ همداسې ښکاري۔ بسته واقعاً LAN انټرفېس ته رسېږي، خو د هغې د سرچینې پته بله فرعي شبکه ده۔ دا د تګلارې ردول دي نه د لارښوونې ناکامي، او توپیر یې د لاګونو لوستلو پر مهال مهم دی۔

د Pi-hole د اورېدو لارښود په سیمه ییز ډول نښلول شوې سرچینې له لارښوول شوو اصليتو څخه بېلوي، او د راتلو انټرفېس معیار نه دی۔ هغه حالت وټاکئ چې VPN پول ته اجازه ورکوي پرته له دې چې ټول انټرنیټ ته اجازه ورکړي، بیا یې له فایر وال قاعدې سره جوړه کړئ چې DNS یوازې له پول څخه مني۔

د لومړنۍ پوښتنې د کار کولو لپاره recursion ټولو اصليتو ته پرانیستل غلطه مرمت دی۔ دا شخصي ریزارور خلاص ته بدلوي، او سمون محدوده اجازه ده نه نړیواله۔

ځواب له پوښتنو لاګ سره سم کړئ

له کلینټ وپوښتئ، بیا سرور وګورئ او دواړه پرتله کړئ۔ په systemd-resolved کلینټ باندې لاندې کمانډونه راپور ورکوي چې کوم ریزارور ځواب جوړ کړ او کوم سرورونه د هرې اړیکې لپاره تنظیم شوي۔ هغه نوم وکاروئ چې یوازې Pi-hole یې پېژني، ځکه د Pi-hole پتې ته مستقیمه پوښتنه لاسرسي ثبوي نه تنظیم۔

resolvectl query intranet.example.lan
resolvectl dns

تمه شوی ځواب 192.168.50.53 د سرور په توګه نوموي او هغه پته بېرته راوړي چې یوازې هغه ریزارور به پېژندله۔ بیا د خود Pi-hole منظر وګورئ: pihole -t د پوښتنو لاګ ژوندی تعقیبوي، او هره کرښه د سرچینې پته لري۔ که سرچینه د کلینټ د تونل پته وي، د پول لار سمه ده۔ که دا د ګېټوې LAN پته وي، د سرچینې ژباړه روانه ده او د کلینټ خپله پته به هېڅکله راڅرګنده نه شي۔

که په لاګ کې هېڅ هم راڅرګند نه شي، پوښتنه هېڅکله Pi-hole ته نه ده رسېدلې او بل څه چې باید وګورل شي په ګېټوې باندې لېږد دی۔ که پوښتنه راڅرګنده شي او ځواب بېرته نه راځي، ستونزه د بېرته راتلو لار ده، یعنې پخوانۍ برخه۔ ناکامي په دې ډول ووېشل د لارښوونې تېروتنه له فایر وال قاعدې سره د ګډېدو مخه نیسي۔

د ګېټوې د لېږد قاعده وګورئ

ګېټوې باید د کلینټ DNS بستې Pi-hole ته لېږي، او هغه قاعده چې دا کوي د فرض کولو پرځای لوستلو ارزښت لري۔ لاندې کمانډونه هغه قواعد لیستوي چې پورټ 53 ته رسېږي، د شمارونکو سره، په nftables هوسټ او په iptables هوسټ باندې۔ هغه قاعده چې شته خو صفر سمون ښيي، دا اشاره ده چې ترافیک د ژباړې مخکې غورځول کېږي۔

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

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

هوسټ کومه وسیله کاروي، کنټرول تنګ وساتئ: پول د سرچینې په توګه، پورټ 53 د منزل په توګه او Pi-hole د یوازیني اجازه لرونکي هدف په توګه۔ پراخه لېږد قاعده چې پورټ 80 ته هم اجازه ورکوي، بله ستونزه ده چې د پېښېدو انتظار کوي۔