systemd VPN सेवा रोक देता है: Type= को क्लाइंट से मिलाएँ

यूनिट सही दिख सकती हैं, systemctl start सफलता बता सकता है, और दस सेकंड बाद सेवा निष्क्रिय पड़ी रहती है। या वह हर आधे मिनट में फिर से शुरू होती है जब तक स्टार्ट सीमा उसे रोक न दे। इनमें से कोई भी व्यवहार नेटवर्क की खराबी नहीं है: यूनिट ऐसी प्रक्रिया का जीवनकाल बताती है जो क्लाइंट वास्तव में जो करता है उससे मेल नहीं खाता। क्लाइंट फ़ोर्क करके बाहर निकल सकता है, या सत्र कॉन्फ़िगर करके तुरंत बाहर निकल सकता है।

सफल शुरुआत के कुछ सेकंड बाद यूनिट निष्क्रिय क्यों हो जाती है

systemd जिस प्रक्रिया को शुरू करता है उसी से स्थिति निकालता है, इसलिए Type= उस प्रक्रिया के बारे में एक दावा है, दस्तावेज़ नहीं। Type=simple के साथ कमांड चलने तक यूनिट सक्रिय गिनी जाती है और लौटने पर निष्क्रिय हो जाती है। इसलिए जो क्लाइंट कनेक्शन किसी सहायक को सौंपकर बाहर निकलता है, वह क्रैश जैसा दिखता है, टनल चालू होने पर भी। तब जर्नल ऐसा स्टार्ट-स्टॉप पैटर्न दिखाता है जो खराब बाइनरी की तरह पढ़ा जाता है।

नेटवर्क कॉन्फ़िगरेशन छूने से पहले क्लाइंट के व्यवहार के साथ यूनिट का प्रकार पढ़ें।

वह प्रकार चुनें जो क्लाइंट से मेल खाता है

दो पैटर्न अधिकांश वेंडर CLI को कवर करते हैं: एक कमांड जो सत्र कॉन्फ़िगर करके बाहर निकलता है, और एक कमांड जो लौटने से पहले सहायक को फ़ोर्क करता है। हर एक को अलग यूनिट आकार चाहिए।

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot और RemainAfterExit=true मिलकर कमांड लौटने के बाद भी यूनिट को सक्रिय रखते हैं, जो कॉन्फ़िगर-करो-और-निकलो पैटर्न से मेल खाता है, और स्टॉप कमांड सेवा को स्वच्छ बंद करता है। फ़ोर्क करने वाला क्लाइंट वही आकार रखता है पर उसे Type=forking चाहिए ताकि systemd संतान का पीछा करे। Restart=on-failure, RestartSec=30 और सीमित StartLimitBurst सेट करें, ताकि प्रदाता की रुकावट त्रुटि को दफ़न करने वाले रीस्टार्ट लूप में न बदले।

निगरानी वाले क्लाइंट को कभी डेमन बनने न दें

systemd के बाहर के पर्यवेक्षक उसी दीवार से टकराते हैं। जो runit रन स्क्रिप्ट डेमन बने क्लाइंट को चलाती है, वह तुरंत पर्यवेक्षक के पास लौटती है, और वह लौटना क्रैश समझकर एक और प्रतिलिपि शुरू कर देता है। हर पर्यवेक्षक अग्रभूमि की प्रक्रिया रखने की अपेक्षा करता है, जैसे sshd -D आगे रहता है। निगरानी वाले कमांडों के लिए डेमन फ़्लैग हटाएँ और पृष्ठभूमि का काम पर्यवेक्षक को दें। जो रैपर स्क्रिप्ट टनल बनने से पहले लौटती हैं, वे वही उलझन पैदा करती हैं।

जो प्रक्रिया स्वयं को अलग कर लेती है, वह उस सबके लिए अदृश्य है जिसे उस पर नज़र रखनी थी।

सत्र समाप्त होता है और टनल को साथ ले जाता है

डेस्कटॉप सत्र जिस क्लाइंट को शुरू करता है उसका स्वामी है। लॉगिन समाप्त करें और सत्र बस गायब हो जाती है, टनल को साथ ले जाती है, जिससे समझ आता है कि आखिरी विंडो बंद होने पर ग्राफ़िकल क्लाइंट का कनेक्शन अक्सर क्यों टूटता है। सर्वर को सिस्टम यूनिट या NetworkManager प्रोफ़ाइल इस्तेमाल करनी चाहिए जो अपने आप ऊपर आए। उपयोगकर्ता यूनिट तभी अर्थपूर्ण है जब टनल लॉगिन के साथ खत्म होनी हो, इसलिए उसे ग्राफ़िकल सत्र लक्ष्य से बाँधें और उसका उल्लेख उसके विवरण में करें।

सेवा उपयोगकर्ता उसी समस्या का दूसरा आधा हिस्सा है। root के स्वामित्व वाली और मोड 0600 वाली कुंजी दूसरे खाते के अंतर्गत चलने वाली यूनिट के लिए अपठनीय है, आपके शेल में sudo ने जो भी हासिल किया हो।

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

पता बनने के बाद निर्भर इकाइयों को क्रम दें

जब कोई डेमन ऐसे टनल पते से बंधता है जो अभी नहीं बना, तो वह Cannot assign requested address के साथ बाहर निकलता है। सुधार स्पष्ट क्रमबद्धता है, पुनः प्रयास का लूप नहीं।

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After= कार्यों को क्रम देता है, जबकि डिवाइस यूनिट पर Requires= निर्भर इकाई को इंटरफ़ेस के अस्तित्व से बाँधता है, जो केवल नेटवर्क लक्ष्य की प्रतीक्षा से अधिक मज़बूत है। संपादन के बाद प्रबंधक को फिर से लोड करें और निर्भर सेवा पुनः आरंभ करें, फिर यह मानने के बजाय कि क्रम प्रभावी हुआ, उसका जर्नल पढ़ें। क्लाइंट का आउटपुट StandardOutput=journal या किसी लॉग विकल्प के साथ जर्नल में भेजें, क्योंकि निगरानी वाला क्लाइंट जो ऐसी फ़ाइल में लिखता है जिसे कोई नहीं खोलता, ठीक वैसा ही दिखता है जैसा कभी शुरू ही न हुआ हो।

फिर एक बार रीबूट करें और पुष्टि करें कि टनल डिवाइस दिखने के बाद यूनिट सक्रिय है। केवल systemctl start से सत्यापित सुधार ने उस बूट क्रम की परीक्षा नहीं की जिसे ठीक करना था।