DPD ٹائمر کو مختصر کرنا VPN فیل اوور کو تیز نہیں کرے گا

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

چار مراحل، جن میں سے ایک کا وقت آپ ناپ سکتے ہیں

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

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

ٹائمر سب سے کم دلچسپ عدد کیوں ہے

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

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

واقعی سست مرحلے کی پیمائش کریں

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

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

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

متبادل پہلے ہی قابل استعمال ہونا چاہیے

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

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

فیل بیک کی بے چینی اور انتظامی راستہ

بنیادی کو بحال کرنا ایک الگ فیصلہ ہے۔ جارحانہ فیل بیک اس کام میں خلل ڈال سکتا ہے جو بیک اپ پر پہلے ہی بحال ہو چکا تھا، اور لرزتا راستہ غیر مستحکم سرنگ جیسا لگ سکتا ہے جب اصل خرابی دو برابر اختیارات کے درمیان مسلسل جھولتا راستہ ہو۔

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

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