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 को रूपमा भण्डारण गर्न सकिन्छ; दुवै रूप काम गर्छन्, तर मान गेटवेसँग बाइट बाइट मिल्नुपर्छ, त्यससँगै प्रतिलिपि गरिएका अन्त्यका खाली ठाउँहरू सहित।