L2TP/IPsec ناکام: IPsec، ٹنل کی تصدیق یا PPP لاگ ان الگ کریں

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

تصدیق کے تین مراحل، تین مختلف شناختیں

IPsec ثابت کرتا ہے کہ سرے کس کے ہیں، پہلے سے مشترکہ کلید یا سرٹیفکیٹ استعمال کرتے ہوئے۔ وہ شناخت مشینوں یا گیٹ ویز کی ہوتی ہے، کی بورڈ کے سامنے بیٹھے انسان کی کبھی نہیں۔ جب ساتھی اس مرحلے پر متفق نہیں ہو سکتے، تو کوئی L2TP پیکٹ ہی تبدیل نہیں ہوتا۔

L2TP کنٹرول کنکشن دوسرا، الگ چیلنج جواب تبادلہ شامل کر سکتا ہے، جسے وہ مشترکہ راز چلاتا ہے جو دونوں سروں کے پاس ہونا ضروری ہے۔

RFC 2661 اس کنٹرول کنکشن تصدیق کو اختیاری بناتا ہے، جو بتاتا ہے کہ وہی غلطی دو سرورز پر مختلف علامات کیوں پیدا کرتی ہے۔ جو تعیناتی کبھی ٹنل راز ترتیب نہیں دے پائی، وہ مرحلہ مکمل طور پر چھوڑ دیتی ہے؛ جس نے صرف ایک طرف ترتیب دیا، وہ PPP پیش ہونے سے پہلے ہی ناکام ہو جاتی ہے۔ پھر PPP صارف کی تصدیق PAP، CHAP یا MSCHAPv2 سے کرتا ہے اور نام اس اکاؤنٹ ذخیرے کو دیتا ہے جو مقامی، chap-secrets میں یا RADIUS پر ہو سکتا ہے۔ اس وقت غلط پاس ورڈ پھر بھی آپ کو کام کرتے ٹنل اور ناکام سیشن کے ساتھ چھوڑ دیتا ہے۔

ترتیب بدلنے سے پہلے رکنے کی جگہ پڑھیں

ipsec --version سے شروع کریں تاکہ معلوم ہو کہ حالت کی آؤٹ پٹ strongSwan کی ہے یا Libreswan کی۔ پھر سرور لاگ پڑھیں، کلائنٹ ڈائیلاگ نہیں، کیونکہ سرور درج کرتا ہے کہ کس مرحلے نے انکار کیا۔

عام طور پر ایک سطر ٹکٹ طے کرتی ہے: IKE یا تجاویز کی شکایت پہلا مرحلہ، کنٹرول کنکشن کا پیغام دوسرا مرحلہ، اور PPP طریقہ یا اکاؤنٹ کی نامنظوری تیسرا مرحلہ ہے۔ وہ سطر وقت کی مہر کے ساتھ ٹکٹ میں نقل کریں۔ کلائنٹ کی طرف سے اندازہ لگانا وہ واحد ثبوت ضائع کرتا ہے جو آپ کے پاس پہلے سے ہے۔

کلید کا مواد اور پاس ورڈ اس پیسٹ سے باہر رکھیں؛ مرحلے کا نام کام کی رہنمائی کرتا ہے، اور ظاہر ہو گئی مشترکہ کلید بدتر نتائج کے ساتھ ٹکٹ دوبارہ کھول دیتی ہے۔

پہلا مرحلہ: کیا IPsec کے پاس انجمن ہے؟

strongSwan پر ipsec statusall یا Libreswan پر ipsec whack --status چلائیں اور غیر صفر شمار کنندگان کے ساتھ قائم شدہ چائلڈ انجمن تلاش کریں۔ ip xfrm state دونوں پر کرنل کا منظر دکھاتا ہے۔ بڑھتے شمار کنندگان کے ساتھ نصب SA جوڑا یعنی پہلا مرحلہ مکمل ہو گیا اور آپ آگے بڑھ سکتے ہیں۔

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

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

دوسرا مرحلہ: کیا L2TP کنٹرول کنکشن کی تصدیق ہوئی؟

جب IPsec چل پڑے، تو L2TP ڈیمون میں قائم حالت تک پہنچنے والے کنٹرول کنکشن پر نظر رکھیں، کیونکہ اس سے پہلے PPP شروع نہیں ہو سکتا۔ کنٹرول کنکشن پر انکار کا مطلب ہے کہ ٹنل راز سروں کے درمیان مختلف ہے، یا ایک سرا ایسا راز مانگتا ہے جو دوسرا کبھی نہیں بھیجتا۔ کلائنٹ اکثر shared secret کے لیبل والا ایک ہی خانہ دکھاتے ہیں، اور وہ عام طور پر L2TP کا نہیں بلکہ IPsec کا ہوتا ہے۔ اسے بھرنے سے ٹنل راز ترتیب نہیں پاتا، اور خالی کرنے سے وہ غیر فعال نہیں ہوتا۔

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

صرف وہی سیشن جو PPP کی گفت و شنید شروع کرتا ہے، ٹنل مرحلہ واقعی طے کر چکا ہے۔

تیسرا مرحلہ: کیا PPP اکاؤنٹ نامنظور کر رہا ہے؟

PPP کی ناکامی باہر سے مختلف نظر آتی ہے: ٹنل قائم ہے، سیشن شروع ہوتا ہے، اور ڈیمون تصدیق کے طریقے کی ناکامی یا اکاؤنٹ کی نامنظوری درج کرتا ہے۔ اس پیغام میں مذکور طریقہ پڑھیں۔ PAP اور CHAP مختلف وجوہات سے ناکام ہوتے ہیں، اور جو سرور ایک کو نامنظور کرتا ہے وہ صرف وہی پیش کرنے والے کلائنٹ کو بھی نامنظور کرے گا۔

Linux سرور پر، ڈیمون کی جانب سے PPP کو دی جانے والی اختیارات فائل، عام طور پر /etc/ppp/options.xl2tpd، دیکھیں اور تصدیق کریں کہ کون سے طریقے قبول کیے جاتے ہیں اور اکاؤنٹس کہاں حل ہوتے ہیں۔ RADIUS میں موجود مگر مقامی راز فائل میں نہ ہونے والا نام صاف ناکام ہوتا ہے اور غلط پاس ورڈ جیسا لگتا ہے۔ پھر دیکھیں کہ کلائنٹ وہ طریقہ پیش کرتا ہے جو سرور قبول کرتا ہے، نہ کہ زیادہ مضبوط طریقہ جس کی گفت و شنید سرور نامنظور کرتا ہے۔ اس مرحلے کو ٹھیک کرنے کے لیے پہلے سے مشترکہ کلید بدلنا دوپہر ضائع کرتا ہے اور کچھ نہیں بدلتا۔

جب سیشن آخرکار اٹھتا ہے، پتہ تفویض، DNS اور راستے ابھی جانچے نہیں گئے، اور ہر ایک اپنے اپنے انداز میں خاموشی سے ناکام ہوتا ہے۔ اپنے نوٹس میں تینوں تہیں الگ رکھیں: درست کلید اور غلط اکاؤنٹ ہمیشہ ناکام ہوتا ہے، اور ایک تہہ درست کرنا کبھی دوسری کو درست نہیں کرتا۔