Ubuntu पर बूट के समय OpenVPN: NetworkManager या systemd?

अधिकांश गाइड इस चुनाव को सौंदर्य का विषय बताती हैं: या तो 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 कॉन्फ़िगरेशन की ओर इशारा करता है।

पहले से तय करें कि टनल ऊपर न आ सके तो क्या होना चाहिए। सामान्य कनेक्टिविटी पर लौटना एक नीति है, और उसे पहले शुरू होने वाले किसी भी प्रबंधक पर छोड़ने के बजाय लिख लेना चाहिए।