VPN سرور کے لیے کلاؤڈ فائر وال بمقابلہ ہوسٹ فائر وال

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

کنارے سے شروع کریں اور اندر کی طرف جائیں

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

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

مہمان کو چھونے سے پہلے کلاؤڈ پالیسی پڑھیں

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

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

پہلے سامع، پھر ان پٹ زنجیر کی تصدیق کریں

انسٹانس پر جانچیں کہ VPN عمل اسی پتے اور پورٹ سے بندھا ہے جس کی آپ توقع کرتے ہیں، مثلاً ss -lntp 'sport = :1194' کے ذریعے۔ صرف 127.0.0.1 سے بندھا ڈیمن مقامی کلائنٹ قبول کرتا ہے اور ٹنل سے کچھ نہیں، جو باہر سے بالکل فلٹر شدہ پورٹ جیسا دکھتا ہے۔

پھر مقامی قواعد اسی نحو میں پڑھیں جو آپ انہیں بدلنے کے لیے استعمال کریں گے، جیسے iptables -S INPUT یا nft list chain inet filter input۔ فائل میں لکھا مگر کبھی لوڈ نہ کیا گیا قاعدہ، یا ملتی اجازت کے بغیر ڈیفالٹ گرا دینا، پیکٹ خاموشی سے گرا دیتا ہے۔ آگے بھیجنے والے گیٹ وے کے لیے آگے بھیجنے اور الٹے راستے کی ترتیبات بھی دیکھیں۔ انسٹانس کو مخاطب نہ ہونے بلکہ اس کے ذریعے روٹ ہونے والے پیکٹوں کا کیا ہوگا، یہی طے کرتی ہیں۔

ایک پرت میں حالت کے ساتھ، اگلی میں حالت کے بغیر

سیکیورٹی گروپ ان بہاؤں کو یاد رکھتے ہیں جن کی انہوں نے اجازت دی اور جوابات واپس آنے دیتے ہیں۔ سب نیٹ کی رسائی کنٹرول فہرستیں اور بہت سے ہوسٹ فائر وال ایسی حالت نہیں رکھتے، اس لیے صرف باہر جانے والی سمت ڈھکنے والا قاعدہ درخواست گزرنے دیتا ہے اور جواب گرا دیتا ہے۔ دوسری پرت کا قاعدہ پڑھے بغیر پرتوں کے درمیان واپسی ٹریفک کا مفروضہ کبھی نہ اٹھائیں (second layer's rule)۔

اکاؤنٹ کے ہر قاعدے کو پڑھنے سے جلد کاؤنٹر فیصلہ کر دیتے ہیں۔ بڑھتا کاؤنٹر یعنی پیکٹ وہاں پہنچا اور وہیں گرا دیا گیا، جبکہ صفر پر جمے کاؤنٹر کا مطلب ہے کہ وہ وہاں تک پہنچا ہی نہیں؛ جب قواعد کاؤنٹرز کے ساتھ لوڈ ہوں تو iptables -vnL INPUT اور nft list ruleset وہی اعداد دکھاتے ہیں۔

زندہ نشست کے بجائے نئی نشست سے جانچیں

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

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