Pi ہاٹ اسپاٹ Pi-hole اور VPN کے ساتھ: ہر سروس کو ایک کام دیں
ایک ہی Pi پر تین مددگار فعال کرنے سے پہلے فیصلہ کریں کہ DHCP، DNS اور پیکٹ فارورڈنگ کا مالک کون ہے۔ دہرائے گئے مالکان مسابقتی لیز اور ریزولور لوپ پیدا کرتے ہیں۔
ایک فون Pi کے ہاٹ اسپاٹ سے جڑتا ہے، پتہ لیتا ہے، اور صفحہ پھر بھی نہیں کھلتا۔ Pi ایک ہاٹ اسپاٹ مددگار، Pi-hole اور VPN کلائنٹ چلا رہا ہے، اور ہر ایک سمجھتا ہے کہ وہ راستے کا کچھ حصہ رکھتا ہے۔ ان میں سے زیادہ تر تعمیرات کسی جزو کے خراب ہونے سے نہیں، بلکہ اس لیے ناکام ہوتی ہیں کہ دو اجزاء ایک ہی کام کرتے ہیں۔ کسی بھی چیز کو ٹیون کرنے سے پہلے ہر فنکشن کے لیے ایک مالک مقرر کریں۔
ہر فنکشن کے لیے ایک مالک مقرر کریں
یہاں چار فنکشن اہم ہیں، اور ہر ایک کو بالکل ایک مالک درکار ہے۔ نیچے دی گئی جدول فنکشن، قابل عمل مالک اور وہ بتاتی ہے جو غلط ہوتا ہے جب دو سروسز اس پر دعویٰ کریں۔
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
اوورلیپ عام طور پر ایک وقت میں ایک پیکٹ آتا ہے۔ ہاٹ اسپاٹ مددگار اپنی dnsmasq مثال نصب کرتا ہے، Pi-hole پورٹ 53 چاہتا ہے، اور VPN کلائنٹ راستے شامل کرتا ہے۔ ہر قدم الگ الگ معقول لگتا ہے، اور مل کر ایسی مشین بناتے ہیں جہاں دوسری شروع ہونے والی سروس پہلی کے رویے کو خاموشی سے بدل دیتی ہے۔
کچھ اور فعال کرنے سے پہلے مالکان لکھ لیں۔ تعمیراتی نوٹ میں ایک مختصر جدول بعد کی تنصیب کو ایسے فنکشن پر قبضہ کرنے سے روکتی ہے جس کا پہلے سے مالک تھا۔
ایک رینج چنیں اور اسے ٹنل سے دور رکھیں
ہاٹ اسپاٹ کی رینج، اس میں Pi کا پتہ، DHCP پول اور وہ ریزولور منتخب کریں جو کلائنٹس کو ملتا ہے۔ اس رینج کو اوپری LAN اور VPN ٹنل کی رینج سے الگ رکھیں، کیونکہ اوورلیپ ہونے والے سب نیٹ روٹنگ کے مسئلے کو پتہ ترجمے کے منصوبے میں بدل دیتے ہیں۔ ٹنل سے اوورلیپ ہونے والی رینج Pi کو دو یکساں سابقوں کے درمیان حادثاتی روٹر بنا دیتی ہے۔ رینج اور پول کو ڈیفالٹ پر چھوڑنے کے بجائے ہاٹ اسپاٹ کنفیگریشن میں لکھیں۔
اگر ہاٹ اسپاٹ NetworkManager کے مشترکہ موڈ کے پاس ہے تو DHCP سرور شامل کرنے سے پہلے موثر کنکشن کا معائنہ کریں۔ مشترکہ موڈ اپنے مددگار شروع کرتا ہے اور فارورڈنگ فعال کرتا ہے، اس لیے وہ اس انٹرفیس کے پتہ منصوبے کا پہلے سے مالک ہے۔ صرف دستیاب ہونے کی وجہ سے دوسرا سرور شامل کرنا فالتو پن کے بجائے مسابقتی پیشکشیں پیدا کرتا ہے۔
IPv6 کا فیصلہ سوچ سمجھ کر کریں۔ راؤٹر اعلانات اور DHCPv6 بہت سی ترتیبات میں DHCPv4 سے مختلف مددگار سے آتے ہیں، اور IPv6 کو آن رکھنا جبکہ VPN پالیسی صرف IPv4 کا احاطہ کرتی ہے، کلائنٹس کو ٹنل سے بچنے والا راستہ دے دیتا ہے۔ یا تو IPv6 پہلو کی منصوبہ بندی کریں یا اسے ہاٹ اسپاٹ انٹرفیس پر تحریری وجہ کے ساتھ بند کر دیں۔
پورٹ 53 پر اصل میں کون جواب دیتا ہے
کنفیگریشن بدلنے سے پہلے ہر اس عمل کی فہرست بنائیں جو پورٹ 53 پر سن رہا ہے۔ ایسے Pi پر جو مقامی ریزولور stub، Pi-hole اور اشتراک مددگار چلاتا ہے، سننے والوں کی فہرست ہی اس کی واحد قابل اعتماد نقشہ ہے کہ سوالات کا جواب کون دیتا ہے:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-hole کی انٹرفیس گائیڈ بتاتی ہے کہ ایک انٹرفیس تک محدود وصولی موڈ پھر بھی wildcard ساکٹ استعمال کر سکتا ہے اور کہیں اور آنے والے پیکٹ پھینک سکتا ہے۔ یہ صرف منتخب انٹرفیس باندھنے کے مترادف نہیں، جو اس وقت مطلوبہ ترتیب ہے جب کوئی دوسری DNS سروس مشین کو شیئر کرنی ہو۔
دو عمل عام طور پر ایک ہی پتہ اور پورٹ نہیں باندھ سکتے، حالانکہ SO_REUSEPORT مشترکہ بائنڈ کو کامیاب کر سکتا ہے؛ تب بھی wildcard سننے والا تنگ سروس کے لیے آنے والے پیکٹ لے سکتا ہے۔ مطلوبہ کردار کے لیے دستاویزی موڈ منتخب کریں اور سروسز کو مطلوبہ ترتیب میں دوبارہ شروع کریں۔
Pi-hole کا انتظامی صفحہ ہاٹ اسپاٹ نیٹ ورک سے باہر رکھیں۔ کلائنٹس کو ریزولور درکار ہے، وہ ویب انٹرفیس یا API نہیں جو ریزولور کی کنفیگریشن بدل سکے۔
DNS کی دو ٹانگیں، ہر ایک کے لیے ایک پالیسی
کلائنٹ کا سوال فون سے Pi تک جاتا ہے، اور ایک الگ سوال Pi سے اس کے اوپری ریزولور تک جاتا ہے۔ فارورڈ شدہ ہاٹ اسپاٹ ٹریفک سے مماثل روٹنگ قاعدہ دوسری ٹانگ پر خود بخود لاگو نہیں ہوتا، کیونکہ Pi وہ ٹریفک مقامی طور پر پیدا کرتا ہے۔ اگر VPN کو DNS لے جانا ہے تو مقامی راستے کو اپنی پالیسی درکار ہے۔
لوپ سے بچیں۔ Pi-hole کے اوپری ریزولور کو ایسے پتے کی طرف موڑنا جو Pi خود پیش کرتا ہے، براہ راست یا پورٹ فارورڈ کے ذریعے، ایسے سوالات بناتا ہے جو وقت ختم ہونے تک گھومتے رہتے ہیں۔ اسے حقیقی اوپری ریزولور یا ان ڈومینز کے لیے مشروط فارورڈر دیں جن کا وہ جواب نہیں دے سکتا۔
فیصلہ کریں کہ ٹنل گرنے پر کیا ہوگا۔ مقامی ریزولور پر واپس جانا براؤزنگ کو زندہ رکھتا ہے لیکن نام VPN سے باہر لے جا سکتا ہے؛ بلاک کرنا پالیسی کو برقرار رکھتا ہے اور خرابی کو نظر آنے والی غلطی بنا دیتا ہے۔ دونوں انتخاب قابل دفاع ہیں، لیکن انہیں منتخب کرنا ہوگا، ڈیفالٹ سے وراثت میں نہیں لینا۔
راستہ اور خرابی کے وقت کا رویہ ثابت کریں
تہوں میں جانچیں: کلائنٹ کو پتہ ملتا ہے، کلائنٹ Pi کے ذریعے نام حل کرتا ہے، Pi مطلوبہ اوپری ریزولور کے ذریعے حل کرتا ہے، اور ایپلیکیشن درخواست مکمل کرتی ہے۔ کامیاب پنگ DNS کے بارے میں کچھ نہیں کہتا، اور کامیاب تلاش فارورڈنگ کے بارے میں کچھ نہیں کہتی۔
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1پھر ٹنل روکیں اور دہرائیں۔ مطلوبہ رویہ چند سیکنڈ میں ظاہر ہونا چاہیے، Pi-hole یا ہاٹ اسپاٹ سروس کو دستی طور پر دوبارہ شروع کرنے کے بعد نہیں۔ خرابی کے دوران کلائنٹ کی ریزولور ترتیب چیک کریں، کیونکہ ثانوی عوامی ریزولور جواب دیتا رہے گا چاہے پالیسی ناکامی کی توقع کر رہی ہو۔
فارورڈنگ اور NAT کے لیے ایک مالک رکھیں اور اسے کلائنٹ سے تصدیق کریں، خود Pi سے نہیں۔ Pi سے کامیابی سے نکلنے والی درخواست واپسی کے راستے میں پھر بھی گری ہو سکتی ہے، اور کلائنٹ واحد جگہ ہے جہاں پورا راستہ نظر آتا ہے۔