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

اصول لکھنے سے پہلے سروس لکھیں

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

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

تین ماخذ ماڈل، تین مختلف اصول

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

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

ہر منسلک گروپ میں اتحاد پڑھیں

انسٹنس کھولیں، اس کا نیٹ ورک انٹرفیس تلاش کریں، اور اس سے منسلک ہر سیکیورٹی گروپ کی فہرست بنائیں۔ ہر ایک کے لیے، آپ کے پروٹوکول اور پورٹ کو ڈھانپنے والا ہر اصول چیک کریں، بشمول وسیع پورٹ رینج اور دونوں پتہ خاندان۔ 0.0.0.0/0 سے IPv4 اصول آپ کو ::/0 چیک کرنے سے مستثنی نہیں کرتا، اور تمام ٹریفک کی اجازت دینے والا اصول پورٹ کا سوال مکمل طور پر چھپا دیتا ہے۔ اس فہرست کے بعد ہی آپ کہہ سکتے ہیں کہ سروس کے لیے مؤثر اجازت کیا ہے۔

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

نیٹ ورک ACL ایک الگ، بے حالت پالیسی ہے جس میں ترتیب شدہ اجازت اور انکار اندراجات ہوتے ہیں، اور ان کا جائزہ انسٹنس پر نہیں بلکہ سب نیٹ پر ہوتا ہے۔

انکار کی دیوار سے جواب نہ دیں

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

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

نئے سیشن کے ساتھ جانچ کریں اور اندر آنے کا راستہ رکھیں

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

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

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