گیٹ وے کا سرٹیفکیٹ درست ہے: IKEv2 PEAP لاگ اِن پھر بھی کیوں ناکام ہوتا ہے

آپ کے VPN گیٹ وے کا سرٹیفکیٹ درست ہے، زنجیر کی توثیق ہوتی ہے، اور IKEv2 کلائنٹ پھر بھی سرٹیفکیٹ کی مدتِ اعتبار کے بارے میں پیغام کے ساتھ لاگ اِن مسترد کر دیتا ہے۔ پہلا تاثر گیٹ وے کا سرٹیفکیٹ دوبارہ جاری کرنا یا EAP طریقہ بدلنا ہوتا ہے، اور دونوں عام طور پر غلط ہیں۔ لاگ اِن کی کوشش دو الگ سرور شناختیں ساتھ لاتی ہے: وہ گیٹ وے سرٹیفکیٹ جو IKE استعمال کرتا ہے، اور وہ سرٹیفکیٹ جو PEAP ختم کرنے والا پیش کرتا ہے۔ ان میں سے ایک درست ہے، اور دوسرا ہی وہ وجہ ہے کہ کلائنٹ رکا۔

دو شناختیں، ایک لاگ اِن کوشش

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

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

لاگ کی سطر کو مرحلے کے مقابل پڑھیں

وہ پیغام تلاش کریں جس میں وجہ اور تاریخیں بیان ہوں۔ موضوع کی خرابی کے ساتھ مدتِ اعتبار کی شکایت کا مطلب ہے کہ سرور نے وہ سرٹیفکیٹ مسترد کیا جو اسے دیا گیا، یہ نہیں کہ صارف نے لاگ اِن مسترد کیا۔ پھر مرحلہ تلاش کریں: strongSwan کا charon لاگ EAP تبادلہ شروع ہونے سے پہلے IKE_SA .* established دکھاتا ہے، اس لیے اس سطر کے بعد کی سرٹیفکیٹ خرابی EAP شناخت کی ہے، جبکہ اس سے پہلے کی خرابی گیٹ وے کی طرف اشارہ کرتی ہے۔ Windows کلائنٹ کے کنکشن پینل میں مرحلے کا متن بھی یہی کہتا ہے۔

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

معلوم کریں کہ PEAP کو کون سا آخری نقطہ ختم کرتا ہے

گیٹ وے اور RADIUS کی ساخت میں گیٹ وے EAP آگے بھیجتا ہے اور اسے ختم نہیں کرتا۔ strongSwan کا eap-radius پلگ اِن تبادلہ RADIUS سرور کے حوالے کرتا ہے، جس کے پاس PEAP TLS سیشن اور اس کا سرٹیفکیٹ ہوتا ہے۔ دونوں لاگوں میں ایک ناکام کوشش کو ملا کر دیکھیں اور تصدیق کریں کہ اس سیشن کے لیے کس عمل نے واقعی سرٹیفکیٹ منتخب کیا۔

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

سرٹیفکیٹ وہاں بدلیں جہاں EAP ختم ہوتا ہے

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

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

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

کیا نہ کریں

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

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