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 सर्भरहरू पढ्न सुरु गर्नुहोस्. त्यो अर्को समस्या हो, र तपाईंले भर्खरै सुधारेको पासवर्डसँग त्यसको कुनै सम्बन्ध छैन.