L2TP: مہلک سگنل 15، NO_PROPOSAL_CHOSEN اور غائب modp1024

آپ کا کنکشن رک جاتا ہے، کلائنٹ باہر نکل جاتا ہے، اور اسکرین پر آخری سطر death_handler: Fatal signal 15 received ہوتی ہے۔ وہ سطر رکاوٹ کی اطلاع دیتی ہے، وجہ کی نہیں۔ IPsec لاگ میں ایک سطر اوپر تقریباً ہمیشہ NO_PROPOSAL_CHOSEN ہوتا ہے، اور یہ جوڑا تبادلے کے مرحلہ 2 کی طرف اشارہ کرتا ہے، جہاں دونوں فریق انکرپشن اور ہیش کے انتخاب کا موازنہ کرتے ہیں اور جب کوئی مشترک چیز نہ ہو تو رک جاتے ہیں۔ اس مرحلے پر اسناد ابھی نہیں بھیجی گئیں، اس لیے پاس ورڈ دوبارہ لکھنے سے نتیجہ نہیں بدلے گا۔

لینکس کلائنٹ پر عام طور پر دو چیزیں اس اشتراک کو خالی کرتی ہیں۔ مقامی ڈیمن اب پروفائل کے مانگے ہوئے Diffie-Hellman گروپ کو نافذ نہیں کرتا، یا پروفائل مرحلہ 1 کی تجویز کو مرحلہ 2 کے خانے میں رکھتا ہے۔ دونوں لاگ میں نشان چھوڑتے ہیں، اور ان میں سے کوئی بھی اکاؤنٹ کا مسئلہ نہیں ہے۔

یہ دو پیغام دراصل کیا کہتے ہیں

IKE مرحلوں میں گفت و شنید کرتا ہے۔ مرحلہ 1 محفوظ چینل بناتا ہے اور اپنے الگورتھم چنتا ہے؛ مرحلہ 2، یعنی چائلڈ SA، ٹریفک کو الگ سیٹ کے تحت لے جاتا ہے۔ NO_PROPOSAL_CHOSEN وہ اطلاع ہے جو جواب دینے والا اس وقت واپس بھیجتا ہے جب پیش کردہ امتزاج میں سے کوئی قابل قبول نہ ہو، اور یہ INFORMATIONAL تبادلے کے اندر [ HASH N(NO_PROP) ] کی صورت میں ظاہر ہوتی ہے۔

سگنل 15 ایک الگ واقعہ ہے: کسی چیز نے مقامی عمل کو رکنے کا کہا اور ہینڈلر نے اسے درج کیا۔ جب دونوں سطریں اکٹھی ظاہر ہوں تو ترتیب سببی ہوتی ہے، پہلے انکار اور پھر بند ہونا۔

اسناد کو چھونے سے پہلے گفت و شنید پڑھیں

لاگ کی سطح وہاں بڑھائیں جہاں ڈیمن لکھتا ہے، پھر آؤٹ پٹ دیکھتے ہوئے دوبارہ جڑیں۔ NetworkManager ہوسٹ پر L2TP پلگ ان وہ سطح بیک اینڈ کو دیتا ہے، اور پیغامات تقسیم کے مطابق journal یا روایتی syslog فائل میں پہنچتے ہیں۔ ان میں سے کوئی بھی تبادلہ دکھائے گا: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' یا tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'۔

pluto کا نام لینے والی سطر libreswan سے آتی ہے، charon strongSwan سے، اور دونوں ایک ہی حالت کو مختلف الفاظ میں بیان کرتے ہیں۔ تلاش کے قابل شکل وہ ہے جو غائب گروپ کا نام لیتی ہے، مثلاً algorithm 'modp1024' is not supported، کیونکہ یہ مبہم ناکامی کو واضح بناتی ہے۔

modp1024 کہاں گیا

Diffie-Hellman گروپ 2 اس قدر کمزور ہے کہ کئی تقسیمیں 3.30 سے اسے libreswan میں شامل کرنا بند کر بیٹھیں۔ پھر برسوں پہلے لکھا گیا یا صرف aes128-sha1-modp1024 درج کرنے والی گیٹ وے گائیڈ سے لیا گیا پروفائل مقامی ڈیمن سے وہ چیز مانگتا ہے جو وہ بالکل نہیں کر سکتا۔ نئے NetworkManager-l2tp بلڈ اس نتیجے کو زیادہ ممکن بناتے ہیں: 1.2.16 سے وہ سیٹ کو Windows 10 اور iOS طرز کی تجاویز سے بدل دیتے ہیں اور libreswan کا پتہ چلتے ہی modp1024 چھوڑ دیتے ہیں۔ سامنے والا فریق اکثر بے قصور ہوتا ہے اور اب بھی وہی گروپ پیش کرتا ہے جو آپ نے ترتیب دیا تھا۔

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

