شراکت داروں کو ضم کیے بغیر ان کی VPN رسائی کو مرکزی بنائیں

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

ہر شراکت دار کے پہلے سے دستخط شدہ معاہدے سے شروع کریں

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

وہ ریکارڈ ہی حتمی پیداوار ہے۔ اگر آپ ایک شراکت دار کے لیے یہ نہیں لکھ سکتے تو وہ شراکت دار مرکزی بنانے کے لیے تیار نہیں۔

صرف منزل سے نہیں، سیاق و سباق سے روٹ کریں

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

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

جہاں جواب ہاں ہے، وہاں روٹنگ سیاق و سباق ہی وہ چیز بنتا ہے جسے آپ دستاویز کرتے اور جانچتے ہیں، کیونکہ یہ traceroute میں نظر نہیں آتا۔

طے کریں کہ ملازم کیا ٹائپ کرتا ہے اور شراکت دار کیا لاگ کرتا ہے

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

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

شراکت دار سے شراکت دار ٹرانزٹ کی واضح طور پر تردید کریں

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

تردید کو اجازتوں کے ساتھ ہی شراکت دار کے ریکارڈ میں لکھیں، تاکہ ارادہ عملے کی تبدیلی سے بھی بچا رہے۔

اسے بڑا لیپ ٹاپ نہیں، مشترکہ سروس کے طور پر چلائیں

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

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

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