L2TP پر NO_PROPOSAL_CHOSEN؟ پہلے گیٹ وے اسکین کریں

صارف نام کا پرامپٹ کبھی ظاہر نہیں ہوتا، اور کلائنٹ NO_PROPOSAL_CHOSEN رپورٹ کرتا ہے۔ اس لمحے اسناد اور پہلے سے مشترکہ چابی بے معنی ہیں، کیونکہ دونوں سرے فیز 1 کے تحفظ پر متفق نہیں ہوئے۔ زیادہ تر لوگ آن لائن ملنے والی سائفر اسٹرنگ چپکا کر جواب دیتے ہیں۔ گیٹ وے اسکین کرنا اسی سوال کا ثبوتوں کے ساتھ جواب دیتا ہے اور تقریباً اتنا ہی وقت لیتا ہے۔

پیغام کیا خارج کرتا ہے

انکار مرکزی موڈ میں، کسی بھی L2TP یا PPP تبادلے سے پہلے ہوتا ہے، اس لیے سرنگ اور صارف ڈیٹا بیس سے پوچھا نہیں گیا۔ فیز 1 خفیہ کاری، سالمیت اور Diffie-Hellman گروپ پر بات چیت کرتا ہے۔ فیز 2 ڈیٹا کے لیے ESP تجویز پر بات چیت کرتا ہے۔ فیز 1 کی ناکامی فیز 2 کی PFS سیٹنگ بدل کر درست نہیں کی جا سکتی، اور مکمل شدہ IKE ربط ثابت نہیں کرتا کہ ESP تجویز موزوں ہے۔

نحو میں ترمیم سے پہلے backend نوٹ کریں: ipsec --version۔ libreswan اور strongSwan ایک ہی الگورتھم کے لیے تجویز کی مختلف ہجے قبول کرتے ہیں۔

پھر انکار کو سیاق میں اس کے ساتھ پڑھیں: journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd۔

گیٹ وے کا ٹرانسفارم سیٹ اسکین کریں

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

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

پرانے آلات اکثر 3DES، SHA1 اور MODP1024 پیش کرتے ہیں، کیونکہ مصنوعات کی ترسیل کے وقت یہی ڈیفالٹ تھے اور کسی نے ان کا دوبارہ جائزہ نہیں لیا۔ اسکین کا خام آؤٹ پٹ رکھیں، کیونکہ اسی دن دوسرے سرے نے کیا پیش کیا اس کا یہی واحد ریکارڈ ہے۔ اگر یہی دستیاب مضبوط ترین اوورلیپ ہے، تو درست اسکیلیشن گیٹ وے کے مالک کی طرف ہے، نہ کہ ایسی کلائنٹ کنفیگریشن کی طرف جو سب کے لیے کمزور خفیہ کاری دوبارہ فعال کرتی ہے۔

سلامتی بند کیے بغیر اوورلیپ ملائیں

صرف وہی ٹرانسفارمز درج کریں جو اسکین اور آپ کی پالیسی دونوں میں نظر آئیں۔ نیچے کی مثال فیز 1 میں 3DES، SHA1 اور MODP1024 پیش کرنے والے گیٹ وے کی عکاسی کرتی ہے۔ backend کی تنبیہ پر توجہ دیں: libreswan 4.x modp1024 گروپ کو کمپائل نہیں کرتا، اس لیے یہ strongSwan یا DH2 معاونت والے libreswan بلڈ پر لاگو ہوتا ہے۔ کلائنٹ کو خراب ماننے سے پہلے ورژن کی تصدیق کریں۔

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

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

دوبارہ کوشش سے پہلے ڈیمون اور پورٹ جانچیں

NetworkManager-l2tp اپنا xl2tpd انسٹانس شروع کرتا ہے۔ اگر نظامی سروس کے پاس پہلے سے UDP 1701 ہے، تو کلائنٹ عارضی ماخذ پورٹ پر چلا جاتا ہے، جس کی RFC 3193 اجازت دیتا ہے اور کچھ سرور خاموشی سے گر دیتے ہیں۔ اگلی کوشش سے پہلے ساکٹ کے مالک کی جانچ کریں۔

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

باسی پیدا شدہ راز ایک اور خاموش وجہ ہیں۔ یہاں کی فائلیں /etc/ipsec.d/ پرانے کنکشن کے نام پر رکھی فائلیں انھیں بنانے والی پروفائل سے زیادہ عرصہ زندہ رہ سکتی ہیں، اس لیے جن کا کوئی حوالہ نہیں دیتا انھیں ہٹائیں اور دوبارہ کوشش کریں۔

آخر میں، جانچیں کہ مشورہ کہاں سے آیا۔ ipsec.conf IKEv1 XAuth کے لیے لکھی گئی فائل کسی اور قسم کے VPN کی وضاحت کرتی ہے، اور L2TP پروفائل میں اس کی تجویز ہی واحد غلط لائن نہیں ہوگی۔ آپ نے جو ٹرانسفارم سیٹ درج کیا اسے پروفائل کے ساتھ نوٹ کریں، تاکہ اگلا شخص جانچ دہرائے نہ۔