VPN جڑنے کے بعد Pi-hole اشتہارات بلاک نہیں کر رہا: پانچ جانچیں

ایک کلائنٹ پر اشتہارات اب بھی دکھائی دے رہے ہیں، Pi-hole خود کو صحت مند قرار دے رہا ہے، اور ٹنل فعال ہے، اس لیے فطری رجحان یہ ہے کہ اس کلائنٹ کی ٹریفک Pi کے ذریعے بھیجی جائے۔ یہ غلط موڑ ہے۔ فلٹرنگ کو پیکٹ نہیں، سوالات درکار ہیں، اور جس کلائنٹ کے استفسارات ISP کے ریزالور کی طرف جاتے ہیں وہ اپنی ٹریفک کہیں بھی بہے، بغیر فلٹر ہی رہتا ہے۔ اس فہرست کو ترتیب سے مکمل کریں اور جس پہلے مرحلے میں ناکامی ہو وہیں رکیں، کیونکہ پچھلا مرحلہ خراب ہونے پر اگلا مرحلہ آپ کو کچھ نہیں بتا سکتا۔

1. وہ ریزالور پڑھیں جو کلائنٹ واقعی استعمال کر رہا ہے

راؤٹر سے نہیں، کلائنٹ سے پوچھیں۔ Linux پر resolvectl status ہر لنک کے DNS سرور اور یہ کہ کون سا لنک جیتتا ہے چھاپتا ہے؛ اکیلا /etc/resolv.conf عام طور پر 127.0.0.53 کی طرف اشارہ کرنے والا stub ہوتا ہے۔ 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 اور ریزالور اقدار رکھیں؛ رات کے کھانے کے وقت گھر کا انٹرنیٹ توڑ دینے والی تبدیلی کی ڈیبگنگ ایک منٹ میں واپس لائی جا سکنے والی تبدیلی سے کہیں زیادہ مشکل ہے۔