ایک ہی Pi پر Pi-hole اور VPN: کیا آپریٹنگ سسٹم اب بھی معاون ہے؟

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

معاونت کا تعین ریلیز شاخ کرتی ہے، خاندان کا نام نہیں

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

آپ کے Pi پر اب بھی بوٹ ہونے والا پرانا ایمیج معاونت کا ثبوت نہیں۔ بورڈ ٹھیک ہے، پیکج اشاریہ پرانا ہے، اور عدم مطابقت بعد میں ظاہر ہوتی ہے، جب انسٹالر ایسا انحصار کھینچتا ہے جو ریلیز اب پورا نہیں کر سکتی۔

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

بائنری ہدف کو اپنی صارف جگہ کے مطابق بنائیں

ساخت زیادہ خاموش ناکامی ہے۔ 32 بٹ صارف زمین کے ساتھ 64 بٹ کرنل کئی بورڈز پر حقیقی، معاون امتزاج ہے، اور یہ 32 بٹ FTL بائنری کو بلا شکایت چلاتا ہے، ٹھیک اس لمحے تک جب آپ ایسی چیز نصب کریں جو صرف arm64 کے لیے شائع ہوتی ہے۔ ایمیج چننے سے پہلے دونوں نصف چھاپیں، اور نتائج اپنے نوٹس کے ساتھ رکھیں۔

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

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

بورڈ کی مارکیٹنگ بھی یہ طے نہیں کرتی۔ میموری کا حجم اور CPU ماڈل اس بارے میں کچھ نہیں کہتے کہ آپ کے پیکج کس libc سے منسلک ہوتے ہیں، اس لیے چھپے ہوئے اقدار سے فیصلہ کریں، کبھی مصنوعات کے صفحے سے نہیں۔

ایک ڈبہ، دو سروسز، نیٹ ورک کا ایک مالک

پہلا پیکج چڑھنے سے پہلے طے کریں کہ پتہ بندی، حل کنندہ اور ٹنل کس کے ہیں، ورنہ دو سروسز ایک ہی فرض کا دعویٰ کریں گی اور کوئی صاف نہیں جیتے گی۔ Pi کو اپنے راؤٹر کے دیے ہوئے DHCP تالاب سے باہر مستقل پتہ دیں، اور ٹنل کو اس کے اپنے ذیلی نیٹ پر رکھیں: Pi کے لیے 192.168.50.10 اور ٹنل کے لیے 10.42.0.0/24 ایک قابل عمل تقسیم ہے، اور اعداد خود من مانی ہیں جب تک وہ اس سے ٹکرائیں نہیں جو آپ کا راؤٹر پہلے ہی مہیا کرتا ہے۔ پھر لکھیں کہ کون سا جزو پورٹ 53 پر جواب دیتا ہے، استعمال کریں تو کون DHCP تقسیم کرتا ہے، اور ٹنل چڑھی ہونے پر کس کے پاس طے شدہ راستہ ہے۔ بغیر اسکرین ایمیج پر وہ آخری کام NetworkManager یا systemd-networkd کا ہے، اور ایسا فراہم کنندہ کلائنٹ نصب کرنا جو حل کنندہ کی تشکیل بھی دوبارہ لکھتا ہے وہ راستہ ہے جس سے لوگ زندہ ٹنل اور مردہ DNS کے ساتھ پھنس جاتے ہیں۔

ڈبہ بانٹنا ٹھیک ہے۔ کردار بانٹنا نہیں۔ Pi-hole پورٹ 53 پر واحد سننے والا بننا چاہتا ہے، اور VPN ڈیمن اپنی DNS ترتیب کلائنٹس تک دھکیلنا چاہتا ہے، اس لیے چنیں کہ کلائنٹس کو دونوں میں سے کس پر بھروسا کرنا چاہیے اور دوسرے کو راستے سے ہٹ کر رہنے کی ترتیب دیں۔

جہاں ممکن ہو انتظامی راستہ ٹنل سے باہر رکھیں۔ اگر حل کنندہ اور ٹنل ساتھ ناکام ہوں، آپ پھر بھی LAN پتے پر SSH قابل رسائی چاہیں گے، اور اس کا مطلب ہے کہ انتظامی سروس دونوں میں سے کسی پر منحصر نہ ہو۔

اگلی اپ گریڈ کو انتخاب کا حصہ بنائیں

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

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

اپ گریڈ کامیاب دکھے اور کچھ نہ بدلے کی عام وجہ ہولڈ کیے گئے پیکج ہیں۔ ہولڈ جان بوجھ کر ایک ایک کر کے ہٹائیں، اور نوٹ کریں کہ کس سروس کو پن درکار تھا۔

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

جب کوئی ایک ریلیز دونوں سروسز سے میل نہ کھائے

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

ورژن جعلی بنانا وہ واحد شارٹ کٹ ہے جسے براہ راست مسترد کرنا چاہیے۔ پیکج منتظمین ریلیز فائل کی بات مانتے ہیں، اس لیے جعلی شناخت آپ کو ایسی تنصیب دیتی ہے جس کی ڈیبگنگ میں دونوں منصوبوں میں سے کوئی مدد نہیں کرے گا۔

اگر دو موجودہ ریلیزیں سب کچھ پورا کریں تو وہ چنیں جس کے اپ گریڈ نوٹس آپ بغیر اندازے کے چلا سکیں، اور ڈھونڈنا بند کریں۔ پھر ورژن، ساخت، سروس کے مالکان اور بحالی کا مرحلہ ایک جگہ درج کریں، کیونکہ SD کارڈ کو چھونے والے اگلے شخص کو چاروں درکار ہوں گے۔