क्या 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 संस्करण पर दो मशीनें अलग व्यवहार कर सकती हैं क्योंकि एक के पास वितरण पैकेज है और दूसरे के पास बैकपोर्ट, और बग रिपोर्ट में दोनों पर डेमॉन संस्करण एक जैसा दिखता है। यह निष्कर्ष निकालने से पहले कि अपग्रेड ने कोई प्रासंगिक चीज़ नहीं बदली, प्लगइन संस्करण जाँचें, केवल डेमॉन संस्करण नहीं।

उसी क्षेत्र में एक छोटा जाल है। दोनों डेमॉन अंडाकार वक्र 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 समूह और एक प्रमाणीकरण विधि से बनाता है। फिर तेज़ मोड वह ESP सहयोग बनाता है जो L2TP ले जाएगा। सर्वर पहले को स्वीकार करने और दूसरे को अस्वीकार करने के लिए स्वतंत्र है, इसलिए आधा-सही प्रोफ़ाइल आपकी अपेक्षा से देर से विफल होता है और किसी दूसरी बग जैसा दिखता है।

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

विस्मयादिबोधक चिह्न strongSwan सिंटैक्स में कठोर प्रविष्टि है: केवल यही एक संयोजन दें, और कुछ नहीं। इसके बिना प्रविष्टि फ़ॉलबैक सूची में शामिल हो जाती है, जो तब अच्छा है जब सामने वाला आधुनिक हो और तब हानिकारक है जब वह एक ही कठोर-कोडित नीति वाला उपकरण हो। ऊपर के जोड़े को रूप का उदाहरण मानें, आज आप जो कुछ भी बना रहे हैं उसके लिए सिफ़ारिश नहीं।

एक फ़ील्ड बदलें, फिर परीक्षण दोहराएँ

वर्तमान प्लगइन पर, सबसे तेज़ पहला परीक्षण दोनों प्रस्ताव फ़ील्ड पूरी तरह खाली करके फिर से कनेक्ट करना है, क्योंकि दिया गया डिफ़ॉल्ट सेट पहले से ही सामान्य Windows और Apple संयोजन रखता है। पुराने प्लगइन पर, उन्हें खाली करने से नियंत्रण ऐसे डेमॉन के पास लौट जाता है जिसने शायद वह एल्गोरिदम छोड़ दिया हो जिस पर आपका सर्वर ज़ोर देता है, और विफलता और बुरी हो जाती है।

यदि खाली करने से मदद न मिले, तो वह कठोर जोड़ी सेट करें जिसे आपका सर्वर प्रलेखित करता है, एक बार में एक चरण। चरण 1 बदलें, फिर से कनेक्ट करें, और चरण 2 को छूने से पहले लॉग पढ़ें। जब कोई संयोजन अंततः काम करे, तो उसे सर्वर मॉडल और प्लगइन संस्करण के बगल में लिख लें, क्योंकि डिफ़ॉल्ट फिर बदलेंगे और वही टिप्पणी अगले अपग्रेड को पाँच मिनट की जाँच बनाती है।