OpenVPN auth-nocache: पुढील लॉगिनला काय होते
OpenVPN चे मेमरीतील क्रेडेन्शियल्स पुसल्याने पुढील प्रमाणीकरण बदलते. इंटरॅक्टिव्ह क्लायंट, क्रेडेन्शियल्स फाइल आणि सेवा यांना वेगळी हाताळणी आवश्यक आहे.
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 वाढवणे, जोपर्यंत प्रॉम्प्ट दुर्लक्ष करण्याइतका दुर्मिळ होत नाही. त्यामुळे सेशनचे की-रोटेशन वेळापत्रक पुन्हा लिहिले जाते आणि तीच क्रेडेन्शियल्स समस्या अधिक उशिरा, कमी अंदाज करण्यायोग्य क्षणाकडे ढकलली जाते; त्यामुळे क्रेडेन्शियल्सचा स्रोत तयार होत नाही. कोण्या कारणाने वेळापत्रकानुसार की नूतनीकरण करणारे धोरण फक्त पासवर्ड टाइप करणे टाळण्यासाठी सैल करू नये.
तुम्ही बसलेल्या सेशनऐवजी पुनःकनेक्शनची चाचणी करा, कारण जिवंत सेशन काहीही सिद्ध करत नाही. सर्व्हरच्या बाजूने सुरंग पाडा, किंवा क्लायंट सेवा पुन्हा सुरू करा, आणि कीबोर्डवर कोणी नसताना पुढील पुनर्वाटाघाटी काय करते ते पहा. ती पुन्हा जोडली गेल्यास गुपित पुरवणारी यंत्रणा सांगा; नाही तर या होस्टवर पर्यायाची खरी किंमत तुम्ही शोधली आहे. कोणताही निकाल तुम्हाला चाचणीच्या वेळी टिकलेले उत्तर नव्हे, तर व्यत्ययाच्या वेळी टिकणारे उत्तर देतो.
व्यवस्थापित फ्लीटमध्ये, तैनातीच्या मालकाला तीन गोष्टी सांगता आल्या पाहिजेत: क्रेडेन्शियल्स कुठून येतात, कुठे साठवली जातात आणि कोण त्यांचे रोटेशन करते. या उत्तरांपैकी कोणतेही होस्ट सेट करणारी व्यक्ती असल्यास, पर्याय तिथे अजून सुरक्षित नाही.