Ubuntu वर बूट होताना OpenVPN: NetworkManager की systemd?
लॅपटॉप आणि स्क्रीन नसलेल्या सर्व्हरला वेगळे बूट मार्ग लागतात। NetworkManager च्या दुय्यम कनेक्शनची openvpn-client@ आणि त्याच्या क्रेडेन्शियल फाइलशी तुलना करा।
बहुतेक मार्गदर्शक ही निवड दिसण्यावरचा प्रश्न म्हणून मांडतात: एकतर NetworkManager ने टनेल वर उचलू द्या, किंवा systemd उदाहरण सक्षम करा आणि झाले। दोन्ही मार्ग एका गोष्टीत वेगळे आहेत जी स्क्रीन नसलेल्या यंत्रावर निकाल ठरवते, आणि तिचा कोणते साधन नवे आहे याच्याशी काही संबंध नाही। NetworkManager सत्राद्वारे रहस्ये उघडते; systemd उदाहरणाकडे उघडण्यासाठी सत्र नाही। तुमच्यासमोरच्या यंत्राशी जुळणारी रहस्य-हाताळणी असलेला मार्ग निवडा।
बाकी सर्व, रूट इन्स्टॉलेशनपासून पुन्हा जोडण्याच्या वर्तनापर्यंत, त्या पहिल्या निर्णयातून येते।
कीरिंग हाच असा फरक आहे ज्याचा कोणी उल्लेख करत नाही
NetworkManager कडे VPN प्रोफाइल असते तेव्हा संकेतशब्द लॉगिन कीरिंगमध्ये राहू शकतो, जो वापरकर्ता साइन इन करतो तेव्हा उघडतो। लॅपटॉपवर ते चांगले काम करते: व्यक्ती तिथे असते, कीरिंग उघडते, टनेल वर येते। देखरेखीशिवाय बूट होणाऱ्या सर्व्हरवर काहीही उघडणारा कोणी नसतो, म्हणून प्रोफाइल अशा रहस्याची वाट पाहते जे कधीच येत नाही। कनेक्शन कॉन्फिगर केलेले दिसते आणि कधीच सक्रिय होत नाही।
systemd उदाहरण डिस्कवरून क्रेडेन्शियल फाइल वाचून ती अडचण टाळते, ज्यामुळे फाइल ही तुम्ही संरक्षित करत असलेली वस्तू बनते। chmod 400 आणि root ची मालकी हे किमान आहे, आणि फाइल तुमच्या नियंत्रणाबाहेरील बॅकअप आणि इमेज टेम्पलेटपासून दूर राहिली पाहिजे।
VPN ला कनेक्शनशी जोडणे हे बूटची हमी नाही
nm-connection-editor मध्ये, VPN ऐवजी वायर्ड किंवा वायरलेस कनेक्शन निवडा, General टॅब उघडा, स्वयंचलितपणे VPN ला जोडण्याचा पर्याय टिक करा आणि प्रोफाइलला नाव द्या। नंतर प्राथमिक कनेक्शन जोडलेल्या स्थितीत पोहोचल्यावर NetworkManager VPN ला दुय्यम कनेक्शन म्हणून सक्रिय करते। हे अवलंबन आहे, फायरवॉल नियम नाही। टनेल वर येण्यापूर्वीच्या सेकंदांत पॅकेट अजूनही बाहेर जाऊ शकतात, आणि उघडता न आलेले साठवलेले रहस्य यंत्राला त्याशिवाय ऑनलाइन ठेवते।
जर आवश्यकता अशी असेल की टनेलशिवाय काहीही बाहेर जाऊ नये, तर ते सांगा आणि किल स्विच बनवा, कारण हे सेटिंग एकही देणार नाही। सस्पेंड आणि रिझ्यूमही तपासा, कारण परत येताना दुय्यम कनेक्शनचे पुनर्मूल्यांकन होते।
systemd उदाहरणाला जुळणारे फाइलनाव लागते
प्रोफाइल पॅकेज अपेक्षित असलेल्या क्लायंट डिरेक्टरीत ठेवा, उदाहरणार्थ /etc/openvpn/client/office.conf, आणि आतून क्रेडेन्शियल फाइलला auth-user-pass office.cred ने संदर्भ द्या। उदाहरणाचे नाव प्रत्ययाशिवाय फाइलनाव आहे, म्हणून openvpn-client@office फाइल office.conf वाचते। sudo systemctl enable --now openvpn-client@office ने ते सक्षम करा आणि ब्लॉगमधील उदाहरणावर विश्वास ठेवण्याऐवजी systemctl cat openvpn-client@office ने जुळणीची पुष्टी करा।
प्रोफाइलमधील मार्ग प्रोफाइलशी नाही, तर युनिटच्या कार्यरत डिरेक्टरीशी सापेक्षपणे सोडवले जातात, म्हणून सापेक्ष ca किंवा auth-user-pass ओळ हाताने तपासल्यावर काम करत असली तरी बूट होताना अयशस्वी होऊ शकते। युनिटला शोधावे लागणाऱ्या सर्व गोष्टींसाठी निरपेक्ष मार्ग वापरा। नंतर खऱ्या बूटनंतर journalctl -u openvpn-client@office -b वाचा; टनेलशिवाय सक्रिय असल्याचे सांगणारे युनिट सहसा त्या लॉगमध्ये गहाळ फाइलचे नाव देते।
जुनी पॅकेज वेगळे टेम्पलेट नाव देतात, म्हणून systemctl list-unit-files 'openvpn*' या होस्टवर कोणते आहे हे ठरवते।
पुन्हा जोडण्याचे वर्तन वेगळा निर्णय आहे
ping-restart असलेले प्रोफाइल टनेल पडल्यानंतर ते पुन्हा बांधते, आणि रीस्टार्ट निर्देश असलेले युनिट सेवा स्तरावर तसेच काहीसे करते। त्या तुम्ही निवडता त्या धोरणे आहेत, वारशाने मिळणारी डीफॉल्ट मूल्ये नाहीत। कनेक्शन फक्त मागणीनुसार वर यायला हवे असेल, तर रीस्टार्ट वर्तन जाणीवपूर्वक काढून टाका आणि का ते लिहा। युनिट नेटवर्क वापरण्यायोग्य होण्यापूर्वी सुरू होत असेल, तर त्याला पुन्हा प्रयत्नाचे धोरण लागते, कारण बूट होताना एक अयशस्वी प्रयत्न आपोआप पुनरावृत्त होत नाही।
थांबवणेही तितकेच शब्दशः आहे: sudo systemctl disable --now openvpn-client@office चालू असलेले उदाहरण थांबवते आणि बूट लिंक काढून टाकते। फक्त अक्षम केल्यास टनेल पुढील रीबूटपर्यंत चालू राहते, जे अक्षम करून तपासणाऱ्या आणि इंटरफेस वरच राहताना पाहणाऱ्या प्रत्येकाला आश्चर्यचकित करते।
रीबूट करा, नंतर चार गोष्टी क्रमाने तपासा
सेवा रीस्टार्ट करणे सेवेची चाचणी करते; यंत्र रीबूट करणे बूट मार्गाची चाचणी करते। रीबूटनंतर युनिट वर आले, नंतर दूरच्या सबनेटसाठी रूट आहे, नंतर यंत्र इंटरनेटला कोणता पत्ता दाखवते, आणि शेवटी नावे टनेलमधून सोडवली जातात याची पुष्टी करा। काही चुकले तर त्या चार तपासण्या त्याच क्रमाने अयशस्वी होतात, ज्यामुळे पहिले अपयश उपयुक्त ठरते।
रूटशिवाय सक्रिय युनिटचा सहसा अर्थ असा की प्रोफाइल जोडले गेले पण सर्व्हरने कोणताही रूट ढकलला नाही, किंवा रूट नंतर नाहीशा झालेल्या इंटरफेसवर बसवले गेले। ज्या रूटमध्ये नाव-शोध काम करत नाही ते टनेलकडे नाही, तर DNS कॉन्फिगरेशनकडे निर्देश करते।
टनेल वर येऊ शकत नाही तेव्हा काय व्हावे हे आधीच ठरवा। सामान्य कनेक्टिव्हिटीकडे परत जाणे हे धोरण आहे, आणि ते आधी सुरू झालेल्या कोणत्याही व्यवस्थापकावर सोडण्याऐवजी लिहून ठेवावे।