L2TP/IPsec PSK अस्वीकृत: पहले संवाद, फिर फ़ाइलें देखें

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

नीचे का रास्ता कुंजी को फ़ील्ड से फ़ाइल तक ले जाता है, और यही क्रम बताता है कि वह कहाँ खोई। इसे उस मशीन पर करें जो विफल होती है, न कि उस पर जो काम करती है, क्योंकि उन दो मशीनों का अंतर आम तौर पर फ़ाइलों का लेआउट होता है, कुंजी नहीं।

संवाद से शुरू करें, पर फ़ील्ड पर भरोसा न करें

कनेक्शन का IPsec टैब खोलें और कुंजी को पेस्ट करने के बजाय फिर से टाइप करें। चैट संदेश, PDF या पासवर्ड मैनेजर से कॉपी की गई कुंजी के अंत में ऐसा लाइन ब्रेक आ सकता है जो फ़ील्ड नहीं दिखाता, और दिखने वाले अक्षर फिर भी सही लगते हैं।

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

अगर कुंजी ऐसी टिकट प्रणाली से आई है जो लंबी पंक्तियाँ मोड़ती है, तो उसे ऐसे चैनल से माँगें जो न मोड़ता हो। दो स्ट्रिंग को बगल-बगल देखने के बजाय लंबाई एडमिनिस्ट्रेटर से तुलना करें; मोड़ के बिंदु पर खोया अक्षर आनुपातिक फ़ॉन्ट में अदृश्य होता है।

/etc/ipsec.d में कुंजी का पीछा करें

प्लगइन PSK को IPsec डेमन को कमांड लाइन पर आर्ग्युमेंट के रूप में कभी नहीं देता। इसके बजाय वह मान को सीक्रेट फ़ाइल में रखता है और व्यवस्था करता है कि डेमन उस फ़ाइल को शामिल करे, ज़रूरत होने पर /etc/ipsec.secrets में include पंक्ति जोड़कर। संवाद जो रखता है वह उस बनी फ़ाइल का इनपुट है, इस्तेमाल में लिया जा रहा मान नहीं।

कुछ भी बदलने से पहले सूची बनाएँ कि क्या मौजूद है:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

प्लगइन के पुराने संस्करण प्रति कनेक्शन एक फ़ाइल लिखते थे, जिसका नाम कनेक्शन के UUID पर होता था, उदाहरण के लिए /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets। ऐपलेट में प्रोफ़ाइल मिटाने से वह फ़ाइल भरोसेमंद तरीके से नहीं मिटती। अगर पिछले सर्वर की पुरानी फ़ाइल अब भी डिस्क पर है और अब भी शामिल है, तो डेमन ऐसा सीक्रेट चुन सकता है जो ऐसे प्रोफ़ाइल का है जिसे आप अब इस्तेमाल नहीं करते, और दिखाई देने वाला फ़ील्ड सही होने पर भी कनेक्शन विफल हो जाता है।

समझें कि 1.2.12 बदलाव ने अपग्रेड के साथ क्या किया

प्लगइन संस्करण 1.2.12 ने प्रति-कनेक्शन सीक्रेट फ़ाइलों को एक साझा फ़ाइल से बदल दिया, /etc/ipsec.d/ipsec.nm-l2tp.secrets। अपग्रेड पुरानी UUID-आधारित फ़ाइलों को साफ़ नहीं करता, और मौजूदा include /etc/ipsec.d/*.secrets पंक्ति उन्हें अब भी शामिल करती है। संस्करण 1.2.16 डिफ़ॉल्ट प्रस्तावों का प्रबंधन बदला, सीक्रेट का लेआउट नहीं।

यह इतिहास बताता है कि एक जैसे दिखने वाले प्रोफ़ाइल वाली दो मशीनें अलग क्यों बर्ताव करती हैं। कुंजी एक जैसी है; डेमन जो फ़ाइलें शामिल करता है वह समूह एक जैसा नहीं है। जब आप अनाथ फ़ाइल हटाएँ, तो उसे मिटाने के बजाय किनारे कर दें, कनेक्शन की पुष्टि करें, और काम करने वाली स्थिति दर्ज होने के बाद उसे मिटाएँ। नाम बदलने से पुराना मान वापस पाने योग्य रहता है, अगर गड़बड़ी कहीं और निकले।

उन अक्षरों को अलग करें जिन्हें संग्रह प्रारूप नहीं रख सकता

साझा सीक्रेट स्ट्रिंग के लिए strongSwan का दस्तावेज़ कहता है कि मान में नई पंक्ति या दोहरा उद्धरण चिह्न नहीं हो सकता। किसी दस्तावेज़ से पेस्ट की गई कुंजी सामान्य संवाद में बिना किसी दृश्य अंतर के दोनों में से कोई भी ले जा सकती है।

1.2.12 से संग्रहीत मान सादा पाठ नहीं है। प्लगइन PSK को फ़ाइल तक पहुँचने से पहले base64 में एनकोड करता है, और रिलीज़ नोट्स उसी एनकोडिंग को कारण बताते हैं कि दोहरा उद्धरण चिह्न अब कुंजी में स्वीकार्य है। इसलिए फ़ील्ड में टाइप किया गया उद्धरण चिह्न प्रस्तुत करने योग्य है; हर नियंत्रण अक्षर के लिए यह सच नहीं है।

लंबाई दूसरी बाधा है। L2TP/IPsec सॉफ़्टवेयर में कोई सार्वभौमिक न्यूनतम लागू नहीं होता: कुछ क्लाइंट बीस अक्षरों से छोटी कुंजियाँ स्वीकार करते हैं और कुछ गेटवे न्यूनतम थोपते हैं। अगर छोटी कुंजी अस्वीकार हो, तो नियम सर्वर नीति या उस क्लाइंट के सत्यापन का है, और स्थानीय रूप से कुछ बढ़ाने से वह नहीं बदलेगा।

पढ़ें कि प्रमाणीकरण की कौन-सी परत विफल हुई

पहले ipsec --version चलाएँ, क्योंकि strongSwan और Libreswan अलग फ़ाइल नाम और सिंटैक्स इस्तेमाल करते हैं, और एक के लिए दी गई सलाह दूसरे को नुकसान पहुँचा सकती है। फिर क्लाइंट के संदेश या डेमन लॉग से विफलता का चरण पढ़ें: प्री-शेयर्ड कुंजी की शिकायत अस्वीकृत उपयोगकर्ता नाम और पासवर्ड से अलग घटना है।

PSK टनल के सिरों का प्रमाणन करती है। उपयोगकर्ता नाम और पासवर्ड L2TP के भीतर के व्यक्ति का प्रमाणन करते हैं, और IPsec एसोसिएशन उठने के बाद PPP उन्हें संभालता है। सही PSK के साथ ग़लत खाता भी विफल होता है, और खाता बदलने से ऐसी कुंजी ठीक नहीं होगी जिसे डेमन ने कभी ठीक से नहीं पढ़ा।

टिकट बंद करते समय चारों बातें लिखें: प्लगइन संस्करण, इस्तेमाल में ली गई सीक्रेट फ़ाइल, कुंजी फिर से टाइप हुई या पेस्ट हुई, और त्रुटि में बताई गई परत। तब आगे यह रास्ता दोहराने वाला कोई भी सीधे काम करने वाली और विफल मशीन के अंतर पर जा सकेगा।