L2TP NO_PROPOSAL_CHOSEN: اصل میں کون سا مرحلہ ناکام ہوا؟
اطلاع کہتی ہے کہ ایک تجویز مسترد ہوئی، یہ نہیں کہ کون سی۔ مرحلہ معلوم کرنے کے لیے بیک اینڈ لاگ پڑھیں، پھر گیٹ وے چلانے والے سے سیٹوں کا موازنہ کریں۔
NO_PROPOSAL_CHOSEN کسی بھی PPP صارف نام کی جانچ سے پہلے آتا ہے، جو ایک مفید حقیقت ہے اور یہی وجہ ہے کہ پیغام گمراہ کرتا ہے۔ یہ بتاتا ہے کہ ایک فریق نے تجویز مسترد کی؛ یہ نہیں بتاتا کہ کون سا پیرامیٹر مختلف تھا، اور اس بارے میں بھی کچھ نہیں کہتا کہ مسترد ہونا IKE رشتہ بناتے وقت ہوا یا بعد میں ٹریفک کے تحفظ پر بات چیت کے دوران۔ ان دو امکانات کے پیچھے دو مختلف اصلاحات ہیں، اور ان میں سے صرف ایک اس PFS چیک باکس سے متعلق ہے جس کی طرف لوگ پہلے ہاتھ ڈالتے ہیں۔
ایک پیغام، دو تجاویز کے سیٹ
IKEv1 L2TP/IPsec ترتیب میں دو بات چیت یکے بعد دیگرے ہوتی ہیں۔ مرحلہ 1 انکرپشن الگورتھم، سالمیت کے الگورتھم اور Diffie-Hellman گروپ سے IKE سیکیورٹی رشتہ بناتا ہے۔ پھر مرحلہ 2 طے کرتا ہے کہ ٹریفک کی حفاظت کیسے ہوگی، اور PFS کی شرط اسی دوسری گفتگو سے تعلق رکھتی ہے۔
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
چونکہ مراحل یکے بعد دیگرے ہیں، ناکامی کی جگہ بتاتی ہے کہ کون سی فہرست کا موازنہ کرنا ہے۔ پیغام کی پوری تشخیصی قدر اسی میں ہے، اور کسی بھی سیٹنگ کو چھونے سے پہلے اسے نکال لینا مناسب ہے۔
PFS چیک باکس مرحلہ 1 کی مرمت کیوں نہیں کر سکتا
PFS بند کرنا مرحلہ 2 کی ایک خصوصیت بدلتا ہے۔ اگر فریق کبھی مرحلہ 1 پر متفق نہیں ہوئے، تو ESP گفتگو کبھی نہیں ہوتی، اس لیے چیک باکس کا مسترد ہونے پر کوئی اثر نہیں پڑتا، اور اسی لیے اسے تبدیل کرنے سے وہی خرابی مختلف وقت کی مہر کے ساتھ آتی ہے۔
الٹی غلطی بھی اتنی ہی عام ہے۔ کامیاب IKE رشتہ یہ ثابت نہیں کرتا کہ ESP تجویز قابل قبول ہے، اور یہ ہرگز ثابت نہیں کرتا کہ مرحلہ 2 کا گروپ میل کھاتا ہے۔ قائم شدہ انتظامی سرنگ کو صرف مرحلہ 1 کے بارے میں ثبوت سمجھیں۔ لوگ سبز لکیر کو «سرنگ چل رہی ہے» پڑھتے ہیں، پھر غلط مرحلے پر ایک گھنٹہ ضائع کرتے ہیں کیونکہ کسی نے انہیں نہیں بتایا کہ دوسری بات چیت شروع نہیں ہوئی تھی۔
الگورتھم منتخب کرنے سے پہلے لاگ پڑھیں
مسترد ہونے سے فوراً پہلے کے پیغامات اسی بیک اینڈ سے جمع کریں جو واقعی کنکشن سنبھالتا ہے، اور انہیں اسی کوشش سے جوڑیں۔ اس ربط کے بغیر آپ کسی دوسرے کنکشن کی تاریخ پڑھ رہے ہیں اور اس سے نتائج اخذ کر رہے ہیں۔
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanان سطروں سے دو سوالوں کے جواب دیں: کیا مرحلہ 1 کا رشتہ قائم ہوا، اور کون سی تبادلہ ناکام ہوئی۔ یہ دو جواب تلاش کو ایک ہی خصوصیات کی فہرست تک محدود کر دیتے ہیں۔ گرد و نواح کے سیاق و سباق کے بغیر ننگا اعلان یہ نہیں کر سکتا، فورم کے دھاگے سے تجویز آزمانا کتنا ہی پرکشش ہو۔ مختلف بیک اینڈ والی مشین سے کام کرنے والی سٹرنگ کاپی کرنا عام طور پر ایک مسترد ہونے کو دوسرے سے بدل دیتا ہے، تھوڑی دیر بعد۔
بیک اینڈ کی نحو سفر نہیں کرتی
کچھ بھی موازنہ کرنے سے پہلے NetworkManager-l2tp کا ورژن اور IPsec بیک اینڈ کا ورژن لکھ لیں۔ Libreswan اور strongSwan نہ تجویز کی نحو بانٹتے ہیں اور نہ یکساں الگورتھم سیٹ، اس لیے ایک میں چلنے والی سٹرنگ دوسرے میں نحوی غلطی ہے۔ نصب شدہ بیک اینڈ پالیسی کے تحت IKEv1 سے بھی انکار کر سکتا ہے، اور تب کوئی تجویز کبھی قبول نہیں ہوگی۔
منصوبے کا README ان بیک اینڈ فرقوں کو دستاویز کرتا ہے اور مرحلہ 1 اور مرحلہ 2 کے میدان الگ رکھتا ہے۔ اسے ساخت کی دستاویز کے طور پر پڑھیں، ہر تاریخی سائفر اور کمزور گروپ کو فعال کرنے کی دعوت کے طور پر نہیں، کیونکہ صرف اسی طرح کامیاب ہونے والا کنکشن وہ کنکشن نہیں جو آپ کو بنانے کو کہا گیا تھا۔
سیٹ پر اتفاق کریں، پھر مراحل کی تصدیق کریں
گیٹ وے آپریٹر سے پوچھیں کہ کون سے IKE اور ESP سیٹ معاون اور منظور شدہ ہیں، پھر اس جواب کا موازنہ کلائنٹ کی اصل تجاویز سے کریں، اس کی کنفیگریشن فائل سے نہیں۔ اگر اختلاف خاص طور پر مرحلہ 2 کے PFS کے بارے میں ہے، تو کسی معاون گروپ یا واضح طور پر منظور شدہ PFS کے بغیر پالیسی پر فیصلہ کریں۔ خرابی کے نام سے پالیسی کا اندازہ نہ لگائیں۔
جب واحد مشترکہ حصہ ایسی کرپٹوگرافی کا تقاضا کرے جو ادارہ اب قبول نہیں کرتا، تو فیصلہ گیٹ وے یا پروٹوکول کی منتقلی کا ہے۔ کلائنٹ سٹرنگ کو اس وقت تک چوڑا کرنا جب تک کوئی چیز بات چیت نہ کرے، معلوم کمزوری کو ساتھ سبز ٹک لگا کر بھیجنے کا طریقہ ہے۔
اصل عدم مطابقت درست کرنے کے بعد، L2TP اور PPP کی تحقیق سے پہلے IPsec کے قیام کی تصدیق کریں، اور بعد میں ہونے والے کسی بھی تصدیقی انکار کو اگلے مرحلے کا قرار دیں۔ پھر منظور شدہ جانچ کے عمل میں تجدید آزمائیں، کیونکہ پہلے رشتے کا قیام اس کی باقی عمر کے بارے میں کچھ نہیں کہتا۔