جب openfortivpn جڑتا ہے تو راستوں اور DNS کا مالک کون ہونا چاہیے؟

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

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

ایک ہی کنکشن جیسے دکھنے والے چار مراحل

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

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

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

روٹنگ جدول کون ترمیم کرتا ہے

بطور ڈیفالٹ مالک کلائنٹ ہے۔ یہ جسمانی انٹرفیس کے ذریعے گیٹ وے کی طرف راستہ، سرنگ کے ساتھی کے لیے راستہ، اور ان نیٹ ورکس کے لیے راستے شامل کرتا ہے جنہیں نشست استعمال کر سکتی ہے، پھر عمل کے باہر نکلنے پر انہیں ہٹا دیتا ہے۔ یہ ڈیفالٹ ایک ہی نیٹ ورک مینیجر اور کوئی دوسرا VPN سافٹ ویئر نہ ہونے والے لیپ ٹاپ پر آسان ہے۔

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

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

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

DNS اور ریزولور فائل کا مالک کون ہے

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

جدید Linux میزبان پر ریزولور مقامی اسٹب کے ذریعے سنبھالا جا سکتا ہے، اور اس اسٹب کی پیٹھ پیچھے ریزولور فائل دوبارہ لکھنے سے ایسی ترتیب بنتی ہے جو درست دکھتی ہے اور غیر مستقل برتاؤ کرتی ہے۔ اگر میزبان پہلے سے ریزولور مینیجر چلا رہا ہے، تو اسے DNS کا مالک بننے دیں اور اس کے معاون انٹرفیس کے ذریعے سرنگ کے سرورز اسے دیں۔ کلائنٹ کا no-dns اختیار وہاں درست انتخاب ہے، کوئی بچاؤ نہیں۔

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

استحقاق، تیاری اور حوالگی

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

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

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