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 ने तपासलेली दुरुस्ती दुरुस्त करायच्या बूट क्रमाची चाचणी घेतलेली नाही।