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 सेटिंग पुन्हा सुरू करण्याची गरज पूर्णपणे दूर करते का ते तपासा। चालू राहणारे सत्र तुम्ही स्वयंचलित करू पाहत असलेल्या प्रॉम्प्टपर्यंत कधीही पोहोचत नाही।