VPN کے لیے Linux نیٹ ورک نیم اسپیس: یہ کیا الگ نہیں کرتے

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

نیم اسپیس کس کا مالک ہے، اور ساکٹ کہاں جنم لیتا ہے

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

WireGuard کے لیے تخلیق کا سیاق موجودہ مقام جتنا ہی اہم ہے: UDP ساکٹ اسی نیم اسپیس میں بندھتا ہے جہاں انٹرفیس بنایا گیا تھا، چاہے ڈیوائس کہیں اور چلا جائے۔ انکرپٹ شدہ پیکٹ کس روٹنگ ٹیبل کی پیروی کرتے ہیں یہ اسی جائے پیدائش پر منحصر ہے۔ جب ساکٹ ایسے سیاق میں رہتا ہے جہاں ساتھی تک کوئی روٹ نہیں، انٹرفیس تلاش کرتا ہے اور مصافحہ کبھی باہر نہیں جاتا۔ پہلے اس کی جائے پیدائش، پھر موجودہ مقام جانچیں۔

نیم اسپیس کیا الگ نہیں کرتا

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

حل یہ ہے کہ /etc/netns/<name>/resolv.conf پر فی نیم اسپیس فائل ہو، یا تیار شدہ فائل کا bind mount، جو اندر سے قابل رسائی ریزولور کی طرف اشارہ کرے۔ میزبان پر /etc/resolv.conf میں ترمیم کرنے سے نیم اسپیس جو دیکھتا ہے اس میں کچھ نہیں بدلتا۔

عملوں کی جگہ بندی ہی کنٹرول ہے

آپ کو جو علیحدگی ملتی ہے وہ بالکل اندر شروع کیے گئے عملوں کی علیحدگی ہے۔ نیم اسپیس کے exec معاون کے ذریعے شروع ہوا شیل، اور وہ جو کچھ پیدا کرتا ہے، اندر ہی رہتا ہے؛ میزبان سیشن سے شروع کی گئی ڈیسک ٹاپ ایپلیکیشن نہیں رہتی۔ سیاق بنائیں، ڈیوائس منتقل کریں، پھر دونوں پہلو ثابت کریں:

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

نیم اسپیس کے اندر سے پہلا wg show اور میزبان سے دوسرا پڑھیں، اور توقع رکھیں کہ ان میں سے صرف ایک ہی ساتھی کی فہرست دے گا۔ اگر دونوں دیں تو ڈیوائس کبھی ہلا ہی نہیں؛ اگر کوئی نہ دے تو وہ کہیں اور چلا گیا۔ جب لانچر سروس مینیجر ہو تو unit فائل میں ترمیم کرنی ہوتی ہے، ڈیسک ٹاپ شارٹ کٹ میں نہیں۔ نیم اسپیس سیٹنگ کے بغیر unit ڈیمون کو میزبان کے سیاق میں شروع کرتا ہے اور ڈیزائن کو خاموشی سے منسوخ کر دیتا ہے۔

ایپلیکیشن کے سیاق سے جانچیں

جانچ اسی بائنری اور اسی صارف کے ساتھ چلائیں جو ایپلیکیشن استعمال کرتی ہے، نیم اسپیس کے اندر۔ DNS اور دونوں پتہ خاندان شامل کریں، کیونکہ جس IPv6 روٹ کے بارے میں آپ نے کبھی نہیں سوچا وہ باہر نکلنے کا عام راستہ ہے۔ آپ کے اپنے شیل سے کی گئی جانچ صرف یہ ثابت کرتی ہے کہ آپ کا شیل الگ ہے۔

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

فارورڈنگ، ناکامی کی پالیسی اور صفائی

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

نیم اسپیسوں کے نام، انٹرفیس اور ترتیب کس کی ہے یہ درج کریں، تاکہ صفائی صرف وہی ہٹائے جو تعیناتی نے بنایا۔ رول بیک کے دوران میزبان نیٹ ورکنگ ری سیٹ کرنا صفائی کو خلل میں بدل دیتا ہے۔ صفحہ network_namespaces(7) مختصر ہے اور اس راستے کی تشکیل سے پہلے پڑھنے کے قابل ہے۔