OpenVPN میں TLS ہینڈ شیک ناکام: آپ کس شاخ پر ہیں؟

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

ناکامی سے پہلے کا آخری واقعہ پڑھیں

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

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

درست پہلی خرابی طویل لاگ اقتباس سے زیادہ قیمتی ہے۔ یہ مرحلے کا نام لیتی ہے، اور مرحلہ مالک کا نام لیتا ہے۔

شاخ ایک: کچھ واپس نہیں آیا

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

اسی ہوسٹ نام پر صفحہ لوڈ کرنے والا براؤزر صرف یہ ثابت کرتا ہے کہ کسی ویب سروس نے جواب دیا۔ قبول شدہ TCP کنکشن بھی OpenVPN کے گفت و شنید مکمل کرنے کے بارے میں کچھ نہیں کہتا۔

اگر پروفائل کسی اور قابل اعتماد نیٹ ورک پر کام کرتا ہے تو وہ موازنہ رکھیں۔ یہ پابندی کو راستے یا واسطے تک محدود کرتا ہے۔

شاخ دو: کنٹرول چینل میل نہیں کھاتا

جب تبادلہ شروع ہو کر رک جائے، تو کنٹرول چینل کی ترتیبات پہلا شبہ ہیں۔ tls-auth اور tls-crypt کو تعیناتی سے میل کھانا چاہیے، اور دوسرے سرور کا مواد مفید تبادلہ نہیں دے گا۔ یہ ناکامی کسی بھی اکاؤنٹ لاگ ان سے پہلے ہوتی ہے۔ پرانے سرور سے نقل کیا گیا پروفائل عام ذریعہ ہے۔

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

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

شاخ تین: سرٹیفکیٹ مسترد ہوا

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

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

لکھیں کہ ناکامی نیٹ ورک کے پیچھے چلتی ہے یا پروفائل کے۔ ہر جگہ نظر آنے والی سرٹیفکیٹ خرابی راستے کا مسئلہ نہیں۔

شاخ چار: گفت و شنید ختم ہوئی اور کچھ اور ناکام ہوا

شناخت کے تبادلے کی کامیابی کے بعد، باقی ناکامی توثیق یا راستہ بندی کی ہے۔ اکاؤنٹ کا واضح انکار توثیق کا سوال ہے، اور ناقابل رسائی سائٹوں والا منسلک ٹنل راستہ بندی یا DNS کا سوال ہے۔ اس وقت TLS اختیارات بدلتے رہنا پہلے سے کام کرنے والے مرحلے کو نقصان پہنچاتا ہے۔

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