OpenVPN प्रमाणपत्र फाइल वा व्यवस्थापन सकेट: कुन स्क्रिप्ट गर्ने

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 समस्या हो, प्रमाणपत्र समस्या होइन।

त्यसपछि पहिलो सुरु मात्र होइन, पुनः जडान पनि परीक्षण गर्नुहोस्। सर्भरतर्फको सत्र छोड्नुहोस् वा त्यसको समय सकिने प्रतीक्षा गर्नुहोस्; क्लाइन्ट फेरि सोध्छ, र त्यहीँ बुटमा सही देखिएको फाइल पुनः जडान हुने खाताका लागि अझै पढ्न योग्य छ कि छैन देखाउँछ।