مصروف IPsec ٹنل جلدی کلیدیں کیوں بدلتا ہے: وقت اور حجم کی حدیں
بائٹ کی حد گھنٹہ ختم ہونے سے بہت پہلے متحرک ہو سکتی ہے۔ نرم اور سخت عمر، انجمن کا استعمال کردہ شمار کنندہ، اور تبدیلی کا تبادلہ موازنہ کریں۔
تقریباً ہر پچاس منٹ بعد مصروف لنک پر ٹنل چند سیکنڈ کے لیے گر جاتی ہے، اور پہلا مشتبہ گھڑی ہے۔ انجمنیں وقت کی حد یا بائٹ کی گنتی پر ختم ہو سکتی ہیں، اور جو حد پہلے آئے وہی انہیں ریٹائر کرتی ہے۔ حقیقی ٹریفک لے جانے والے لنک پر حجم کی حد مقررہ گھنٹہ ختم ہونے سے بہت پہلے متحرک ہو سکتی ہے۔ لہٰذا «بہت جلدی» گھڑی کے بارے میں بیان ہے، انجمن کے بارے میں نہیں۔
انٹرفیس نہیں، انجمن جو گنتی ہے وہ گنیں
انٹرفیس کا کل بائٹ، ڈیش بورڈ کا مشترکہ تھرو پٹ اور انجمن کا اپنا شمار کنندہ تین الگ اعداد ہیں، اور ان میں سے صرف ایک حد سے موازنہ کیا جاتا ہے۔ آنے والی اور جانے والی انجمنوں کو ان کے شناخت کنندگان کے ساتھ الگ ریکارڈ کریں، تاکہ ایک سمت کو چھونے والی کلید کی تبدیلی معمہ کے بجائے سمتی واقعہ کے طور پر ظاہر ہو۔ انجمن کا شمار کنندہ بھی کلید کی تبدیلی پر دوبارہ شروع ہوتا ہے، اسی لیے انٹرفیس سے لیا گیا کل بڑھتا ہے جبکہ اہم قدر ری سیٹ ہوتی ہے۔
حساب ایک بار کرنا قابلِ قدر ہے تاکہ مقدار کا ترتیب بے ترتیب محسوس ہونا بند کرے۔ ایک گبی بائٹ کا گنا ہوا بجٹ جو فی منٹ مستقل 128 میبی بائٹ کی رفتار سے خرچ ہوتا ہے آٹھ منٹ میں ختم ہو جاتا ہے، اور یہ اکائی کی تبدیلی ہے، آپ کی ٹنل کی پیمائش نہیں۔ اگر نتیجہ عدد وقت کی حد سے بہت نیچے ہو، تو حجم ہی طریقہ کار ہے اور گھڑی دیکھنے سے وقفہ واضح نہیں ہوگا۔ اگر وہ بہت اوپر ہو، تو بائٹ کی حد آپ کا محرک نہیں اور تلاش کہیں اور ہے۔
نرم اور سخت حد دو مختلف واقعات ہیں
سخت حد کے انجمن ختم کرنے سے بہت پہلے نرم حد تبدیلی مانگتی ہے، اور عمل درآمد آپ کی ترتیب کردہ چیز کے اوپر اپنے مارجن اور بے ترتیبیت شامل کرتے ہیں۔ اسی لیے مشاہدہ شدہ وقفہ تقریباً کبھی گول عدد نہیں ہوتا۔ IPsec معماری عمر کو وقت اور بائٹ گنتی میں دو قسم کی حدوں کے ساتھ بیان کرتی ہے، اور پہلے ختم ہونے والی ہی لاگو ہوتی ہے۔ اگر آپ ایک چھپی ہوئی عمر کو شیڈول سمجھیں تو مارجن کے برابر غلط ہوں گے۔
مؤثر پالیسی فائل کے عدد سے اندازہ لگانے کے بجائے چلتی حالت سے پڑھیں، کیونکہ مارجن عمل درآمد کا ہے، آپ کے ارادے کا نہیں۔ علامات کو خاموش کرنے کے لیے حدوں کو ان کی زیادہ سے زیادہ تک کھینچنے کی آزمائش کا مقابلہ کریں: شیڈول کے مطابق کلیدیں بدلنے والی ٹنل ڈیزائن کے مطابق برتاؤ کرتی ہے، اور طویل عمر واقعہ کو صرف مؤخر کرتی ہے اور سمجھوتہ شدہ کلید کو زیادہ دیر قابلِ استعمال رکھتی ہے۔ جب تبدیلی خود ناکام ہو، تو حد پیغامبر ہے، قصور نہیں۔
چلتی حالت سے مؤثر عمر پڑھیں
strongSwan پر، swanctl --list-sas انجمن کا خلاصہ اس کے کلید کی تبدیلی اور عمر کے اوقات کے ساتھ چھاپتا ہے، اس لیے ڈیمن جو قدر نافذ کرنا چاہتا ہے وہ اندازے کے بغیر نظر آتا ہے۔ ڈیمن کے منظر کے بغیر Linux میزبان پر، ip xfrm state ترتیب شدہ نرم اور سخت بائٹ اور پیکٹ حدیں موجودہ شمار کنندگان کے ساتھ بتاتا ہے۔ یہ دو پڑھائیاں مختلف سوالات کا جواب دیتی ہیں اور دونوں ٹکٹ میں رکھنے کے قابل ہیں۔
swanctl --list-sas
ip -s xfrm state
چھپی ہوئی نرم حد کا آپ کی ناپی گئی وقفہ سے موازنہ کریں، کیونکہ سخت حد کے نیچے مارجن کے ساتھ شروع ہونے والی تبدیلی معمول ہے اور کبھی شروع نہ ہونے والی نہیں۔ اگر ڈیمن ایک عمر دکھائے اور کرنل حالت دوسری، تو آپ دو غیر متفق تہوں کو دیکھ رہے ہیں، اور یہ بذات خود دریافت ہے۔
SA کو بدلنے والے تبادلے پر نظر رکھیں
تین تجديدات کو الگ رکھیں، کیونکہ وہ مختلف طریقوں سے ناکام ہوتے ہیں: IKE SA کلید کی تبدیلی نئی کنٹرول انجمن بناتی ہے، CHILD SA کلید کی تبدیلی ڈیٹا انجمن کو بدلتی ہے، اور دوبارہ توثیق شناخت کا تبادلہ دہراتی ہے۔ IKEv2 میں ہر ساتھی ایک مشترک قدر پر بات چیت کرنے کے بجائے اپنی عمریں خود طے کرتا ہے، اس لیے جو تبادلہ آپ نے شروع نہیں کیا وہ معمول ہے۔ perfect forward secrecy میں عدم مطابقت نئی child SA کے بالکل کلید کی تبدیلی کے وقفے پر مرنے کی بار بار وجہ ہے، اور جب تک کوئی تجویز نہ پڑھے یہ بالکل ٹائمر کی خرابی جیسی دکھتی ہے۔
پرانی انجمن کا اس کے جانشین اور اس تبادلے سے موازنہ کریں جس نے اسے پیدا کیا۔ شناخت کنندہ کا غائب ہونا معمول کی تبدیلی ہے؛ مسترد شدہ تجویز، غائب جواب یا قابلِ استعمال جانشین حالت کی عدم موجودگی دوسرے مالک کا دوسرا واقعہ ہے۔ کچھ بھی بدلنے سے پہلے وہ ثبوت محفوظ کریں، کیونکہ ورژن کے مخصوص نوٹس، ساتھی کی تجویز اور طے شدہ عمریں ہی لاگ گھومنے کے بعد ایک ہفتہ بعد بھی معاملہ پڑھنے کے قابل بناتی ہیں۔
چھپانے کے بجائے تجدید ثابت کریں
نفاذ کو اپنی طرف سے ہونے والی تجدید کے بجائے اپنی منصوبہ بند تجدید سے گزر کر قبول کریں۔ دیکھ بھال کی کھڑکی کے اندر ایک کلید کی تبدیلی پر مجبور کریں، پھر تصدیق کریں کہ بعد میں دونوں سمتیں ڈیٹا لے جاتی ہیں اور ایپلیکیشن کا نتیجہ تبدیل نہیں ہوا، صرف یہ نہیں کہ ٹنل کا اشارہ سبز ہے۔ ریکارڈ کریں کہ کون سی حد متحرک ہوئی اور کون سا تبادلہ شامل تھا۔
اس شکل کا نتیجہ جانچ میں ٹک جاتا ہے، لیکن وہ بدلی ہوئی ٹائمر قدر جو کنکشن کو ایک دوپہر خاموش دکھاتی رہی نہیں ٹکتی۔ اگر صرف ٹائمر ہلا، تو ثبوت بھی اس کے ساتھ ہلا۔