IKEv2 تبادلہ کام کرتا ہے، پھر تصدیق ناکام ہوتی ہے: کہاں دیکھیں

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

جانچ 1: پیغام نہیں، مرحلہ پڑھیں

مسترد ہونا تین جگہوں سے آ سکتا ہے: کلائنٹ سرور کی شناخت مسترد کرتا ہے، گیٹ وے کلائنٹ کا ثبوت مسترد کرتا ہے، اور کوئی بیرونی تصدیقی سروس اکاؤنٹ مسترد کرتی ہے۔

ہر ایک مختلف مشین پر مختلف لاگ لائن بناتا ہے، اور ہر ایک کا مختلف حل ہے۔ کلائنٹ کی طرف سے سرور سرٹیفکیٹ مسترد کرنا کلائنٹ پر اعتماد یا نام دینے کا مسئلہ ہے؛ گیٹ وے کی طرف سے کلائنٹ سرٹیفکیٹ مسترد کرنا گیٹ وے پر اعتماد کا مسئلہ ہے؛ EAP کی ناکامی اکاؤنٹ یا بیک اینڈ کا مسئلہ ہے۔ آپ جو پیغام دیکھتے ہیں وہ عام طور پر ان میں سے کسی ایک کے بارے میں کلائنٹ کا خلاصہ ہے، اسی لیے گیٹ وے کا لاگ کلائنٹ کے لاگ جتنا ہی اہم ہے۔

جانچ 2: کون سی شناخت جانچی گئی

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

strongSwan کی اصطلاح میں یہ کلائنٹ پر rightid ہے اور دوسری طرف گیٹ وے کی اپنی شناخت، اور EAP پر بات ہونے سے پہلے ہی عدم مطابقت ناکام ہو جاتی ہے۔

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

جانچ 3: اگر EAP شامل ہو

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

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

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

جانچ 4: کامیاب لاگ ان کے بعد کیا ہوتا ہے

IKE_AUTH مکمل ہونے کے بعد، CHILD_SA مذاکرات طے کرتے ہیں کہ کون سے ٹریفک منتخب کنندگان نصب ہوں گے، اور وہیں کنکشن کامیاب ہو کر بھی کچھ منتقل نہیں کر سکتا۔

نیا کام کرنے والا لاگ ان اکثر ایسا منتخب کنندہ یا راستہ کا مسئلہ سامنے لاتا ہے جو پہلے تصدیق کی ناکامی کے پیچھے چھپا ہوا تھا۔ اگر ٹنل اوپر آ جائے اور کوئی ایپلیکیشن پھر بھی اپنی منزل تک نہ پہنچے، تو دوبارہ شناخت کے بجائے طے شدہ منتخب کنندگان اور راستوں کو دیکھیں۔ اس وقت شناخت کی ترتیبات بدلنا غلط مرحلے کو نشانہ بناتا ہے اور عام طور پر کام کرنے والا لاگ ان توڑ دیتا ہے۔ swanctl --list-sas سے تصدیق کریں، جو IKE SA سے الگ بچوں اور ان کے منتخب کنندگان دکھاتا ہے۔

جانچ 5: معاونت کو کیا دیں

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

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