قائم شدہ Linux VPN استعمال کرنے والا براؤزر /dev/net/tun نہیں کھولتا۔ یہ ایک ساکٹ کھولتا ہے، اور کرنل طے کرتا ہے کہ اُس ساکٹ کے پیکٹ کس انٹرفیس سے باہر جاتے ہیں۔ جس عمل نے ٹنل بنایا وہ اُس عمل سے مختلف کام کر رہا ہے جس کی ٹریفک وہ لے جاتا ہے۔ اِن دو کرداروں کو الگ رکھنا اکثر اجازت کے سوالوں کا جواب اُن کے پوچھے جانے سے پہلے دے دیتا ہے۔

ساکٹ سے ٹنل تک ایک پیکٹ کا پیچھا کریں

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

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

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

طے کریں کہ کسے ڈیوائس چاہیے اور کسے نہیں

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

راستہ اور پالیسی قائم ہونے کے بعد، ایک عام عمل نکلنے والے راستے کو اپنی معمول کی ساکٹ کالز کے ذریعے استعمال کرتا ہے۔ اُسے ڈیوائس نوڈ کی ضرورت نہیں، اور root کی بھی ضرورت نہیں۔

ڈیوائس کی اجازتیں بدلنا کسی ایپ کو منزل تک رسائی دینے کا طریقہ نہیں ہے۔ یہ صرف ڈیوائس کی حد کو کہیں اور منتقل کرتا ہے۔

وہ نیم اسپیس دیکھیں جس میں ایپ واقعی چلتی ہے

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

اِسے ip netns list اور ip -n NAME route سے، یا عمل کے نیم اسپیس لنک کو دیکھ کر جانچیں۔ جواب عام طور پر ایک ہی کمانڈ میں نظر آتا ہے۔

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

صلاحیتوں کو نیٹ ورک پالیسی سے الگ کریں

کچھ ٹولز کو ساکٹ سے زیادہ چاہیے ہوتا ہے۔ پیکٹ پکڑنے کے لیے خام ساکٹ چاہیے، اور راستے بدلنے کے لیے انتظامی اختیار چاہیے۔ یہ الگ اجازتوں والے الگ کام ہیں، اور ایک دینا VPN استعمال کرنے کی عمومی شرط کے طور پر نہیں پڑھا جانا چاہیے۔

اپنی ٹنل خود نافذ کرنے والا پروگرام تیسرا معاملہ ہے۔ یہ واقعی TUN کھولتا ہے کیونکہ یہ ڈیمون کا کردار لیتا ہے، اسی لیے اُسے ڈیمون کے استحقاقات چاہیے۔

استحقاق کا نام لینے سے پہلے کام کا نام لیں۔ دونوں کو الگ کرنا عام طور پر دکھنے سے آسان ہوتا ہے۔

دو اکاؤنٹس کے ساتھ تقسیم کی تصدیق کریں

ٹنل کو بطور سروس جوڑیں، پھر ایپ کو عام صارف کے طور پر چلائیں اور تصدیق کریں کہ یہ نجی وسیلے تک پہنچتی ہے۔ اُس صارف کے شیل سے منزل کے لیے ip route get دیکھیں کہ کون سا انٹرفیس چنا گیا۔ اگر راستہ درست ہے اور کنکشن پھر بھی ناکام ہوتا ہے تو مسئلہ پالیسی ہے، استحقاق نہیں۔

نتیجے میں بننے والا ڈیزائن واضح حد کے ساتھ کم سے کم استحقاق ہے: ایک جزو سیٹ اپ اور ٹنل کے وسائل کا مالک ہے، ورک لوڈ اپنے عام اکاؤنٹس رکھتے ہیں، اور نیٹ ورک پالیسی طے کرتی ہے کہ کیا گزر سکتا ہے۔ سب کچھ root کے طور پر چلانا اُن کرداروں کو بغیر کچھ بتائے ڈھا دیتا ہے۔

متعلقہ مضامین