openvpn3 session-start ले तपाईंको प्रमाणपत्र फाइल बेवास्ता गर्छ

2.x क्लाइन्टसँग जोड्नुहोस् र प्रोफाइल चल्छ; त्यही फाइल 3.x क्लाइन्टलाई दिनुहोस् र त्यो पासवर्ड प्रॉम्प्टमा रोकिन्छ। --auth-user-pass creds.txt openvpn3 session-start लाई दिए पनि नतिजा उही हुन्छ, किनभने नयाँ क्लाइन्टमा त्यो फाइल पढ्ने चरण छैन। यो अस्वीकृति जानाजानको हो: प्रमाणहरू सत्रसँग सम्बन्धित हुन्छन्, र सत्र टर्मिनलको प्रक्रियाले होइन, सेवाले बनाउँछ। अन्तरक्रियात्मक प्रॉम्प्ट र autoload सहायकमध्ये एउटा छान्नुहोस्, र प्रत्येकले के राख्छ जान्नुहोस्।

सुरक्षित फाइललाई जाने ठाउँ किन छैन

नयाँ डिजाइनमा कन्फिगरेसन व्यवस्थापन र सत्र व्यवस्थापन प्रणाली बसबाट कुरा गर्ने छुट्टाछुट्टै सेवाहरू हुन्। यही विभाजनले साधारण प्रयोगकर्तालाई विशेषाधिकारप्राप्त डेमनले उनीहरूको तर्फबाट सुरक्षित पासवर्ड फाइल नपढी सत्र सुरु गर्न दिन्छ। फाइलमा आधारित प्रमाणहरूको त्यो मोडेलमा ठाउँ छैन, किनभने तिनीहरूलाई पढ्ने डेमन पक्षको सुरुवात छैन। अस्वीकृति वास्तुकलाको परिणाम हो, हराएको सुविधा होइन।

पुरानो ढाँचालाई नाम दिनु उपयुक्त हुन्छ ताकि त्यसलाई छोड्न सजिलो होस्: प्रोफाइलले प्रमाणपत्र फाइललाई सन्दर्भ गर्छ, र सुरुङ सुरु हुँदा डेमनले त्यो पढ्छ। नयाँ मोडेलमा प्रमाणहरू सत्रसँग सम्बन्धित हुन्छन् र त्यो सत्र सुरु हुँदा दिइन्छ। openvpn3 session-start --config work.ovpn ले तिनीहरू माग्छ, र --auth-user-pass creds.txt अस्वीकार गरिन्छ किनभने त्यो मार्गमा फाइल खोल्ने केही छैन। तपाईंले भेट्ने हरेक 2.x विधिले अब नभएको चरण मान्छ।

कन्फिगरेसन र साइट-स्थानीय सेटिङहरू पनि छुट्टिएका छन्, जसले दोस्रो आश्चर्य बुझाउँछ। प्रोफाइल पूर्ण देखिन सक्छ तर त्यसले बनाउने जडानमा राउटिङ र रिजोल्भर कन्फिगरेसन हुँदैन। ती भागहरू आयात गरिएको फाइलबाट अलग, साइट-स्थानीय सेटिङका रूपमा लागू गरिन्छ।

प्रॉम्प्ट मार्ग र त्यसले छोड्ने सत्र

सत्र सुरु हुँदा पासवर्ड दिनु भन्ने अभिप्रेत कार्यप्रवाह हो। क्लाइन्टले एक पटक सोध्छ, प्रमाणहरू सत्र ब्याकइन्डलाई दिन्छ र अगाडि बढ्छ:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

त्यो मार्गले डिस्कमा केही लेख्दैन। टर्मिनल बन्द भएपछि पनि सत्र चलिरहन्छ, जसले प्रक्रिया आफ्नो शेलसँगै मर्छ भन्ने अपेक्षा गर्नेहरूलाई अचम्मित बनाउँछ। सत्र ह्यान्डलिङलाई सेवामा सार्नुको उद्देश्य यही हो। सत्रले त्यसको अनुरोध गर्ने टर्मिनलभन्दा लामो समय बाँच्छ, र त्यसलाई स्पष्ट रूपमा रोक्नुपर्छ।

अगाडि मानिस भएको वर्कस्टेसनका लागि यो सबैभन्दा सुरक्षित विकल्प पनि हो, किनभने जोगाउन वा बिर्सन सुरक्षित गोप्य कुरा हुँदैन। टाइप गर्न कोही नभएको ठाउँमा मात्र यो उपयुक्त हुँदैन।

किबोर्डअगाडि मानिस नभएको अटोमेसन

