OpenVPN auth-user-pass: फाइल, stdin की प्रॉम्प्ट? कसे निवडावे

कोणता क्रेडेन्शियल स्रोत वापरायचा हे तीन गोष्टी ठरवतात: कन्सोलवर एखादी व्यक्ती बसलेली आहे का, रहस्य डिस्कवर राहू शकते का, आणि दुसऱ्या प्रक्रियेने प्रॉम्प्टला उत्तर द्यायचे आहे का. चुकीची निवड केल्यास पासवर्ड पूर्णपणे वैध असतानाही क्लायंट stdin समस्या नोंदवतो, आणि यामुळे बहुतेक लोक विनाकारण सर्व्हरकडे जातात. आधी मार्ग निवडा; कोणत्या मार्गाने त्या तयार केल्या हे कळल्यावरच त्रुटी संदेशांचा अर्थ उमजतो.

हे ठरवणाऱ्या तीन अटी

कन्सोल प्रॉम्प्ट हा एकमेव मार्ग आहे ज्याला माणसाची गरज असते, त्यामुळे systemd युनिट किंवा कंटेनरमध्ये शांतपणे अपयशी होणारा तोच एकमेव मार्ग आहे. जर एखादी व्यक्ती क्लायंट सुरू करून पासवर्ड टाइप करते, तर कोणतीही फाइल सहभागी होत नाही आणि संवेदनशील काहीही डिस्कवर जात नाही. जर क्लायंट बूटच्या वेळी सुरू होत असेल, तर तोच प्रॉम्प्ट अडकून पडतो, आणि कालबाह्यता सामान्यतः क्रेडेन्शियल त्रुटीऐवजी सामान्य कनेक्शन अपयश म्हणून दिसते.

प्रक्रिया देखरेखीशिवाय सुरू होते आणि नियंत्रित परवानगी संचाखाली रहस्य डिस्कवर राहू शकते तेव्हा क्रेडेन्शियल फाइल हे योग्य उत्तर आहे. जेव्हा रहस्य अजिबात लिहू नये असे असते - फक्त तिजोरी धोरण, अल्पकालीन टोकन - तेव्हा क्लायंट उघडू शकणारा स्ट्रीम आवश्यक असतो, ज्याचा प्रत्यक्ष अर्थ प्रक्रिया बदली किंवा फाइल डिस्क्रिप्टरमध्ये लिहिणारा सहायक असतो. व्यवस्थापन इंटरफेस चौथी परिस्थिती हाताळतो: टनेलचे जीवनचक्र आधीच व्यवस्थापित करणारा आणि सॉकेटद्वारे प्रश्नांना उत्तर देऊ शकणारा नियंत्रक.

• कन्सोलवर माणूस, ऑटोमेशन नाही: परस्परसंवादी प्रॉम्प्ट.
• देखरेखीशिवाय सुरुवात, रहस्य साठवता येते: मोड 0600 क्रेडेन्शियल फाइल.
• देखरेखीशिवाय सुरुवात, रहस्य साठवता येत नाही: प्रक्रिया बदली किंवा रहस्य एजंट लिहिणारा fd.
• क्लायंट दुसऱ्या प्रक्रियेच्या मालकीचा आहे: व्यवस्थापन इंटरफेस.

दोन उत्तरे जुळत असतील तर रहस्य argv आणि shell इतिहासाबाहेर ठेवणारे निवडा. प्रोग्राम आर्ग्युमेंट म्हणून दिलेला पासवर्ड प्रक्रिया यादीद्वारे प्रत्येक स्थानिक वापरकर्ता वाचू शकतो, आणि हे उघड होणे परत करणे कठीण आहे.

प्रत्येक इनपुट मार्ग प्रत्यक्षात काय करतो

--auth-user-pass एकटाच कन्सोलवर वापरकर्तानाव आणि पासवर्ड मागतो. फाइलचे नाव दिल्यास क्लायंट पहिली ओळ वापरकर्तानाव म्हणून आणि दुसरी ओळ पासवर्ड म्हणून घेतो; कोणतेही अवतरण, टिप्पण्या किंवा की-मूल्य सिंटॅक्सला समर्थन नाही. हा संपूर्ण फॉरमॅट आहे, त्यामुळे INI फाइलच्या अपेक्षेने संपादित करणारा कोणीही ती तोडतो. इनलाइन <auth-user-pass> ब्लॉक प्रोफाइलमध्ये त्याच दोन ओळी ठेवतो, ज्यामुळे प्रोफाइल स्वतःच रहस्य बनते आणि खाजगी कीप्रमाणे त्याच वर्गात येते.

