OpenVPN کلائنٹس کو دوسرے ہوسٹ پر Pi-hole resolver کی طرف بھیجیں

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

دھکیلی گئی DNS آپشن کیا کرتی ہے اور کیا نہیں کرتی

سرور ذیل کی ہدایت کے ساتھ ایک resolver کا اعلان کرتا ہے، یہ فرض کرتے ہوئے کہ 192.168.50.53 Pi-hole ہوسٹ ہے۔ کلائنٹ آپشن وصول کرتا ہے اور، اپنے پلیٹ فارم اور resolver انٹیگریشن کے مطابق ، اسے ٹنل انٹرفیس پر لاگو کرتا ہے یا مقامی stub کے حق میں نظر انداز کرتا ہے۔ روٹ لائن DNS لائن جتنی ہی اہم ہے، کیونکہ جس resolver تک کلائنٹ نہیں پہنچ سکتا وہ کوئی resolver نہیں۔ اس میں سے کچھ بھی سرور کی طرف سے نظر نہیں آتا۔

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"

آپشن وصول کرنا اسے استعمال کرنے کے مترادف نہیں۔ resolver مینیجر والا Linux کلائنٹ دھکیلا گیا سرور قبول کر سکتا ہے اور اسے صرف مخصوص ڈومین بھیج سکتا ہے؛ جو کلائنٹ خود DNS سنبھالتا ہے وہ ترتیب کو مکمل طور پر بدل سکتا ہے۔ دھکیلی گئی روٹس کچھ پلیٹ فارمز پر محدود بھی ہیں، جس سے resolver ناقابل رسائی رہتا ہے اگرچہ آپشن قبول ہو چکی ہو۔ کلائنٹ پر دیکھیں کون سا سرور جواب دیتا ہے، سرور پر نہیں کہ کیا بھیجا گیا۔

آپشن سرور کی طرف کے بارے میں بھی کچھ نہیں کہتی۔ 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 کھولنا غلط مرمت ہے۔ یہ نجی resolver کو کھلا بنا دیتا ہے، اور اصلاح محدود اجازت ہے نہ کہ عالمی۔

جواب کو استفسار لاگ سے ملائیں

کلائنٹ سے پوچھیں، پھر سرور جانچیں اور دونوں کا موازنہ کریں۔ systemd-resolved کلائنٹ پر نیچے دیے گئے کمانڈز بتاتے ہیں کہ کس resolver نے جواب پیدا کیا اور ہر لنک کے لیے کون سے سرور ترتیب دیے گئے۔ ایسا نام استعمال کریں جو صرف Pi-hole جانتا ہو، کیونکہ Pi-hole کے پتے پر براہ راست استفسار رسائی ثابت کرتا ہے نہ کہ ترتیب۔

resolvectl query intranet.example.lan
resolvectl dns

متوقع جواب 192.168.50.53 کو سرور کے طور پر نام دیتا ہے اور ایسا پتہ واپس کرتا ہے جو صرف وہی resolver جانتا ہوگا۔ پھر خود 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 کی بھی اجازت دے، ایک اور مسئلہ ہے جو ہونے کا انتظار کر رہا ہے۔