VPN کلائنٹ کی ٹریفک اور فائر وال کی حالت: بیرونی اور اندرونی بہاؤ

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

جب تک آپ ان دونوں کو الگ نہ کریں، ہر اصول کی تبدیلی ایک اندازہ ہے۔

فائر وال دو مختلف پیکٹ دیکھتا ہے

کیپسول کھولنے سے پہلے، فائر وال VPN کے آخری نقطے کی طرف بھیجی گئی ٹریفک دیکھتا ہے: سننے والے کی طرف بیرونی UDP بہاؤ۔ کیپسول کھولنے کے بعد، آگے بھیجا گیا پیکٹ کلائنٹ کا اندرونی پتہ اور خدمت کی منزل لے کر جاتا ہے۔

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

دونوں طرف کے مساوی مقامات سے لیے گئے کیپچر کا موازنہ کریں۔ ٹنل کے کنارے کا کیپچر اور سرور پر کا کیپچر ایک ہی سیشن کے لیے مختلف ٹوپل دکھاتے ہیں۔

پہلا فیصلہ: ٹنل یا خدمت کی اجازت

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

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

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

دوسرا فیصلہ: ہر حد پر حالت کے ساتھ یا بغیر

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

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

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

اسی پالیسی کے تحت واپسی کا راستہ تصدیق کریں

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

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