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 सँगै कमाण्ड फर्केपछि पनि युनिट सक्रिय रहन्छ, जुन कन्फिगर गर र बाहिरिन ढाँचासँग मिल्छ, र रोक्ने कमाण्डले सेवालाई सफा बन्द दिन्छ। फोर्क गर्ने क्लाइन्टले उही आकार राख्छ तर systemd ले सन्तानलाई पछ्याउन Type=forking चाहिन्छ। 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 ले जाँचिएको सुधारले सुधार्नुपर्ने बुट क्रम परीक्षण गरेको छैन।