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 बढ़ाना है, जब तक प्रॉम्प्ट इतना दुर्लभ न हो जाए कि उसे नज़रअंदाज़ किया जा सके। यह सत्र की कुंजी-रोटेशन अनुसूची को फिर से लिखता है और उसी क्रेडेंशियल समस्या को बाद के, कम अनुमानित पल में धकेल देता है; यह क्रेडेंशियल का स्रोत नहीं बनाता। जो नीति किसी कारण अनुसूची के अनुसार कुंजियाँ नवीनीकृत करती है, उसे केवल पासवर्ड टाइप करने से बचने के लिए ढीला नहीं करना चाहिए।

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

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