Pi-hole له VPN سره له نښلېدو وروسته اعلانونه نه بندوي: پنځه کتنې

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

1. هغه حل کوونکی ولولئ چې کلینټ یې واقعاً کاروي

له کلینټ وپوښتئ، نه له روټر۔ په Linux کې resolvectl status د هرې لینک لپاره DNS سرورونه او دا چې کومه لینک ګټي چاپوي؛ /etc/resolv.conf یوازې معمولاً یو stub دی چې 127.0.0.53 ته اشاره کوي۔ په Windows کې ipconfig /all د هر اډاپټر لپاره د DHCP ورکړل شوي سرورونه لیستوي، او په macOS کې scutil --dns هماغه د ساحې له مخې ښیي۔ که ځواب د Pi-hole پته نه وي، تاسو د تخصیص ستونزه لرئ او ګام 2 هماغه ځای دی چې دا ده۔

دوه شیان د سیستم حل کوونکی ماتوي حتی کله چې سم تنظیم شوی وي۔ هغه براوزرونه چې خپل خوندي DNS لري (د Chrome “Use secure DNS”، د Firefox network.trr.mode) غوښتنې د HTTPS له لارې عامه حل کوونکي ته لېږي او هیڅکله پورټ 53 نه پرانیزي۔ او په خود کلینټ کې VPN کلینټ کولای شي په خپل تونل انټرفیس کې د ~. د لارښوونې ډومین سره DNS سرور نصب کړي، چې هغه لینک د هر نوم لپاره واکمن کوي۔

هغه لار وازموئ چې اپلیکیشنونه یې وهي، نه هغه لار چې د ډیبګ وسیله یې وهي۔ resolvectl query example.com ښیي کومه لینک ځواب ورکړ، او getent hosts example.com هماغه NSS لارې ته ځي چې یو اپلیکیشن ځي؛ په macOS کې dscacheutil -q host -a name example.com هغه ساحوي حل کوونکي لولي چې scutil --dns لیستوي۔ خالي dig دا نه کوي: دا /etc/resolv.conf لولي او د هرې لینک غوره توب پرېږدي، نو کولای شي له Pi-hole څخه ځواب ورکړي پداسې حال کې چې هر اپلیکیشن لېږل شوی حل کوونکی کاروي، او دا هماغه سمه نیمګړتیا ده چې دا لیست د نیولو لپاره شته۔ د یو ځانګړي سرور ازموینې لپاره dig @192.168.1.53 وساتئ۔

2. تایید کړئ چې ځواب څوک ویشي

تخصیص له هغې څخه راځي چې DHCP ته ځواب وایي۔ په dnsmasq کې دا یوه کرښه ده، dhcp-option=6,192.168.1.53؛ د روټر په ویب UI کې دا د LAN DHCP برخې DNS ساحه ده۔ کلینټونه باید د لیدو دمخه نوي کړي۔ هغه وسیله چې ورځې روانه ده لا هم زوړ کرایه ساتي، او هغه وسیله چې حل کوونکی یې په لاس لیکل شوی وي هغه تل ساتي۔ د خپرېدو انګېرنې پرځای په ازموینې کلینټ کې نوی کړئ۔

IPv6 هغه نیمه ده چې هېرېږي۔ د روټر اعلانونه کولای شي خپل DNS سرور ولېږدوي (RDNSS)، او په OpenWrt کې دا د odhcpd ra_dns انتخاب دی؛ هغه کلینټ چې IPv6 غوره ګڼي هغه سرور کاروي پداسې حال کې چې همدا اوس ټاکل شوی DHCPv4 انتخاب بې کاره پاتې کیږي۔ که تیار نه یاست چې د IPv6 له لارې DNS وړاندې کړئ، یوازې د DNS اعلان پاک کړئ: په odhcpd کې ra_dns، یا په هر هغه څه کې چې د روټر اعلانونو ته ځواب وایي RDNSS انتخاب۔ ټول اعلان بندول له LAN څخه IPv6 پته هم لرې کوي، کوم چې ستاسو د موخې په پرتله ډېر لوی بدلون دی، خو یوازې د DNS انتخاب پاکول پته بې زیانه ساتي او ورک RDNSS په پاکټ نیولو کې ښکاره کوي۔

3. ثابت کړئ چې غوښتنه Pi-hole ته رسېږي

له Pi څخه غوښتنه د شبکې لارې په اړه هېڅ ثابتوي۔ له کلینټ څخه یې وچلوئ او د ځواب کوډ ولولئ:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

وخت ختمېدل فلټر کولو یا لارې ته اشاره کوي؛ REFUSED د لاسرسي قاعدې ته؛ SERVFAIL د Pi-hole شاته پورته حل کوونکي ته؛ هغه سم ځواب چې هیڅکله په غوښتنو ثبت کې نه ښکاري مانا دا ده چې کلینټ بل څه پوښتلي۔ UDP او TCP 53 وګورئ، ځکه چې لوی ځوابونه او ځینې حل کوونکي TCP ته بیرته ځي، او کله چې Pi-hole په کانټینر کې وي دواړه خپاره کړئ۔ یوازې UDP پوښونکی نقشه د پاکټ ضایع ته ورته وقفې ناکامۍ پیدا کوي۔

بیا د Pi-hole د اورېدو حالت فیصله کوي چې ایا دا اصلاً ځواب وایي۔ په یوازې ځایي حالت کې dnsmasq هغه سرچینو غوښتنې نه ګڼي چې په مستقیم نښلول شوي سبنیټ کې نه وي، او بل روټر شاته یا د تونل له لارې راغلی کلینټ هماغسې ښکاري: کلینټ وخت ختموي او غوښتنه هیڅکله ثبت ته نه رسېږي۔ هغه غوښتنه چې بیا هم د REFUSED په توګه ښکاري، د لاسرسي لیست یا فایر وال قاعدې لخوا رد شوې۔ ټولو سرچینو ته اجازه ورکول عادي حل دی، له هغې فایر وال قاعدې سره چې پورټ 53 ستاسو خپلو سبنیټونو ته محدودوي۔

4. وګورئ چې تونل ځواب بدل کړی که تېر کړی یې دی

دا هغه حالت دی چې دواړه نښې پکې پټې دي۔ کله چې روټر خپله VPN کلینټ وي، لېږل شوی DNS انتخاب کولای شي د تونل پورته کېدو شيبه LAN تنظیم تر پښو لاندې کړي: OpenVPN سرورونه dhcp-option DNS لېږي، او WireGuard پروفایل خپله DNS ننوتنه لري۔ د روټر اغېزمن حل کوونکی د تونل د فعالیدو پر مهال ولولئ، نه تر هغه دمخه، او هغه څه له پامه غورځوئ چې LAN پاڼه یې ادعا کوي۔

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

دواړه نه، یو حل وټاکئ۔ یا تونل له DNS څخه لرې وساتئ — په OpenVPN کې pull-filter ignore “dhcp-option DNS” او په WireGuard کې په AllowedIPs کې د LAN مخکښې پرته —، یا لېږل شوی حل کوونکی ومنئ او د هغه روټر شاته کلینټونو لپاره ځایي فلټر کول پرېږدئ۔ هر څه چې وټاکئ، هغه د پروفایل ترڅنګ ولیکئ، ځکه چې بل څوک چې یې سمون کوي به که نه، په ناڅاپي ډول پریکړه بدله کړي۔

5. له بیا نښلېدو وروسته ازموینه تکرار کړئ

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

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