بڑی OpenVPN کلید دوبارہ کلید بنانے کے ٹائمر کو کیوں ختم نہیں کرتی

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

سائفر کو چھونے سے پہلے دوبارہ کلید بنانے کی ترتیبات پڑھیں، اور ایسا کرتے وقت دونوں طرف پڑھیں۔

کلید کی طاقت اور کلید کی عمر مختلف سوالوں کے جواب دیتی ہیں

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

تعیناتی کے نوٹ میں دونوں لکھیں: ڈیٹا چینل کی حفاظت کیا کرتا ہے اور اس کی کلیدوں کی تبدیلی کیا شروع کرتی ہے۔

دوبارہ کلید بنانے کے تین محرکات ہیں، اور کوئی بھی فریق انہیں چلا سکتا ہے

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

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

دوبارہ کلید بنانا توثیق کے بہاؤ کو کھول دیتا ہے

دوبارہ مذاکرات ایک نیا TLS ہینڈ شیک ہے، یعنی توثیق کا راستہ پھر چلتا ہے۔ ایک بار کے کوڈ، ہارڈویئر ٹوکن یا RADIUS چیلنج استعمال کرنے والی تعیناتیاں یہ مشکل طریقے سے جانتی ہیں: پہلا کنکشن کام کرتا ہے اور ایک گھنٹے بعد سیشن مر جاتا ہے، جب دوسرا ہینڈ شیک پہلے ہی استعمال شدہ کوڈ مانگتا ہے۔ auth-gen-token اسی خلا کو پر کرنے کے لیے موجود ہے، سرور کو نیا متعامل لاگ ان مانگنے کے بجائے دوبارہ مذاکرات کے لیے قلیل المدت ٹوکن جاری کرنے دیتا ہے۔

اسے آپریٹر کے ساتھ حل کرنے والا ورک فلو مسئلہ سمجھیں، تجدید بند کرنے کی ضرورت کا ثبوت نہیں۔

تجدید کو بوجھ کے نیچے جانچیں، ایک منٹ کے سیشن میں نہیں

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

کامیاب بڑی منتقلی کو کرپٹوگرافک حد کا ثبوت نہ پڑھیں۔ یہ صرف دکھاتی ہے کہ راستے اور شمار کنندگان نے اتنی ٹریفک برداشت کی۔

دونوں انتخابات درج کریں

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

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