جب ریموٹ ایکسیس کلائنٹ کو برانچ گیٹ وے کا کردار ادا کرنا پڑے

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

پروٹوکول کا لیبل آپ کو کیا نہیں بتاتا

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

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

معاہدے کے دو پہلو ہیں: برانچ اور ہیڈکوارٹر

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

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

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

روٹڈ یا ٹرانسلیٹڈ: واپسی کا راستہ سوچ سمجھ کر چنیں

روٹڈ چنیں جب فی ڈیوائس شناخت اور فی ہوسٹ پالیسی اہم ہو اور آپ ہر متعلقہ راؤٹر پر واپسی روٹ برقرار رکھ سکیں۔

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

ایک مفید جانچ غیر متناسب ہے: برانچ ڈیوائس سے کوئی وسیلہ طلب کریں، پھر تصدیق کریں کہ جواب ہیڈکوارٹر سے برانچ پریفکس کی طرف نکلتا ہے۔ ہیڈکوارٹر ہوسٹ سے traceroute -n 10.60.4.20 دکھاتا ہے کہ وہ راستہ VPN گیٹ وے سے گزرتا ہے یا نہیں۔

اسے انفراسٹرکچر کی طرح چلائیں، لاگ ان کی طرح نہیں

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

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

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