उर्वरित दोन मार्ग स्ट्रीम आणि सॉकेट आहेत. OpenVPN ला फक्त वाचनीय फाइल डिस्क्रिप्टर लागतो, त्यामुळे ते प्रक्रिया बदली, पाइप-आधारित /dev/fd नोंद किंवा प्रत्यक्षात FIFO असलेले फाइल नाव स्वीकारते. व्यवस्थापन इंटरफेस स्वरूपाने वेगळा आहे: क्लायंट स्वतः वाचण्याऐवजी देखरेख करणाऱ्या प्रक्रियेला मूल्ये विचारतो. पुन्हा जोडणीच्या वेळी हा फरक महत्त्वाचा आहे: क्रेडेन्शियल फाइल, रहस्य सहाय्यक पुन्हा लिहू शकणारा FIFO, आणि व्यवस्थापन इंटरफेस माणसाशिवाय पुन्हा पुरवू शकतात; प्रक्रिया बदली करू शकत नाही, कारण डिस्क्रिप्टर पहिल्या वाचनातच संपतो.

फाइल नेमकी दोन ओळींची असावी

तुटलेल्या क्रेडेन्शियल फाइलींपैकी बहुतेक दोन अपयश पद्धतींमध्ये बसतात. Windows संपादक CRLF शेवट ठेवतो, कॅरेज रिटर्न पासवर्डचा भाग बनतो, आणि सर्व्हर स्क्रीनवर बरोबर दिसणारे मूल्य नाकारतो. रिकामी दुसरी ओळ - पासवर्ड असावा तिथे रिकामी ओळ - क्लायंटला रिकाम्या पासवर्डसह ठेवते, जे सर्व्हर नाकारतो, जरी स्क्रीनवरील मूल्य बरोबर दिसत असले तरी. पासवर्डनंतरची जादा नवीन ओळ निरुपद्रवी आहे. फाइल संपादकातून नाही तर shellमधून लिहा आणि बाइट तपासा:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

मार्ग हा मजकुराइतकाच महत्त्वाचा आहे. सापेक्ष मार्ग प्रक्रियेच्या कार्यरत निर्देशिकेच्या संदर्भात सोडवला जातो, जी सेवेसाठी तुम्ही चाचणी केलेली निर्देशिका असणे दुर्मिळ आहे. निरपेक्ष मार्ग वापरा, फाइल क्लायंट चालवणाऱ्या खात्याच्या मालकीची करा, आणि गट व इतर वाचू नयेत म्हणून मोड 0600 ठेवा. OpenVPN 2.6 पुस्तिका निर्देशाचे स्वीकारले जाणारे प्रकार सूचीबद्ध करते; तिसरा शोधण्यापूर्वी ती तपासा.

सर्व्हरला दोष देण्यापूर्वी फाइल तपासा. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 चालवल्यावर फाइल उघडली का आणि नंतर क्रेडेन्शियल स्वीकारली गेली का हे छापले जाते, ज्यामुळे पुढे कोणता स्तर बदलायचा ते कळते.

स्ट्रीम, stdin आणि त्यांनी निर्माण होणाऱ्या त्रुटी

पासवर्ड पाइपमध्ये टाकणे हे बहुतेक लोक प्रथम करून पाहतात आणि सर्वाधिक आश्चर्य असलेला मार्ग आहे. प्रक्रिया बदली कारण क्लायंटला फक्त वाचनीय डिस्क्रिप्टर लागतो: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin पास करणे तेव्हाच चालते जेव्हा क्लायंट विचारतो त्या क्षणी stdin अजून उघडे आणि वाचनीय असते, जे आधीच ते संपवलेल्या पाइपलाइनमध्ये खरे नाही.

ERROR: could not read Auth username from stdin ला दोन वेगळी कारणे आहेत. काही 2.3.x क्लायंटवर संदेश stdin हाताळणीतील दोषातून आला होता जो नंतरच्या 2.3 आवृत्त्यांनी दुरुस्त केला, त्यामुळे इतका जुना क्लायंट केवळ अपग्रेडने सुधारतो. सध्याच्या क्लायंटवर तेच वाक्य म्हणजे क्लायंटने कन्सोल इनपुट मागितले आणि stdin टर्मिनल नव्हते - नेमकी हीच स्थिती systemd युनिट, cron कार्य किंवा -t शिवाय सुरू केलेल्या कंटेनरमध्ये असते.

auth-nocache तिसरे लूप जोडते जे तुटलेल्या पासवर्डसारखे दिसते. ते वापरानंतर क्रेडेन्शियल स्मृतीतून टाकून देते, त्यामुळे नेटवर्क बदलामुळे झालेल्या पुनर्जोडणीला पुन्हा प्ले करायला काहीच नसते आणि प्रॉम्प्ट परत येतो. हा निर्देश जसा रचला आहे तसा कार्यरत आहे. auth-nocache क्लायंट स्मृतीत काय ठेवतो ते बदलते, सर्व्हर किंवा ओळख पुरवठादार खात्याबद्दल काय विचारतो ते नाही, त्यामुळे संपूर्ण उपाय म्हणजे तीच फाइल पुन्हा पुरवणे, जी पुन्हा सुरू करताना पुन्हा वाचली जाते - आणि व्यवस्थापित कनेक्शनसाठी ही पुरवणी मंजूर रहस्य भांडारातून आली पाहिजे, स्क्रिप्टमधील पासवर्डमधून नाही.

प्रॉम्प्ट दुसऱ्या प्रक्रियेकडे असताना व्यवस्थापन इंटरफेस

