کیا آپ کو دو VPN تہوں کو ایک دوسرے پر رکھنا چاہیے؟ جانچنے کے لیے تین شرطیں

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

لکھیں کہ مبصر کیا رکھتا ہے

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

لہٰذا مفید شے وقت کی لکیر ہے، ڈبوں کا نقشہ نہیں۔ ہر تہہ کے لیے آخری نقطہ، کلید کا مالک، شناخت کی جانچ اور وہ سال لکھیں جب مفروضے کے ناکام ہونے کی توقع ہے۔

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

شرط ایک: کیا تہیں الگ الگ جگہوں پر رکتی ہیں؟

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

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

شرط دو: کیا کلیدی مواد واقعی خودمختار ہے؟

ایک سرٹیفکیٹ، ایک پہلے سے مشترکہ کلید یا ایک وینڈر لائبریری سے بنی دو تہیں اضافی مراحل والی ایک تہہ ہیں۔ تب ایک لیک شدہ اسناد دونوں کو کھول دیتی ہے، اور ایک نفاذ کی خرابی دونوں کو ایک ساتھ ہٹا دیتی ہے۔ خودمختاری ترتیب میں نظر آنی چاہیے، سلائیڈ پر دعویٰ نہیں۔

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

شرط تین: کیا ڈیٹا بیرونی مفروضے سے زیادہ زندہ رہتا ہے؟

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

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

جب جواب نہ ہو تو اس کے بجائے کیا بنایا جائے

اگر تینوں شرطوں میں سے کوئی بھی ناکام ہو تو تہہ بندی چھوڑ دیں اور کوشش اس تہہ پر صرف کریں جو واقعی عمر کی ضرورت اٹھاتی ہے۔ جس پروٹوکول کو آپ پہلے ہی چلا رہے ہیں اس میں ہائبرڈ کلید تبادلہ ترتیب دیں، نفاذ کو تازہ رکھیں، اور جس ساخت پر آپ بھروسہ کرتے ہیں اسے لکھیں۔ ڈیزائن دستاویز میں ML-KEM کا نام لینا سلامتی کی خصوصیت نہیں، اور FIPS 203 کلید کی بندش کا طریقہ کار متعین کرتا ہے، آپ کی سرنگ نہیں۔

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

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