मेसिनले मानिसबिना जोडिनुपर्ने ठाउँमा परियोजनाले openvpn3-autoload उपलब्ध गराउँछ। यसले प्रोफाइलको डिरेक्टरी र प्रत्येक प्रोफाइलका लागि मिल्ने विवरणकर्ता पढ्छ, र विवरणकर्ताले प्रमाणहरू स्पष्ट पाठमा दिन्छ। सहायक छुट्टै बाइनरी हो, सामान्यतया /usr/sbin/openvpn3-autoload मा, session-start को फ्ल्याग होइन। यसलाई तयार पार्नु भनेको डिरेक्टरी बनाउनु, विवरणकर्ताले अपेक्षा गर्ने नाममा प्रोफाइल प्रतिलिपि गर्नु र विवरणकर्ता लेख्नु हो।

प्रत्येक प्रयोगकर्ताको सेटअप यस्तो देखिन्छ, सत्रको मालिक हुने खाताबाट चलाउनुहोस्। डिरेक्टरी मोडले अन्य स्थानीय प्रयोगकर्तालाई बाहिर राख्छ:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

विवरणकर्ताले प्रमाणहरूको नाम दिन्छ र स्वचालित सुरुवात माग्छ। पासवर्डको मान संस्करण नियन्त्रणबाहिर राख्नुहोस्:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

त्यसपछि सहायकलाई एक पटक बोलाउनुहोस् र सत्र देखिन्छ भनी पुष्टि गर्नुहोस्। दोस्रो आदेश जाँच हो, अर्को सेटअप चरण होइन:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

बुटको समयमा openvpn3-autoload.service नामको प्याकेज गरिएको एकाइले प्रत्येक प्रयोगकर्ताको होइन, सम्पूर्ण प्रणालीको डिरेक्टरी /etc/openvpn3/autoload प्रयोग गर्छ। त्यो स्थानलाई root स्वामित्व र कडा मोड चाहिन्छ, र विवरणकर्ताले अझै पासवर्ड स्पष्ट पाठमा राख्छ। सम्झौता स्पष्ट छ: पासवर्ड अब डिस्कमा छ, त्यसैले त्यो डिरेक्टरीलाई गोप्य मान्नुहोस्, होस्टबाहिरका ब्याकअपबाट हटाउनुहोस्, र मानिस उपस्थित हुँदा सधैं अन्तरक्रियात्मक मार्ग छान्नुहोस्।

पासवर्ड विफलताजस्तो देखिने बस विफलता

प्रमाणहरूलाई दोष दिइने केही विफलता त्यस्तै हुँदैनन्। सेवाको सक्रियता मार्गको नाम दिने अनुमति त्रुटिले दुईमध्ये एउटा अर्थ दिन्छ: ब्याकइन्ड चलिरहेको छैन, वा बोलाउनेलाई त्यो सक्रिय गर्ने अनुमति छैन। कुनै प्रोफाइल सम्पादनले दुवैलाई बदल्दैन। कन्फिगरेसन छुनुअघि सेवाको स्थिति र दिइएको बस नीति जाँच्नुहोस्।

तलका आदेशहरूले यी दुईलाई छुट्याउँछन्। पहिलोले ब्याकइन्ड चलिरहेको छ कि भनी रिपोर्ट गर्छ; दोस्रोले हालका बस त्रुटि देखाउँछ:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

अर्को सामान्य गलत पढाइ भनेको देखिने र तुरुन्तै हराउने सत्र हो। त्यो ढाँचाले सामान्यतया साइट-स्थानीय सेटिङ कहिल्यै लागू नभएको अर्थ दिन्छ, त्यसैले सुरुङ त्यसलाई उपयोगी बनाउने मार्ग र रिजोल्भर परिवर्तनबिना माथि आयो। अन्तिम लाइन होइन, क्रम पढ्नुहोस्: सत्र बनियो कि, जोडिएको अवस्थामा पुग्यो कि, र टिक्यो कि भन्ने तीन अलग तथ्य हुन्।

पुरानो क्लाइन्ट अझै प्रयोगमा हुँदा

2.x क्लाइन्टले अझै प्रमाणपत्र फाइल स्वीकार गर्छ, र किरिङले गोप्य कुरा कहिल्यै डिस्कमा नपुगी त्यसको प्रॉम्प्टको जवाफ दिन सक्छ। र्यापरले प्रविष्टि समाधान गर्छ, त्यसैले फाइलले पासवर्ड होइन, खोजको नाम दिन्छ। यो व्यवस्था अनलक गरिएको किरिङमा निर्भर छ, जुन लगइन सत्र नभएको कन्टेनर वा कोही साइन इन गर्नुअघि सुरु हुने एकाइले दिन सक्दैन। त्यसपछि खोज उपकरणले लेख्न नसक्ने सङ्ग्रहको रिपोर्ट गर्छ, त्यसैले किरिङ दोष प्रमाण दोषजस्तो देखिन्छ।

यीमध्ये केही बनाउनुअघि, प्रोफाइलको keepalive सेटिङले पुनः सुरु गर्ने आवश्यकता पूर्ण रूपमा हटाउँछ कि जाँच्नुहोस्। चलिरहने सत्र तपाईंले स्वचालित बनाउन खोजेको प्रॉम्प्टमा कहिल्यै पुग्दैन।