ہر بار چابیاں بدلنے پر آپ کا VPN کیوں گرتا ہے
شیڈول کے مطابق مرنے والی سرنگ عام طور پر تجدید کے تبادلے میں ناکام ہوتی ہے، ابتدائی مصافحے میں نہیں۔ تجاویز، اسناد اور تبدیلی کی حالت کا موازنہ کریں۔
کنکشن ایک گھنٹہ چلتا ہے اور پھر مر جاتا ہے، اور کلائنٹ disconnected سے زیادہ مفید کچھ نہیں بتاتا۔ یہی مدت سراغ ہے، کیونکہ تجدید کے تبادلے میں کچھ ابتدائی مصافحے سے مختلف ہے۔ ٹائمر صرف یہ طے کرتا ہے کہ آپ اس سے کب ملیں گے۔ آخری لیبل کے بجائے اس تبادلے کے پیغامات محفوظ کریں۔
لیبل نہیں، مرحلہ پڑھیں
IKEv2 میں IKE ایسوسی ایشن اور CHILD ایسوسی ایشن الگ الگ شیڈول پر تجدید ہوتی ہیں۔ پہلی گفت و شنید کے لیے قابل قبول تجویز دوسری کے لیے خودکار طور پر قابل قبول نہیں۔ ایک مکمل ہو سکتی ہے جبکہ دوسری مسترد ہو، جس سے آدھی موجود سرنگ بنتی ہے۔ تبادلہ کلائنٹ لاگ لائن کے بجائے اسے رکھنے والے آلے سے ریکارڈ کریں:
swanctl --list-sas
swanctl --log --level 2
ip xfrm state list
OpenVPN کے لیے مساوی واقعہ وہ دوبارہ گفت و شنید ہے جسے ورژن اور تعیناتی کی ترتیبات کنٹرول کرتی ہیں۔ اس کے تصدیق کے رویے کے اپنے ناکامی کے طریقے ہیں۔ اہم پیغام ناکام مرحلے کا نام لیتا ہے، اور آپ کو اسے ٹکٹ میں دوبارہ لکھنے کے بجائے لفظی طور پر درج کرنا چاہیے۔
وقت کی مہریں بھی لکھیں۔ آخری کامیاب گفت و شنید کے بعد مقررہ وقفے پر گرنا استعمال کے دوران بے ترتیب آنے والے گرنے سے بالکل مختلف نتیجہ ہے، اور وقفہ ہی اکثر واحد ثبوت ہوتا ہے جو بچتا ہے۔
ناکام ہونے والی تجویز کا موازنہ کریں
مسترد شدہ تجویز جواب دینے والے پر واضح پیغام پیدا کرتی ہے۔ عام وجہ دونوں سروں کے درمیان الگورتھم، چابی کی لمبائی، گروپ یا مدت میں فرق ہے۔ ابتدائی CHILD گفت و شنید اس لیے کامیاب ہو سکی کہ دوسرے فریق نے اسے شروع کیا، یعنی دوسرے فریق کی تجاویز کی فہرست استعمال ہوئی۔ کچھ بھی بدلنے سے پہلے دونوں سرے دیکھیں۔
مدت میں تفاوت خاص توجہ کا مستحق ہے، کیونکہ ایک سرے پر فراخ نظر آنے والی قدر دوسرے سرے کو ایسی تجدید شروع کرنے پر مجبور کر سکتی ہے جو وہ مکمل نہیں کر سکتا۔ چابی تبدیلی کے رویے کی دستاویز بیان کرتی ہے کہ ایسوسی ایشن کی تجدید کیسے شروع ہوتی ہے اور دونوں سرے اپنے وقت کے توقعات میں کیسے مختلف ہو سکتے ہیں۔ کنفیگریشن فائل کے اشارے کے بجائے یہ موازنہ کریں کہ ہر سرا کس چیز کی حمایت کا دعویٰ کرتا ہے۔
پرانا پروفائل یا فراہم کنندہ کا ٹیمپلیٹ ایسی تجویز پن کر سکتا ہے جو موجودہ ریلیز اب فراہم نہیں کرتی۔ تفاوت صرف اس وقت ظاہر ہوتا ہے جب نئی گفت و شنید پر مجبور کیا جائے۔
اسناد کے مسئلے کو ناقابل رسائی ساتھی سے الگ کریں
تصدیق میں ناکام ہونے والی تجدید کلائنٹ میں یکساں اور سرور پر بالکل مختلف نظر آتی ہے۔ اگر دوبارہ گفت و شنید میں اسناد دوبارہ جانچی جائیں، تو میعاد ختم شدہ سرٹیفکیٹ، منسوخ شدہ اکاؤنٹ یا بدلا ہوا پاس ورڈ تمام پچھلے کنکشن کامیاب ہونے کے باوجود ٹھیک تجدید کے وقفے پر گرنے کا سبب بنے گا۔ ناقابل رسائی ساتھی تیسری امکان ہے، اور یہ کوئی رد پیدا نہیں کرتا: پیکٹ نکل جاتے ہیں اور کوئی جواب نہیں دیتا۔ وہ حالت عام طور پر ٹائمر کے بجائے نیٹ ورک کی تبدیلی کی پیروی کرتی ہے، اس لیے جانچیں کہ ناکامی رومنگ، غیر فعال مدت یا راستے کی تبدیلی کے بعد آتی ہے یا نہیں۔
تینوں کو اس بات سے الگ کریں کہ دور والے سرے نے کیا درج کیا۔ وجہ کے ساتھ رد، تصدیق کی ناکامی اور خاموشی تین مختلف اصلاحات ہیں۔ کلائنٹ کو دوبارہ شروع کرنا انہیں ایک بیکار مشاہدے میں سمیٹ دیتا ہے۔
نیٹ ورک کو الزام دینے سے پہلے سرٹیفکیٹ کی تاریخیں اور اکاؤنٹ کی حالت جانچیں۔ دونوں جانچنا سستا ہے اور دونوں کلائنٹ کے اپنے پیغام میں پوشیدہ ہیں۔
ایک تجدید پر مجبور کریں اور نتیجہ پڑھیں
اگلی کے لیے ایک گھنٹہ انتظار کرنے کے بجائے آپریٹر کے معاون طریقے سے ایک تجدید پر مجبور کریں۔ ایسا کرتے ہوئے مطلوبہ ناکامی کی پالیسی کو برقرار رکھیں۔ تصدیق بند کرنا یا مدتیں ایک دن تک بڑھانا کچھ بھی درست کیے بغیر آپ کے لاگز سے علامت غائب کر دیتا ہے۔ یہ اگلے شخص کے لیے طویل رکاوٹ بھی چھوڑتا ہے۔
اصلاح ہو جانے کے بعد، تجدید شدہ سرنگ جانچیں اور پھر ایپلیکیشن سے نئی درخواست کریں۔ ایسوسی ایشن بدلنے کے وقت زندہ رہنے والے ایپلیکیشن سیشن کو سرنگ دوبارہ صحت مند ہونے پر بھی اپنی بحالی کی ضرورت ہو سکتی ہے۔ صارفین اسے VPN اب بھی خراب ہونے کے طور پر رپورٹ کریں گے۔
ریلیز ورژن، طے شدہ ٹائمر اور ناکام مرحلہ درج کریں۔ اگلی تکرار کا موازنہ تب یادداشت سے دوبارہ بیان کرنے کے بجائے اس سے کیا جا سکے گا۔