L2TP: घातक सिग्नल 15, NO_PROPOSAL_CHOSEN और गायब modp1024

आपका कनेक्शन अटक जाता है, क्लाइंट बाहर निकल जाता है, और स्क्रीन पर आख़िरी पंक्ति death_handler: Fatal signal 15 received होती है। वह पंक्ति रुकावट की सूचना देती है, कारण की नहीं। IPsec लॉग में एक पंक्ति ऊपर लगभग हमेशा NO_PROPOSAL_CHOSEN होता है, और यह जोड़ी अदला-बदली के फ़ेज़ 2 की ओर इशारा करती है, जहाँ दोनों पक्ष एन्क्रिप्शन और हैश के विकल्पों की तुलना करते हैं और तब रुक जाते हैं जब उनमें कुछ भी साझा न हो। उस चरण में क्रेडेंशियल अभी भेजे नहीं गए होते, इसलिए पासवर्ड दोबारा लिखने से नतीजा नहीं बदल सकता।

Linux क्लाइंट पर आम तौर पर दो चीज़ें उस साझा हिस्से को ख़ाली कर देती हैं। स्थानीय डेमॉन प्रोफ़ाइल द्वारा मांगा गया Diffie-Hellman समूह अब लागू नहीं करता हो सकता है, या प्रोफ़ाइल फ़ेज़ 2 के फ़ील्ड में फ़ेज़ 1 का प्रस्ताव रख रहा हो। दोनों लॉग में सबूत छोड़ते हैं, और इनमें से कोई भी खाते की समस्या नहीं है।

ये दो संदेश असल में क्या कहते हैं

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 के रूप में संग्रहित हो सकती है; दोनों रूप काम करते हैं, लेकिन मान गेटवे से बाइट-दर-बाइट मेल खाना चाहिए, जिसमें वे अंतिम खाली जगहें भी शामिल हैं जो आपने उसके साथ कॉपी कीं।