Ubuntu अपग्रेडले L2TP/IPsec बिगार्यो? IKEv1 प्रस्तावहरू तुलना गर्नुहोस्

जडान बिहीबार काम गरिरहेको थियो, अपग्रेड शुक्रबार चल्यो, र सोमबार ग्राहक “connecting” मा घुमिरहन्छ र हार मान्छ। उही ल्यापटप, उही सर्भर, उही खाता, उही पहिले साझा गरिएको कुञ्जी। प्रोफाइलमा केही पनि सम्पादन गरिएको थिएन, त्यसैले स्पष्ट शंकास्पद, पासवर्ड र फायरवाल, तपाईंको समय बर्बाद गर्छन्।

परिवर्तन भएको कुरा तपाईंको मेसिनले प्रस्ताव गर्न तयार रहेका रूपान्तरणहरूको सूची हो। Ubuntu मा प्रयोग हुने दुवै IPsec स्ट्याक, strongSwan र Libreswan, अब सुरक्षित नमानिने एल्गोरिदमहरू हटाउँछन्, र तिनीहरूको अगाडि रहेको NetworkManager प्लगइनको आफ्नै सूची छ, जुन फरक समयतालिकामा चल्छ। 3DES, SHA1 र 1024 बिटको Diffie-Hellman समूहमा पिन गरिएको सर्भरले अन्ततः आफूले स्वीकार गर्ने केही पनि सुन्न सक्दैन।

अपग्रेडले वास्तवमा के परिवर्तन गर्यो

IKEv1 प्रस्तावलाई दुई तहले पोषण गर्छन्। डेमनले कम्पाइल गरिएको पूर्वनिर्धारित प्रस्ताव सेट दिन्छ, र L2TP प्लगइनले या त त्यसमा भर पर्छ या आफ्नै सूची दिन्छ। NetworkManager-l2tp 1.2.16 अघि प्लगइन त्यसमा भर पर्थ्यो, त्यसैले तपाईंको प्रस्ताव स्थापित डेमनले उचित ठानेको कुरा थियो। 1.2.16 देखि प्लगइनले Windows र Apple ग्राहकहरूमा आधारित अभिलेखित सूची पठाउँछ, र त्यो सूची पुरानो पूर्वनिर्धारितभन्दा फराकिलो छ तर अब लाइनको अगाडिको हरेक पुरानो संयोजन समेट्दैन।

यो विभाजनले मानिसहरूलाई अलमल्याउने असफलताको ढाँचा व्याख्या गर्छ: एउटै Ubuntu संस्करणका दुई मेसिन फरक व्यवहार गर्न सक्छन् किनकि एउटामा वितरण प्याकेज छ र अर्कोमा backport, र बग रिपोर्टमा दुवैको डेमन संस्करण एउटै देखिन्छ। अपग्रेडले कुनै पनि सान्दर्भिक कुरा परिवर्तन गरेन भन्ने निष्कर्षमा पुग्नुअघि प्लगइन संस्करण जाँच्नुहोस्, डेमन संस्करण मात्र होइन।

त्यही क्षेत्रमा सानो जाल छ। दुवै डेमनले दीर्घवृत्तीय वक्र Diffie-Hellman समूहहरू फरक तरिकाले लेख्छन्, एउटाले ecp384 लेख्छ र अर्कोले ecp_384। गलत हिज्जे Advanced संवादमा टाँस्नुहोस् र डेमनले त्यो सेटिङलाई विश्लेषण गर्न नसकिने भनी अस्वीकार गर्छ, जुन लगमा कन्फिगरेसनको टाइपिङ त्रुटिको सट्टा वार्ता समस्याको रूपमा देखिन्छ।

केही परिवर्तन गर्नुअघि असफलता पढ्नुहोस्

तपाईं कुन ब्याकएन्ड चलाइरहनुभएको छ त्यसबाट सुरु गर्नुहोस्, किनकि उत्तरले सिन्ट्याक्स र लगको स्थान दुवै निर्धारण गर्छ।

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

