کیوں Pi-hole v6 WireGuard کلائنٹس کی DNS درخواستیں نظر انداز کرتا ہے

Pi-hole v6 پورٹ 53 پر DNS درخواست وصول کرتا ہے اور پھر فیصلہ کرتا ہے کہ آیا آنے والے پیکٹ کا جواب دینے کی اجازت ہے۔ WireGuard ہوسٹ پر یہی دوسرا فیصلہ عام طور پر وجہ ہوتا ہے کہ کلائنٹ کو وقت ختم ہوتا ہے، حالانکہ LAN سے حل کنندہ صحت مند دکھائی دیتا ہے۔ پورٹ کھلا ہے، FTL چل رہا ہے، پھر بھی 10.90.0.1 سے کچھ واپس نہیں آتا۔ جواب نکلنے سے پہلے تین چیزیں ایک دوسرے پر اثر ڈالتی ہیں: dns.interface، dns.listeningMode اور دونوں کے سامنے فائر وال۔

سننے والا ساکٹ فیصلہ نہیں کرتا کہ جواب کس کو ملے گا

FTL پورٹ 53 پر UDP اور TCP سننے والے کھولتا ہے۔ طے شدہ ترتیب میں ساکٹ اکثر wildcard ہوتا ہے، اس لیے ss -lunp | grep :53 0.0.0.0:53 اور [::]:53 دکھاتا ہے، چاہے VPN کلائنٹس کو سروس ملے یا نہ ملے۔ wildcard ساکٹ پیکٹ قبول کرتا ہے، پھر FTL جواب دینے سے پہلے اپنے انٹرفیس اور ماخذ کے قواعد لاگو کرتا ہے۔ اسی لیے "پورٹ سن رہا ہے" ٹنل کلائنٹ کے بارے میں بہت کم ثابت کرتا ہے۔

جس فائل کو آپ فعال سمجھتے ہیں اس کی بجائے چلتی ہوئی ترتیب پڑھیں۔ pihole-FTL --config dns.interface اور pihole-FTL --config dns.listeningMode مؤثر اقدار چھاپتے ہیں، اور جب کنٹینر، ماحولیاتی متغیر یا تعیناتی منتظم وہ ترتیب رکھتا ہے تو یہ میزبان فائل سے مختلف ہو سکتی ہیں۔ Pi-hole FTL ترتیب کا حوالہ موڈز اور یہ کہ ان میں سے کون انٹرفیس پر منحصر ہے کی فہرست دیتا ہے۔

LOCAL پوچھتا ہے کون سا سب نیٹ، SINGLE پوچھتا ہے کون سا انٹرفیس

LOCAL، جو طے شدہ ہے، ان درخواستوں کا جواب دیتا ہے جن کا ماخذ پتہ میزبان کے کسی انٹرفیس پر ترتیب دیے گئے سب نیٹ میں آتا ہے۔ 10.90.0.1/24 والا سادہ wg0 یہ جانچ پاس کرتا ہے، کیونکہ 10.90.0.2 پر کلائنٹ ٹنل سب نیٹ کے اندر ہے۔ پیئر کے دوسری طرف روٹ شدہ کلائنٹ، یا کسی اور سابقے میں NAT کے پیچھے چھپا کلائنٹ، یہ جانچ پاس نہیں کرتا، حالانکہ پیکٹ wg0 پر آیا ہے، اور لاگ میں کوئی درخواست نظر نہیں آتی۔

SINGLE سوال بدل دیتا ہے۔ یہ dns.interface میں نامزد انٹرفیس پر آنے والی درخواستیں لوپ بیک سمیت قبول کرتا ہے اور ماخذ سب نیٹ کو نظر انداز کرتا ہے۔ زنجیر یا روٹ شدہ VPN ٹوپولوجی میں قائم رہنے والا موڈ یہی ہے۔ دونوں کیز ایک ساتھ مقرر کریں، کیونکہ نامزد انٹرفیس کے بغیر موڈ مکمل ہدایت نہیں:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND ساکٹ بدلتا ہے، اور اس کی قیمت ہے

