तपाईं प्रशासकको सन्देशबाट पूर्व-साझा कुञ्जी 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 गलत खातासँग पनि असफल हुन्छ, र खाता बदल्दा डेमनले कहिल्यै राम्ररी नपढेको कुञ्जी सुधारिँदैन।

टिकट बन्द गर्दा चारै लेख्नुहोस्: प्लगइन संस्करण, प्रयोगमा रहेको गोप्य फाइल, कुञ्जी फेरि टाइप गरियो कि टाँसियो, र त्रुटिमा उल्लेख गरिएको तह। त्यसपछि यो बाटो पछि दोहोर्याउने जो कोही सिधै काम गर्ने र असफल हुने मेसिनबीचको फरकमा जान सक्छ।

सम्बन्धित लेखहरू