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

سب نیٹ کی جگہ راستہ بندی ہے، اجازت نہیں

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

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

Client VPN منسلکہ گروپ ہی وہ دستہ ہے

سب نیٹ سے منسلک AWS Client VPN endpoint کے لیے دستاویزی ترتیب مخصوص ہے۔ مطلوبہ سیکیورٹی گروپ endpoint کے ہدف نیٹ ورک منسلکات پر لاگو کریں، پھر اسی Client VPN گروپ کو ماخذ بنا کر وسیلے کے سیکیورٹی گروپ میں مطلوبہ ٹریفک کی اجازت دیں۔

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

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

ایک منسلکہ گروپ کیا الگ نہیں کر سکتا

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

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

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

وہ قاعدہ ہر VPN ڈیزائن میں نقل نہ کریں

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

درمیانی آلے سے ٹریفک گزرنا ماخذ سیکیورٹی گروپ حوالہ اس طرح محفوظ نہیں رکھتا جیسے براہ راست انسٹانس سے انسٹانس ٹریفک کرتا ہے۔ AWS دستاویز کرتا ہے کہ ایسے ڈیزائنوں کو گروپ حوالہ کے بجائے مناسب نجی ماخذ پتے یا CIDR درکار ہو سکتے ہیں۔ منظم Client VPN کا طریقہ کار اس بات کا ثبوت نہیں کہ ہر گیٹ وے کا منسلک گروپ بھیجے گئے پیکٹوں کے لیے عالمگیر شناختی ٹوکن کے طور پر کام کرتا ہے۔

راستے میں ایک NAT چھلانگ مفروضہ توڑنے کے لیے کافی ہے، اور ناکامی ایسے قاعدے کی طرح لگتی ہے جو موجود ہے مگر کبھی میل نہیں کھاتا۔

مؤثر حد کا جائزہ لیں

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

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

کام کی ترتیب: چار حصوں والا تقاضا لکھیں، گروپ کو منسلکات سے جوڑیں، وسیلے کا قاعدہ پورٹ تک محدود کریں، ایک اجازت اور ایک رد کی تصدیق کریں، اور اس کے بعد ہی راستہ بندی کی وجوہات پر سب نیٹ تقسیم کرنے پر غور کریں۔

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