مختلف اثرات کے ساتھ دو مرمت

سستی مرمت یہ ہے کہ الگورتھم ہاتھ سے مقرر کرنا بند کریں۔ ایڈیٹر میں دونوں تجویز خانوں کو خالی کریں اور پلگ ان کو وہ سیٹ چننے دیں جو دور والا فریق قبول کرے؛ اگر گیٹ وے جدید گروپوں کی حمایت کرتا ہے تو گفت و شنید بغیر مزید کام کے مکمل ہو جاتی ہے۔

دوسری مرمت strongSwan نصب کر کے پرانے گیٹ وے کو قابل رسائی رکھتی ہے، جس کے پیکجز زیادہ تر تقسیموں میں اب بھی گروپ 2 نافذ کرتے ہیں۔ یہ ڈیمن کی تبدیلی ہے، اس لیے اس کی قیمت ہے: ہٹانے سے پہلے جانچیں کہ ہوسٹ پر دیگر سرنگیں libreswan کنفیگریشن پر منحصر ہیں یا نہیں، اور Fedora پر NetworkManager اور strongSwan پلگ ان کے درمیان SELinux انکار کی توقع رکھیں۔ وہ انکار IKE ٹریس میں نہیں، آڈٹ لاگ میں ظاہر ہوتے ہیں، اسی لیے کامیاب تنصیب کے فوراً بعد سرنگ ٹوٹی ہوئی لگ سکتی ہے۔ کام کرنے والی ترتیب یہ ہے: پہلے dnf install strongswan، پھر rpm -e libreswan۔

مطابقت رکھنے والی تجویز سٹرنگیں، اور ان کے گرد جال

جب خانے ہاتھ سے بھرنے پڑیں تو مرحلہ 1 اور مرحلہ 2 مختلف قیمتیں لیتے ہیں۔ Meraki طرز کے سامنے والے فریق کے خلاف کام کرنے والی معلوم جوڑی مرحلہ 1 میں aes128-sha1-modp1024 اور اس کے پیچھے 3des-sha1-modp1024 پیش کرتی ہے، دونوں حیرانی کے نشان سے بند جو سیٹ کو سخت بناتا ہے، اس لیے صرف وہی تجاویز بھیجی جاتی ہیں۔

پھر مرحلہ 2 اسی سخت نشان کے ساتھ اور Diffie-Hellman لاحقے کے بغیر aes128-sha1 اور 3des-sha1 تک سکڑ جاتا ہے۔ -modp1024 رکھنے والی مرحلہ 2 کی سطر غلط خانے میں مرحلہ 1 کی قیمت ہے، اور جواب دینے والا ہر دوبارہ کوشش پر اسے مسترد کرتا ہے۔ وہ سطر دوسری پروفائل میں نقل کریں اور دوسری پروفائل بھی اسی طرح ناکام ہوتی ہے، اور اسی طرح ایک ٹائپنگ غلطی پورے بیڑے کا واقعہ بن جاتی ہے۔

دیگر خرابیاں تجویز کی بے ضابطگی نہ ہوتے ہوئے بھی وہی پاپ اپ پہنتی ہیں۔ KDE پر L2TP قسم پلگ ان نصب ہونے کے باوجود فہرست میں ہو سکتی ہے جبکہ ہر کنکشن فوراً مر جاتا ہے، کیونکہ کنکشن ایڈیٹر اور رن ٹائم معاون الگ پیکجز کے طور پر آتے ہیں۔ بغیر اسکرین والے ہوسٹ کام کرتے ڈیسک ٹاپ سے پروفائل دوبارہ استعمال کر سکتے ہیں: اسے /etc/NetworkManager/system-connections/ سے نقل کریں، موڈ 600 پر رکھیں، پھر nmcli con reload چلائیں۔ اسے nmcli con up id work-l2tp سے اوپر لائیں، کیونکہ ننگا روپ UUID مانگتا ہے، اور کوئی پرانی ifname اندراج ہٹا دیں، ورنہ باقی سب درست ہونے پر بھی مینیجر Could not find source connection کا جواب دیتا ہے۔

پہلے سے مشترکہ چابی سادہ متن کے طور پر یا 0s اور پھر base64 کے طور پر محفوظ کی جا سکتی ہے؛ دونوں شکلیں کام کرتی ہیں، لیکن قیمت گیٹ وے سے بائٹ بہ بائٹ ملنی چاہیے، ان آخری خالی جگہوں سمیت جو آپ نے اس کے ساتھ نقل کیں۔