BIND wildcard ساکٹ کو فلٹر نہیں کرتا؛ یہ پورٹ 53 کو صرف ان پتوں سے جوڑتا ہے جو نامزد انٹرفیس پر موجود ہیں، اس لیے کرنل کہیں اور آنے والے پیکٹ مسترد کرتا ہے۔ یہ SINGLE سے زیادہ سخت ہے اور اس کا مترادف نہیں۔ قیمت بوٹ کے وقت ظاہر ہوتی ہے: اگر FTL شروع ہوتے وقت wg0 اوپر نہ ہو، تو جوڑنے کے لیے پتہ نہ ہو، اور حل کنندہ سننے والے کے بغیر چل سکتا ہے جب تک انٹرفیس ظاہر ہو اور FTL دوبارہ شروع ہو۔

BIND اس وقت منتخب کریں جب آپ آغاز کی ترتیب قابو میں رکھتے ہیں، مثلاً WireGuard انٹرفیس کے بعد ترتیب دی گئی systemd اکائی، اور جب آپ چاہتے ہیں کہ کرنل FTL کے دیکھنے سے پہلے بھٹکے ہوئے پیکٹ گرا دے۔ SINGLE اس وقت منتخب کریں جب ٹنل آتا جاتا ہو، یا جب انٹرفیس کوئی ایسا اوزار بناتا ہو جو FTL کے بعد شروع ہوتا ہے۔

فائر وال دوسرا دروازہ ہے

درست FTL موڈ بھی ناکام ہوتا ہے اگر میزبان کا فائر وال wg0 پر پورٹ 53 گرا دے۔ دونوں پروٹوکول کے لیے VPN ماخذ کی حد کی اجازت دیں اور انٹرنیٹ جانب بند رکھیں۔ nftables میں، inet filter جدول کی موجودہ input زنجیر کے ساتھ، قواعد ایسے دکھتے ہیں:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

اگر ٹنل IPv6 لے جاتا ہے تو مطابق IPv6 قواعد شامل کریں، اور انہیں زنجیر کی drop پالیسی سے پہلے رکھیں۔ اگر میزبان ufw یا firewalld استعمال کرتا ہے تو اوزار ملانے کی بجائے اسی منتظم میں وہی مطابقت بیان کریں۔ انٹرنیٹ راؤٹر سے پورٹ 53 آگے نہ بھیجیں؛ کلائنٹس کو ٹنل کے ذریعے حل کنندہ کے VPN پتے تک پہنچنا چاہیے۔

دو راستے الگ رہتے ہیں۔ کلائنٹ کی درخواستیں FTL پر ختم ہوتی ہیں۔ FTL کی اپنی بالائی سمت کی تلاشیں میزبان کے روٹنگ جدول کے مطابق نکلتی ہیں، جو ٹنل استعمال کر سکتا ہے یا نہیں، اس لیے جواب دینے والا مگر کوئی مفید چیز واپس نہ کرنے والا حل کنندہ بالائی سمت کا مسئلہ ہے۔ ویب منتظم اور API اپنی پورٹس پر سنتے ہیں اور انہیں اپنی پابندی درکار ہے۔

جواب اور انکار کی تصدیق کریں

VPN کلائنٹ سے، دونوں پروٹوکول پر حل کنندہ کا پتہ پوچھیں: dig @10.90.0.1 example.com اور dig +tcp @10.90.0.1 example.com۔ پھر منتظم انٹرفیس میں درخواست کا لاگ دیکھیں کہ FTL نے درخواست درج کی ہے۔ لاگ اندراج کے بغیر کلائنٹ کا وقت ختم ہونا فائر وال یا انٹرفیس فلٹر کی طرف اشارہ کرتا ہے؛ جواب کے بغیر لاگ اندراج بالائی سمت کے حل کی طرف۔

VPN سے باہر کے میزبان سے منفی راستہ جانچیں۔ dig @10.90.0.1 example.com کا وقت ختم ہونا چاہیے، اور ss -lunp حل کنندہ پر پورٹ 53 کو کسی عوامی پتے سے بندھا نہیں دکھانا چاہیے۔ سروس ایک بار دوبارہ شروع کریں، پھر میزبان کو دوبارہ بوٹ کریں اور تصدیق کریں کہ wg0 دوبارہ ظاہر ہونے کے بعد بھی حل کنندہ جواب دیتا ہے۔ جو درخواست صرف اگلے ری بوٹ تک کام کرے وہ مکمل شدہ تبدیلی نہیں ہے۔