त्यसपछि आदानप्रदान आफै पढ्नुहोस्। strongSwan मा डेमनले हालको संस्करणमा journal मा र पुरानोमा /var/log/syslog मा लेख्छ, र रोचक भाग अन्तिम लाइन होइन, उसले पठाउने प्रस्ताव हो। तपाईं मिल्ने प्रस्ताव छैन भन्ने शब्दावली खोज्दै हुनुहुन्छ, जुन एल्गोरिदमको समस्या हो; प्रमाणीकरण असफलता, जसले कुञ्जी वा खातातर्फ संकेत गर्छ; वा साधारण टाइमआउट, जसले पहुँचतर्फ संकेत गर्छ।

यी तीन नतिजालाई धेरै पटक एउटै लक्षण मानिन्छ। खाली डेमन लगसहितको टाइमआउट भन्नाले प्याकेटहरू आइपुग्दैनन् भन्ने बुझिन्छ। प्रस्ताव अस्वीकृत हुनु भन्नाले ती आए र अस्वीकार गरिए भन्ने बुझिन्छ। तपाईंको लग शान्त छ भने एक प्रयासका लागि प्लगइनको डिबग स्तर बढाउनुहोस् र पछि घटाउनुहोस्, किनकि विस्तृत आउटपुटले journal छिटो भर्छ।

चरण 1 र चरण 2 अलग दाउ हुन्

IKEv1 दुई पटक वार्ता गर्छ। मुख्य मोडले IKE सुरक्षा सहयोग एन्क्रिप्शन एल्गोरिदम, अखण्डता एल्गोरिदम, Diffie-Hellman समूह र प्रमाणीकरण विधिबाट बनाउँछ। त्यसपछि द्रुत मोडले L2TP बोक्ने ESP सहयोग बनाउँछ। सर्भर पहिलो स्वीकार गर्न र दोस्रो अस्वीकार गर्न स्वतन्त्र छ, त्यसैले आधा सही प्रोफाइल तपाईंले अपेक्षा गरेभन्दा ढिलो असफल हुन्छ र अर्को बगजस्तो देखिन्छ।

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

विस्मय चिन्ह strongSwan सिन्ट्याक्समा कडा प्रविष्टि हो: यही एउटा संयोजन प्रस्ताव गर्नुहोस्, अरू केही होइन। त्यो बिना प्रविष्टि फलब्याक सूचीमा जोडिन्छ, जुन सामनेवाला आधुनिक हुँदा राम्रो हुन्छ र एउटै कडा कोड गरिएको नीति भएको उपकरण हुँदा हानिकारक हुन्छ। माथिको जोडीलाई रूपको उदाहरण मान्नुहोस्, आज तपाईं बनाइरहनुभएको कुनै पनि कुराका लागि सिफारिस होइन।

एउटा फिल्ड परिवर्तन गर्नुहोस्, त्यसपछि परीक्षण दोहोर्याउनुहोस्

हालको प्लगइनमा सबैभन्दा छिटो पहिलो परीक्षण दुवै प्रस्ताव फिल्ड पूरै खाली गरी फेरि जडान गर्नु हो, किनकि दिइएको पूर्वनिर्धारित सूचीमा सामान्य Windows र Apple संयोजनहरू पहिले नै छन्। पुरानो प्लगइनमा ती खाली गर्दा नियन्त्रण तपाईंको सर्भरले जोड दिने एल्गोरिदम छाडेको हुनसक्ने डेमनकहाँ फर्किन्छ, र असफलता अझ नराम्रो हुन्छ।

खाली गर्दा सहयोग भएन भने तपाईंको सर्भरले अभिलेख गरेको कडा जोडी एक पटकमा एक चरण सेट गर्नुहोस्। चरण 1 परिवर्तन गर्नुहोस्, फेरि जडान गर्नुहोस्, र चरण 2 छुनुअघि लग पढ्नुहोस्। संयोजन अन्ततः काम गर्‍यो भने त्यसलाई सर्भर मोडेल र प्लगइन संस्करणको छेउमा लेख्नुहोस्, किनकि पूर्वनिर्धारित मान फेरि सर्नेछन् र त्यही टिप्पणीले अर्को अपग्रेडलाई पाँच मिनेटको जाँचमा बदल्छ।