openvpn3 session-start आपकी क्रेडेंशियल फ़ाइल को अनदेखा करता है

2.x क्लाइंट से जुड़ें और प्रोफ़ाइल काम करता है; वही फ़ाइल 3.x क्लाइंट को दें और वह पासवर्ड संकेत पर रुक जाता है। --auth-user-pass creds.txt को openvpn3 session-start को दें और नतीजा वही रहता है, क्योंकि नए क्लाइंट में फ़ाइल पढ़ने वाला कोई चरण नहीं है। इनकार जानबूझकर है: क्रेडेंशियल किसी सत्र के होते हैं, और सत्र किसी सेवा से बनता है, आपके टर्मिनल की प्रक्रिया से नहीं। इंटरैक्टिव संकेत और ऑटोलोड सहायक में से चुनें, और जानें कि हर एक क्या संग्रहीत करता है।

सहेजी गई फ़ाइल के पास जाने की जगह क्यों नहीं है

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

पुराने पैटर्न को नाम देना ठीक है, ताकि उसे भुलाना आसान हो: प्रोफ़ाइल किसी क्रेडेंशियल फ़ाइल का संदर्भ देता है, और टनल शुरू होने पर डेमॉन उसे पढ़ता है। नए मॉडल में क्रेडेंशियल किसी सत्र के होते हैं और उस सत्र के शुरू होने पर दिए जाते हैं। 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 सेटिंग फिर से शुरू करने की ज़रूरत को पूरी तरह हटा देती है या नहीं। ऊपर रहने वाला सत्र उस संकेत तक कभी नहीं पहुँचता जिसे आप स्वचालित करना चाहते हैं।