VPN کے لیے کلاؤڈ سیکیورٹی گروپ: سننے والا کھولیں، سب کچھ نہیں

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

قاعدے سے پہلے پروٹوکول کا نام لیں

قاعدہ یعنی پروٹوکول، پورٹ کی حد اور ماخذ۔ WireGuard UDP پر سنتا ہے، عام طور پر 51820۔ OpenVPN عام طور پر UDP یا TCP 1194 ہوتا ہے، انحصار اس پر ہے کہ اسے کیسے ترتیب دیا گیا۔ IPsec کو UDP 500 اور 4500 پر IKE تبادلہ اور خود ESP پروٹوکول درکار ہے، جو پورٹ نہیں بلکہ پروٹوکول نمبر ہے۔ یہ سمجھنا کہ TCP ہے کیونکہ باقی قواعد TCP ہیں، ایسا قاعدہ بناتا ہے جو درست دکھتا ہے اور کسی چیز سے مطابقت نہیں رکھتا۔

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

ماخذ کو پورے انٹرنیٹ کے بجائے اس کلائنٹ رینج تک محدود کریں جس کی ڈیزائن اجازت دیتا ہے۔

سیکیورٹی گروپ اسٹیٹ فل ہیں؛ سب نیٹ ACL نہیں

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

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

مؤثر پالیسی منسلک چیزوں کا اتحاد ہے، وہ فائل نہیں جو آپ نے تدوین کی۔

ہوسٹ فائروال الگ حد ہے

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

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

انٹرفیس پر کیپچر بتاتا ہے کہ کس حد نے پیکٹ گرایا۔

سننے والے کو اجازت دینا کلائنٹس کو روٹ کرنا نہیں ہے

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

یہیں کام کرنے والا ہینڈ شیک اور ٹوٹا ہوا ڈیٹا راستہ الگ ہوتے ہیں، اور اسی لیے ٹنل کی حالت صحت مند دکھ سکتی ہے جبکہ کچھ بھی لوڈ نہیں ہوتا۔

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

واپسی کا راستہ رکھیں، پھر قاعدہ تنگ کریں

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

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

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