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

तुमचे कनेक्शन अडकते, क्लायंट बाहेर पडतो आणि स्क्रीनवरील शेवटची ओळ death_handler: Fatal signal 15 received असते. ती ओळ खंड पडल्याचे सांगते, कारण नाही. IPsec लॉगमध्ये एक ओळ वर जवळपास नेहमी NO_PROPOSAL_CHOSEN असते, आणि ही जोडी देवाणघेवाणीच्या फेज 2 कडे निर्देश करते, जिथे दोन्ही बाजू एन्क्रिप्शन आणि हॅशच्या निवडींची तुलना करतात आणि काहीही सामायिक नसल्यास थांबतात. त्या टप्प्यावर क्रेडेन्शियल्स अजून पाठवलेली नसतात, त्यामुळे पासवर्ड पुन्हा टाइप केल्याने निकाल बदलणार नाही.

Linux क्लायंटवर सहसा दोन गोष्टी तो छेद रिकामा करतात. स्थानिक डेमॉन प्रोफाइलने मागितलेला 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 म्हणून साठवता येते; दोन्ही स्वरूपे चालतात, पण मूल्य गेटवेशी बाइट बाइट जुळले पाहिजे, त्यासोबत कॉपी केलेल्या शेवटच्या जागांसह.