auth-nocache र प्रमाण-पत्र फाइल: सहयोग गर्छ कि हानि?

OpenVPN सुरु हुँदा auth-nocache सुझाव दिने चेतावनी छाप्छ, र लोभ्याउने प्रतिक्रिया भनेको विकल्प थपेर लाइन हराएको हेर्नु हो। त्यो सल्लाहले अन्तरक्रियात्मक लगइन मान्छ। प्रयोगकर्ता नाम र पासवर्ड फाइलमा बस्न थालेपछि तुलना बदलिन्छ: विकल्पले टिकाउ प्रतिको रक्षा गर्न छोड्छ, र विशेषाधिकार छोड्ने क्लाइन्टमा यसले पछि पुनः वार्तालाप बिगार्न सक्छ। प्रोफाइल सम्पादन गर्नुअघि दुई भण्डारण मोडेल अलग राख्नु उपयुक्त हुन्छ।

प्रमाण-पत्र अनुरोधको जवाफ दिने दुई तरिका

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

दोस्रो मोडेल फाइलतर्फ संकेत गर्ने auth-user-pass हो, जहाँ फाइल नै भण्डार हो र मान आवश्यक पर्दा क्लाइन्टले त्यो पढ्छ। यहाँ महत्त्वपूर्ण जोखिम प्रक्रियाको स्मृति होइन, त्यो फाइलका अनुमति र स्वामित्व हुन्। सुरुको चेतावनी कन्फिगका निर्देशनबाट आउँछ, तपाईंले पासवर्ड कसरी दिनुहुन्छ भन्ने जाँचबाट होइन, त्यसैले यो दुवै मोडेलमा देखिन्छ र कुनैतर्फ संकेत गर्दैन।

यो तुलनाको बाँकी भाग त्यही विभाजनबाट आउँछ: एउटा मोडेलका लागि स्मृति व्यवस्थापन, अर्कोका लागि फाइल व्यवस्थापन र प्रक्रिया पहिचान।

auth-nocache ले वास्तवमा के हटाउँछ

अन्तरक्रियात्मक लगइनमा, --auth-nocache प्रयोग भएपछि भण्डारित प्रति स्मृतिबाट हटाउँछ। लागत प्रत्येक पुनः वार्तालाप अन्तरालमा नयाँ अनुरोध हो, किनकि अर्को चरणले हटाइएको कुरा पुनः प्रयोग गर्न सक्दैन।

फाइलमा आधारित लगइनमा क्लाइन्टले फाइल फेरि पढ्न सक्छ, त्यसैले हटाउने काम धेरैजसो अदृश्य हुन्छ। यो एउटै ठाउँमा देखिन्छ जहाँ मानिसहरूले अपेक्षा गर्दैनन्: डेमनले विशेषाधिकार छोडेपछि, यदि प्रमाण-पत्र फाइल अहिले जुन खातामुनि यो चलिरहेको छ त्यसले पढ्न नसक्ने भए।

त्यो साटासाट बुझेको हुनाले विकल्प थप्नुहोस्, चेतावनी देखियो भनेर होइन। लग शान्त पार्न थपिएको विकल्प त्यस्तो विकल्प हो जसको प्रभाव कसैले नापेन।

फाइलमा आधारित बाटो कहाँ टुट्छ

टनेल उपकरण खोल्न root का रूपमा सुरु भएर पछि user र group मा जाने क्लाइन्टले प्रमाण-पत्र फाइल दुई पटक पढ्छ: एक पटक परिवर्तनअघि, एक पटक त्यसपछिको पुनः वार्तालापमा। फाइल मोड 600 मा भए र root को स्वामित्वमा भए, दोस्रो पढाइ असफल हुन्छ, र असफलता एक घण्टापछि सर्भर समस्याजस्तो देखिने प्रमाणीकरण त्रुटिका रूपमा देखिन्छ। पुनः वार्तालाप अन्तराल वरपर क्लाइन्ट लग जाँच्नुहोस्, त्यसपछि खाता र फाइल सँगै जाँच्नुहोस्।

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

दुवै लाइन महत्त्वपूर्ण छन्। पहिलोले फाइल कसले पढ्न सक्छ भन्छ, दोस्रोले चलिरहेको डेमन वास्तवमा को हो भन्छ, र तिनीहरूबीचको भिन्नताले पासवर्ड जतिपटक पुनः लेखे पनि नसच्याइने असफलता व्याख्या गर्छ।

व्यावहारिक सुधार चम्किला छैनन्: फाइललाई डेमनको खाताले पढ्न सक्ने डाइरेक्टरी र मालिककहाँ सार्नुहोस्, वा विशेषाधिकारप्राप्त पढाइ राखेर तपाईंको क्लाइन्ट एक पटक मात्र पढ्छ भनी पुष्टि गर्नुहोस्। फाइललाई सबैले पढ्न सक्ने बनाएर यो समाधान नगर्नुहोस्।

विकल्प साँच्चै चाहिने अवस्था

एक-पटक कोड बोकेको लगइनले auth-nocache अर्कै कारणले चाहन्छ। एक-पटक कोड पहिलो प्रमाणीकरणमा खर्चिन्छ, त्यसैले क्यास गरिएको प्रति अर्को पुनः वार्तालापमा बेकार हुन्छ र पुरानो मान फेरि बजाइन सक्छ।

यो प्रमाण-पत्रको प्रकारको प्रश्न हो, यो कहाँ भण्डारण गरिन्छ भन्ने होइन। सुरक्षित फाइलमा रहेको स्थिर पासवर्डको उल्टो प्रोफाइल हुन्छ: त्यो प्रत्येक पुनः वार्तालापमा पढ्न सकिने हुनुपर्छ, र आवश्यक सुरक्षा फाइलमा छ।

यी दुई कारणलाई प्रोफाइल टिप्पणीमा अलग राख्नुहोस्, नत्र अर्को प्रशासकले विकल्प आफूले छान्ने कारणले छ भनी ठान्नेछ।

एउटा निर्णयमा तुलना

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

कुनै पनि मोडेलले भण्डारित पासवर्डलाई आफैँ सुरक्षित बनाउँदैन, र कुनैले पनि सुरुको चेतावनीलाई अर्थपूर्ण बनाउँदैन।

यदि चेतावनी नै प्रोफाइल खोल्ने एकमात्र कारण हो भने, अस्पष्ट विकल्पको सट्टा निर्णय लेख्नुहोस्: प्रमाण-पत्र डेमनको खाताले पढ्न सक्ने फाइलबाट आउँछन्, पुनः वार्तालाप सफल हुँदै गरेको देखिएको छ, र अन्तराल बदल्नुअघि OpenVPN 2.6 पुस्तिकाको पुनः वार्तालापसम्बन्धी खण्ड पढिएको छ। त्यो टिप्पणी कुनै एउटै फ्ल्यागभन्दा लामो टिक्छ।