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 चुकीच्या खात्यासह तरीही अयशस्वी होते, आणि खाते बदलल्याने डीमनने कधीही बरोबर न वाचलेली की दुरुस्त होणार नाही।

तिकीट बंद करताना चारही गोष्टी लिहा: प्लगइन आवृत्ती, वापरातील सीक्रेट फाइल, की पुन्हा टाइप केली की पेस्ट केली, आणि त्रुटीत नमूद केलेला स्तर। मग हा मार्ग पुढे पुन्हा करणारा कोणीही थेट कार्यरत आणि अयशस्वी मशीनमधील फरकाकडे जाऊ शकतो।