OpenVPN क्रेडेन्शियल फाइल की व्यवस्थापन सॉकेट: काय स्क्रिप्ट करावे
auth-user-pass खात्याच्या प्रॉम्प्टची काळजी घेते; व्यवस्थापन सॉकेट चारहींची. एक्सपोजर, स्क्रिप्टिंग खर्च आणि सेवेमध्ये प्रत्येक कसे अपयशी होते याची तुलना करा.
OpenVPN सुरू करून कधीही जोडणी न होणारी स्क्रिप्ट सहसा नेटवर्कची समस्या नसते: क्लायंट टर्मिनल नसलेल्या प्रॉम्प्टवर बसलेला असतो। OpenVPN कडे माणसाशिवाय त्या प्रॉम्प्टला उत्तर देण्याचे नेमके दोन समर्थित मार्ग आहेत, auth-user-pass मागील क्रेडेन्शियल फाइल आणि व्यवस्थापन सॉकेट, आणि ते एकमेकांच्या जागी वापरता येत नाहीत। फाइल एका निर्देशाचा खर्च करते आणि एका प्रॉम्प्टला उत्तर देते; सॉकेट प्रत्येक प्रॉम्प्टला उत्तर देते आणि loopback पोर्ट उघडू शकणाऱ्या कोणत्याही गोष्टीला प्रमाणीकरण नसलेला नियंत्रण चॅनेल देते। तुमच्या उपयोजनात कोणते बसते हे प्रत्यक्षात कोणता प्रॉम्प्ट अडवत आहे आणि कोणते गुपित शांत ठेवण्याची तुमची ऐपत आहे यावर अवलंबून आहे।
यंत्रणा निवडण्यापूर्वी प्रॉम्प्टला नाव द्या
चार प्रॉम्प्ट टर्मिनलवर सारखेच दिसतात। खाते जोडी सर्व्हरच्या PAM किंवा auth-user-pass-verify सेटिंगमधून येते आणि तिला auth-user-pass उत्तर देते। खाजगी कीचा पासफ्रेज की फाइलचा असतो आणि --askpass मधून वाचला जातो किंवा हाताने टाइप केला जातो। PKCS#12 बंडल स्वतःचा पासवर्ड मागते। प्रॉक्सी प्रमाणीकरण खाते क्रेडेन्शियल नव्हे, तर --http-proxy घेत असलेली auth फाइल वापरते।
OpenVPN systemd, PHP किंवा Node चे अपत्य म्हणून चालत असताना टर्मिनल नसते, त्यामुळे यापैकी कोणतेही शांतपणे अडवते। प्रक्रिया तिथेच बसलेली असते, सायफर ओळीनंतर लॉग थांबतो आणि युनिट शेवटी वेळ संपून जाते; कोणता प्रॉम्प्ट प्रलंबित आहे हे पाहण्याऐवजी लोक पुनर्प्रयत्न लूप किंवा sleep जोडतात त्याचे कारण तोच शांतपणा आहे। चारहीला उत्तर फक्त व्यवस्थापन सॉकेटच देऊ शकते। क्रेडेन्शियल फाइल पहिल्याला उत्तर देते आणि दुसऱ्या कशालाही नाही।
auth-user-pass: एक फाइल, एक प्रॉम्प्ट
फाइल पहिल्या ओळीत वापरकर्तानाव आणि दुसऱ्या ओळीत पासवर्ड ठेवते, आणि दुसरे काहीही नाही: अवतरण चिन्ह नाहीत, की-नावे नाहीत, टिप्पणी नाही। मोड 600 सेट करा आणि openvpn चालवणाऱ्या खात्याला मालक करा, जे सेवेसाठी बहुतेक वेळा तुमच्या लॉगिनऐवजी समर्पित वापरकर्ता असते। /root खालील root च्या मालकीची फाइल तुमच्या शेलमध्ये चालणाऱ्या आदेश आणि बूटला अपयशी होणाऱ्या युनिटमधील फरक आहे।
दोन तपशील योग्य फाइलला प्रॉम्प्ट बनवतात। CRLF जतन करणारा संपादक पासवर्डला चिकटलेला कॅरेज रिटर्न सोडतो, त्यामुळे सर्व्हर फाइलमध्ये योग्य दिसणारा पासवर्ड नाकारतो; डोळ्यांनी नव्हे, cat -A किंवा od -c ने तपासा। आणि प्रोफाइलमधील आर्ग्युमेंटविरहित auth-user-pass डिझाइननुसार «वापरकर्त्याला विचारा» असा अर्थ देतो, ज्याला कमांड ओळीवरील दुसरा निर्देश ओलांडू शकत नाही, कारण प्रोफाइल जिथे आहे तिथेच पार्स होते।
पर्यायांचा क्रम तिसरा सापळा आहे, आणि तो आवृत्तीनुसार बदलतो। काही OpenVPN 2.4 बिल्ड --config आधी आल्यास --auth-user-pass कडे दुर्लक्ष करतात, त्यामुळे तेच दोन पर्याय उलट क्रमाने जोडले जातात। निर्देश प्रोफाइलमध्ये किंवा कमांड ओळीवर --config नंतर ठेवा, आणि दुसरे काही बदलण्यापूर्वी प्रोफाइलमधील प्रत्येक आढळ grep करा।
auth-nocache या यंत्रणेचा भाग आहे पण काहीही पुरवत नाही। क्लायंट क्रेडेन्शियल स्मृतीत किती काळ ठेवतो हे मर्यादित करते, जे क्रॅशनंतर मदत करते आणि फाइल नसल्यास अजिबात मदत करत नाही। सर्व्हरकडील सत्र कालबाह्य झाल्यावर पुन्हा जोडणी फाइल पुन्हा वाचते, त्यामुळे बूटला चाललेले क्रेडेन्शियल दिवसाच्या मध्यातही संपू शकते।
व्यवस्थापन सॉकेट: प्रत्येक प्रॉम्प्ट, अधिक पृष्ठभाग
क्लायंटला लिसनरसह सुरू करा आणि प्रॉम्प्ट त्यावर नोंदवले जातील असे स्पष्ट सांगा, OpenVPN 2.6 मॅन्युअलमध्ये दस्तऐवजीकृत निर्देश वापरून:
management 127.0.0.1 3030
management-query-passwords
bash मधून जोडणी एका राखीव फाइल डिस्क्रिप्टरवर ठेवा आणि स्थानाऐवजी प्रॉम्प्टच्या नावाने उत्तर द्या, कारण पुन्हा जोडणी वेगळ्या क्रमाने विचारू शकते:
exec 3<>/dev/tcp/127.0.0.1/3030
while read -r -u 3 line; do
case "$line" in
*"Need 'Auth' username/password"*)
echo 'username "Auth" alice' >&3
echo 'password "Auth" secret' >&3 ;;
*"Need 'Private Key' password"*)
echo 'password "Private Key" secret' >&3 ;;
esac
done
सीमा म्हणजे वाहतूक। व्यवस्थापन प्रोटोकॉल loopback वर TCP वर साधा मजकूर आहे, त्यामुळे दूरस्थ नियंत्रकाला पोहोचण्यासाठी लिसनर LAN किंवा बोगदा पत्त्यावर प्रकाशित करू नये; दूरस्थ नियंत्रक म्हणजे SSH अग्रेषण, अधिक रुंद बाइंड नव्हे। समुदाय डेमन एका वेळी एकच व्यवस्थापन क्लायंट स्वीकारतो, त्यामुळे GUI किंवा मॉनिटर तुमच्या स्क्रिप्टसह सॉकेट सामायिक करू शकत नाही। दुसरी जोडणी रांगेत न ठेवता नाकारली जाते, आणि अपयश बहिरे झालेल्या स्क्रिप्टसारखे दिसते।
ते सॉकेट नियंत्रण चॅनेलही आहे। व्यवस्थापन पासवर्डशिवाय 127.0.0.1:3030 ला जोडू शकणारे काहीही स्थिती वाचू शकते, बोगदा मारू शकते किंवा स्वतः प्रॉम्प्टला उत्तर देऊ शकते। व्यवस्थापन पासवर्ड आणि क्रेडेन्शियल फाइल एकाच वर्गातील गुपिते आहेत, आणि दोन्ही समान काळजीला पात्र आहेत।
उपयोजनाला कोणते बसते
क्रेडेन्शियल फाइल निवडा जेव्हा एकमेव प्रॉम्प्ट खाते जोडी असेल, क्लायंट स्थिर मालकासह सेवा म्हणून चालेल, आणि तुम्ही नियंत्रित न करता येणाऱ्या बॅकअपपासून बाहेर 600 फाइल ठेवू शकता। व्यवस्थापन सॉकेट निवडा जेव्हा की पासफ्रेज किंवा PKCS#12 पासवर्ड गुंतलेला असेल, जेव्हा रॅपर आधीच प्रक्रियेवर देखरेख करत असेल, किंवा जेव्हा पुन्हा जोडणी डीबग करताना स्थिती आणि प्रॉम्प्ट पाहायचे असतील।
दोन अटी निर्णय हलवतात। रॅपर /bin/sh असल्यास, बाइनरीला थेट बोलावणारे systemd युनिट असल्यास, किंवा किमान कंटेनर असल्यास, फक्त-bash सॉकेट गोंद उपलब्ध नसतो आणि फाइल स्वस्त उत्तर आहे। गुपित वारंवार फिरत असल्यास कोणतीही फाइल त्यासाठी चांगले घर नाही: लहान रॅपरमधून कीरिंग विचारा आणि युनिटला रॅपर बोलावू द्या, जे फिरणे एकाच ठिकाणी ठेवते आणि पासवर्ड शेल इतिहासाबाहेर।
प्रक्रिया प्रतिस्थापन दोन्हींच्या मध्ये आहे आणि कोणाचेही नाही। खालील एका ओळीचा आदेश चालतो कारण bash तो openvpn सुरू होण्यापूर्वी विस्तारित करते, क्लायंट वाक्यरचना समजतो म्हणून नाही:
openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")
ते /bin/sh अंतर्गत, शेलला बायपास करणाऱ्या युनिटमध्ये आणि bash किंवा /dev/fd नसलेल्या प्रतिमांमध्ये तुटते। ते परस्परसंवादी चाचणीसाठी ठेवा, कधीही सेवा अवलंबून असलेला करार म्हणून नाही।
गुपिताचे रक्षण करा, नंतर लॉगवरून पडताळणी करा
दोन्ही यंत्रणा OpenVPN प्रक्रियेला वाचनीय गुपित सोडतात। पासवर्ड कधीही कमांड ओळीवर किंवा युनिट फाइलमध्ये ठेवू नका, जिथे ps आणि systemctl तो प्रत्येक स्थानिक वापरकर्त्याला दाखवतात; फाइलचा मार्ग द्या, आतील मूल्य नाही। जिथे प्रमाणपत्रे खाते जोडीची जागा घेऊ शकतात, तिथे ते प्रॉम्प्टचा वर्ग लपवण्याऐवजी काढून टाकते।
योग्य चाल प्रॉम्प्ट क्रम पूर्ण होणे आणि सत्र «Initialization Sequence Completed» पर्यंत पोहोचणे दाखवते। क्लायंट त्याच प्रॉम्प्टवर थांबल्यास जुळणी अपयशी झाली: सॉकेटने पाठवलेल्या नेमक्या ओळी छापा, अवतरण चिन्हे आणि प्रॉम्प्टचे नाव तपासा, आणि sleep जोडण्याऐवजी नमुना दुरुस्त करा। यशाची नोंद देऊन काहीही न वाहणारा बोगदा राउटिंग किंवा push ची समस्या आहे, क्रेडेन्शियलची नाही।
नंतर फक्त पहिली सुरुवात नाही, तर पुन्हा जोडणीही चाचणी करा। सर्व्हरकडील सत्र सोडा किंवा त्याची वेळ संपण्याची वाट पाहा; क्लायंट पुन्हा विचारतो, आणि तिथेच बूटला योग्य दिसलेली फाइल पुन्हा जोडणाऱ्या खात्यासाठी अजूनही वाचनीय आहे का हे दाखवते।