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

ضرورت کو سب نیٹ کے طور پر نہیں، سروس کے طور پر لکھیں

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

سب نیٹ نیٹ ورک ٹیم کی عمل درآمد کی تفصیل ہے، جبکہ سروس وہ ہے جو کاروبار نے طلب کیا اور وہ اکائی جس کا جائزہ لے کر اسے ریٹائر کیا جا سکتا ہے۔

اگر انحصار کی فہرست تین اشیاء سے بڑھ جائے، تو ایپلیکیشن کو غالباً اپنی ڈیزائن گفتگو درکار ہے۔

تنگ راستے پر چلائیں، لیکن نفاذ کہیں اور کریں

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

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

نفاذ کے نقطے کو واضح طور پر دستاویز کریں، ورنہ اگلی تبدیلی اسے اتفاقاً ہٹا دے گی۔

وہ ماخذ جانچیں جو سروس واقعی دیکھتی ہے

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

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

لکھیں کہ دونوں میں سے کون سا منتخب کیا، اس قاعدے کے ساتھ جو اس پر منحصر ہے۔

ایپلیکیشن کی اجازت اختیاری نہیں ہے

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

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

نیٹ ورک قاعدہ اور ایپلیکیشن کردار کو الگ نظاموں میں رکھیں، اور انہیں الگ الگ ریٹائر کریں۔

اجازت یافتہ اور مسترد شدہ دونوں راستے ثابت کریں

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

قبولیت کا امتحان پاس کرانے کے لیے فارورڈنگ فلٹرز بند نہ کریں، کیونکہ اس سے وہ چیز بدل جاتی ہے جس کی جانچ ہو رہی ہے۔

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

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