تصدیق کا ناکام ہونا یعنی سروس نے کوئی شناخت وصول کی اور اسے مسترد کر دیا، جو زیادہ تر لوگوں کے تصور سے زیادہ محدود بات ہے۔ پورٹ کھلا ہے، TLS سیشن مکمل ہو چکا ہو سکتا ہے، اور اسناد یا اکاؤنٹ میں کچھ مسترد ہوا ہے۔ خرابی کا متن پہلے ہی مرحلہ بتا دیتا ہے، لہٰذا وہیں سے شروع کریں۔

خرابی پہلے ہی بتا چکی ہے کہ کون سا مرحلہ ناکام ہوا

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

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

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

تصدیق کریں کہ پروفائل صحیح سروس کی طرف اشارہ کرتا ہے

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

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

پروفائل پر دو منٹ خرچ کرنا اسناد کے اندازے کے ایک دن کو روکتا ہے۔

لاگ اِن کی شکل اسناد کا حصہ ہے

صارف نام کو ای میل شکل، ڈومین سابقہ یا ڈائریکٹری لاحقہ درکار ہو سکتا ہے۔ گیٹ وے موصول شدہ سٹرنگ کا موازنہ کرتا ہے، لہٰذا شکل آرائش نہیں، اسناد کا حصہ ہے۔

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

openvpn --config office.ovpn --verb 3
journalctl -u openvpn-client@office -n 40 --no-pager

AUTH_FAILED والی لاگ سطر میں عموماً وجہ کا کوڈ یا چیلنج سٹرنگ ہوتی ہے۔ مدد مانگتے وقت اسے دوبارہ کہنے کے بجائے بالکل ویسا ہی نقل کریں۔

دوسرے عوامل کا اپنا معاہدہ ہے

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

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

سیشن کی حد دوسری عام مستردگی ہے۔ اگر اکاؤنٹ ایک سیشن کی اجازت دیتا ہے تو دوسرا لاگ اِن پہلے کو ختم کر سکتا ہے، اور علامت پالیسی کی بجائے لرزتے کنکشن جیسی دکھتی ہے۔

سرٹیفکیٹ پاس ورڈ نہیں ہے

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

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

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

متعلقہ مضامین