टनेलवर आधीच देखरेख करणारा नियंत्रक त्याच्या प्रश्नांनाही उत्तर देऊ शकतो. क्लायंट --management 127.0.0.1 7505 सह सुरू करा, स्थिती ओळी वाचा, आणि >PASSWORD:Need 'Auth' username/password कडे लक्ष ठेवा. नियंत्रक वेगळ्या कमांड ओळींवर username "Auth" alice नंतर password "Auth" ... ने उत्तर देतो. 'Auth' टोकन विनंतीतील ओळखकर्ता पुन्हा म्हणते आणि तो जुळला पाहिजे, अन्यथा उत्तर दुर्लक्षित होते आणि क्लायंट वाट पाहतो.

किंमत म्हणजे आता तुमच्याकडे असलेले स्थिती यंत्र: कनेक्शनचा क्रम, क्लायंट पुन्हा सुरू करणे, आणि होस्टवरील इतर वापरकर्त्यांनी पोहोचू नये असे स्थानिक सॉकेट. तुम्ही विकत घेता ते रनटाइमवर पुरवलेले क्रेडेन्शियल, डिस्कवर फाइल नाही आणि अडकू शकणारा प्रॉम्प्ट नाही. तुमच्या स्टॅकमधील दुसरे काहीही हा प्रोटोकॉल आधीच बोलत नसेल, तर हा मार्ग देखभाल करावी लागणारी घटक जोडतो.

क्रेडेन्शियल समस्येसारखे दिसणारे अपयश

कधीही पूर्ण न होणारे TLS हस्तांदोलन, किंवा VERIFY ERROR: depth=0, error=certificate signature failure, हे विश्वासाचे समस्ये आहे आणि कोणतेही वापरकर्तानाव वाचण्यापूर्वी घडते. UDP श्रोत्याकडे निर्देशित proto tcp क्लायंट त्याच ठिकाणी अपयशी होतो: पॅकेट कधीही प्रमाणीकरण टप्प्यापर्यंत पोहोचत नाहीत, त्यामुळे प्रत्येक पासवर्ड संबंधामुळे चुकीचा दिसतो. क्रेडेन्शियल पाठवण्यापूर्वी प्रमाणपत्र पडताळणी सुरू ठेवा; ओळखीचा प्रॉम्प्ट पासवर्ड कोणाला मिळतो याबद्दल काहीही सांगत नाही. क्रेडेन्शियलला स्पर्श करण्यापूर्वी प्रमाणपत्र साखळी, सामान्य नाव आणि वाहतूक तपासा.

प्रोफाइल जुळवणाऱ्या स्क्रिप्टमधील shell त्रुटी हा दुसरा खोटा सुगावा आहे. [ ! -f "$file" ] मध्ये गहाळ जागा command not found निर्माण करते, स्क्रिप्ट लवकर थांबते, प्रोफाइल कधीही पुन्हा तयार होत नाही, आणि क्लायंट आधीच्यासह सुरू होतो. ती त्रुटी shellची आहे, प्रमाणीकरणाची नाही, आणि पासवर्ड कितीही वेळा पुन्हा टाइप केला तरी ती पुसली जाणार नाही.

या प्रवाहातील प्रत्येक प्रॉम्प्ट हे क्रेडेन्शियल नाही. खाजगी की पासफ्रेज, HTTP प्रॉक्सी लॉगिन आणि सेवेचा पासवर्ड या वेगवेगळ्या टप्प्यांवर मागितल्या जाणाऱ्या तीन वेगळ्या रहस्ये आहेत, आणि की पासफ्रेज सामान्यतः auth-user-passऐवजी क्लायंट किंवा एजंट हाताळतो. TLS सत्र उभे राहण्यापूर्वी प्रॉम्प्ट दिसल्यास तुम्ही चुकीच्या प्रश्नाचे उत्तर देत आहात आणि खाते रीसेट काहीही मदत करणार नाही. चुकीचा प्रॉम्प्ट वगळल्यानंतर उर्वरित तपासण्या सर्वात पहिल्या स्तरापासून सुरू होतात:

• शेवटची क्रेडेन्शियल ओळ नाही तर पहिली प्रोटोकॉल त्रुटी वाचा: TLS, नंतर प्रमाणीकरण, नंतर push.
• फाइल दोन ओळींची आहे, कॅरेज रिटर्न नाहीत, आणि निरपेक्ष मार्गाने संदर्भित आहे याची खात्री करा.
• प्रोफाइल आणि कमांड ओळ निर्देशाबद्दल एकमत नसल्याची खात्री करा.
• "क्रेडेन्शियल स्वीकारली" आणि "रहदारी वाहत आहे" वेगळे करा - मार्गनिर्देशन आणि DNS नंतरचा स्तर आहे.

क्लायंट push टप्प्यात पोहोचल्यावर क्रेडेन्शियलकडे पाहणे थांबवा आणि सर्व्हरने पाठवलेले मार्ग व DNS सर्व्हर वाचायला सुरुवात करा. ती पुढची समस्या आहे, आणि तुम्ही नुकताच दुरुस्त केलेल्या पासवर्डशी तिचा काहीही संबंध नाही.