OpenVPN auth-nocache: अर्को लगइनमा के हुन्छ

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

प्रमाणको दोस्रो सेट कहाँबाट आउनुपर्छ

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

त्यसैले त्यो क्षणमा गोप्य कुरा कहाँबाट आउन सक्छ त्यसका हरेक ठाउँ सूचीबद्ध गर्नुहोस्, र तीमध्ये कुन होस्टमा छन् भन्नेमा इमानदार हुनुहोस्। टर्मिनलमा बसेको व्यक्ति, auth-user-pass वा askpass ले पढ्न सक्ने फाइल, वा सर्भरले दिने सत्र टोकन — यी तीन यहाँ महत्त्वपूर्ण छन्। यीमध्ये कुनै पनि उपलब्ध नभए, पुनर्वार्ता परिवर्तनको एक घण्टापछि असफल हुन्छ, तपाईंले त्यो गरेको क्षणमा होइन।

तीन स्वरूप, तीन असफलताका बिन्दु

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

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

निर्देशन वा फ्ल्याग: एउटा छान्नुहोस् र कुन प्रयोग गर्नुभयो जान्नुहोस्

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

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

कुन कलाकृतिले यो सेटिङ राख्छ निर्णय गर्नुहोस्, त्यहीँ मात्र बदल्नुहोस्, अन्त कतै होइन। ल्यापटपमा सम्पादित प्रोफाइल र फ्ल्यागले त्यसलाई अगाडि बढ्ने systemd unit नै रिबुटपछि विरोधाभासी व्यवहार ल्याउने जोडी हो।

प्रमाण फाइलले गोप्य कुरा मेटाउनुको सट्टा सार्छ

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

फाइललाई डिमन चलाउने खाताको स्वामित्वमा राख्नुहोस्, अरू कसैले पढ्न नसक्ने गरी, र होस्ट छोड्ने ब्याकअपबाहिर राख्नुहोस्। OpenVPN को सर्भर-साइड auth-gen-token विकल्पले सफल लगइनपछि क्लाइन्टलाई सत्र टोकन दिन्छ, जुन खाताको पासवर्डभन्दा वरपर छोड्न सानो कुरा हो। जसरी भए पनि रोटेसनको कदम फाइलको छेउमा लेख्नुहोस्, किनकि फाइल सामान्यतया त्यो बनाउने व्यक्तिभन्दा लामो बाँच्छ।

पुनर्वार्ता लम्ब्याउँदा लागत सर्छ, हट्दैन

अर्को सुझाव reneg-sec बढाउनु हो, जबसम्म प्रम्प्ट बेवास्ता गर्न सकिने गरी दुर्लभ हुँदैन। त्यसले सत्रको कुञ्जी-रोटेसन तालिका पुनः लेख्छ र त्यही प्रमाण समस्यालाई अझ ढिलो, कम अनुमान गर्न सकिने क्षणतर्फ धकेल्छ; यसले प्रमाणको स्रोत बनाउँदैन। कुनै कारणले तालिकाअनुसार कुञ्जी नवीकरण गर्ने नीति केवल पासवर्ड टाइप गर्नबाट बच्नका लागि खुकुलो पार्नु हुँदैन।

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

व्यवस्थित फ्लीटमा परिनियोजनको मालिकले तीन कुरा भन्न सक्नुपर्छ: प्रमाण कहाँबाट आउँछ, कहाँ राखिन्छ, र कसले रोटेट गर्छ। यी जवाफमध्ये कुनै पनि होस्ट सेटअप गर्ने व्यक्ति भए, विकल्प त्यहाँ अझै सुरक्षित छैन।