OpenVPN active (exited) म्हणतो? तुम्ही सुरू केलेला इन्स्टन्स शोधा

तुम्ही टनल तपासता, systemctl status openvpn चालवता आणि Main PID नसलेले व रिकाम्या प्रोसेस यादीसह active (exited) मिळते। सेवा सुरू झाली आणि मेली हे साहजिक वाचन आहे, म्हणून तुम्ही unit उघडता, /bin/true सापडते आणि पॅकेज तुटलेले आहे असा निष्कर्ष काढता। Debian पॅकेजिंगमध्ये ती अवस्था रचनेनुसार काम करणारा wrapper आहे, आणि टनल तो सुरू करत असलेल्या instance unit पैकी एकात राहते। एकत्रित unit कोणत्या इन्स्टन्सने ते बांधले हे कधीच सांगणार नाही।

या unit वर active (exited) चा खरा अर्थ काय

पॅकेज केलेला unit एकदाचे काम आहे: त्याचे ExecStart /bin/true आहे, आणि पूर्ण झालेला unit active (exited) म्हणून नोंदवला जात राहण्याचे कारण RemainAfterExit=yes आहे। तो निर्देश काढला तर तेच यशस्वी /bin/true काम inactive (dead) मध्ये संपते, जी नेमकी लोक अपेक्षित असलेली आणि विरुद्ध दिशेने चुकीची वाचलेली अवस्था आहे। आदेश फक्त जागा भरणारा आहे, आणि unit इतर unit करत असलेल्या कामाचा अहवाल देते। या रचनेत काहीही तुटलेले नाही, आणि /bin/true बदलणे टनल नाही तर पॅकेजिंग करार बदलते।

wrapper प्रतिनिधित्व करतो। पॅकेज संरचना किंवा तिचा systemd जनरेटर पुरवत असलेले instance unit सुरू करतो, म्हणून रिकामी प्रोसेस यादी टनलबद्दल काहीही सिद्ध करत नाही। कोणताही इन्स्टन्स निवडला नसला तरी wrapper यशस्वी होतो आणि तरीही काहीही सुरू करत नाही। अवस्था wrapper चालला का याचे उत्तर देते, टनल आहे का याचे नाही।

कंसातील शब्दाऐवजी status आउटपुटच्या तीन ओळी वाचा। Loaded systemd ने वाचलेल्या unit फाइलचे नाव सांगते, Active शेवटच्या यशस्वी फेरीची वेळमुद्रा धारण करते, आणि Main PID नसणे पूर्ण झालेल्या एकदाच्या कामाशी जुळते। या तीन ओळी या wrapper ला सुरू झाल्यानंतर एका सेकंदात पडलेल्या सेवेपासून वेगळे ओळखण्याचा मार्गही आहेत।

status पुन्हा वाचण्यापूर्वी unit ची यादी करा

काय चालू आहे हे विचारण्यापूर्वी systemd ला काय आहे ते विचारा। कोणताही इन्स्टन्स न बनवता टेम्पलेट स्थापित असू शकते, आणि फक्त बनवलेला unit टनल धारण करतो। लोड झालेल्या संचापासून सुरुवात करा:

systemctl list-units 'openvpn*'

ती यादी systemd ने या क्षणी लोड केलेले आहे, आणि ती टनलच्या यादीच्या सर्वात जवळ आहे। स्थापित unit फाइल्स दुसऱ्या प्रश्नाचे उत्तर देतात, आणि काहीही बनवले नसतानाही ती यादी टेम्पलेट दाखवते:

systemctl list-unit-files 'openvpn*'

दोन्ही याद्या एकत्र वाचा, कारण दुसऱ्यातील टेम्पलेट आणि पहिल्यातील इन्स्टन्स दोन वेगळी उत्तरे आहेत। असलेले टेम्पलेट आणि चालू असलेला इन्स्टन्स एकच तथ्य नाही, आणि फक्त दुसरेच टनल अर्थ देतो। पॅकेज मांडणी वितरणे आणि OpenVPN आवृत्त्यांमध्येही बदलते। जुने openvpn@ टेम्पलेट, वेगळी client आणि server जोडी, आणि वितरण wrapper हे सर्व त्यांच्या पॅकेजिंगमध्ये वैध असू शकतात।

तुम्हाला मिळालेल्या ट्युटोरियलनुसार नाही, तुमच्या मशीननुसार जुळवून घ्या। दुसऱ्याच्या आउटपुटमधील इन्स्टन्सचे नाव office असू शकते तर तुमचे home किंवा work। हस्तांतरित होते ती पद्धत, स्ट्रिंग नाही।

इन्स्टन्सच्या नावापासून तो वाचत असलेल्या फाइलपर्यंत जा

upstream client टेम्पलेटमध्ये unit ची कार्य डिरेक्टरी /etc/openvpn/client आहे आणि त्याचा आदेश तिथून %i.conf घेतो, म्हणून openvpn-client@office /etc/openvpn/client/office.conf वाचतो। उदाहरणावर विश्वास ठेवण्याऐवजी स्थापित unit वर ते मॅपिंग तपासा, कारण तुमचे टेम्पलेट जुने किंवा वितरणाने पुन्हा लिहिलेले असू शकते:

systemctl cat [email protected]

त्या आउटपुटच्या तळाशी दिसणाऱ्या drop-in वाचा, कारण .d/ खालील फाइल ExecStart, कार्य डिरेक्टरी किंवा संरचना मार्ग बदलू शकते। तुम्ही office.ovpn म्हणून डाउनलोड केलेली प्रोफाइल इन्स्टन्स उघडत असलेली फाइल नाही। ही तफावत म्हणजे तुम्ही कधीच संपादित न केलेला मार्ग त्रुटी नावाने सांगण्याचे नेहमीचे कारण।

प्रोफाइलमधील सापेक्ष मार्ग हा पुढचा सापळा आहे। ca, cert आणि key संदर्भ सापेक्ष ठेवून मुख्य फाइल हलवल्यास गहाळ-फाइल त्रुटीची जागा दुसऱ्या गहाळ-फाइल त्रुटीने घेतली जाते। दुसरी ती फाइल दाखवते जी आहे याची तुम्हाला खात्री होती, म्हणून फाइल नावापेक्षा प्रोफाइल डिरेक्टरी महत्त्वाची आहे।

ते सुरू करा, नंतर त्या इन्स्टन्सचा जर्नल वाचा

तुम्ही नुकतेच तपासलेला इन्स्टन्स सुरू करा, कारण एकत्रित unit च्या लॉगमध्ये टनलच्या त्रुटी नसतील। नंतर या बूटचा जर्नल वाचा आणि त्याच क्रमाने संरचना त्रुटी, फाइल-प्रवेश त्रुटी आणि कनेक्शन त्रुटी शोधा, कारण प्रत्येकजण सुरुवातीच्या वेगळ्या टप्प्यावर अयशस्वी होते।

sudo systemctl start [email protected]
journalctl -u [email protected] -b

सुरू करणे आणि सक्षम करणे हे वेगळे निर्णय आहेत: start unit आता चालवते, enable पुढच्या बूटची व्यवस्था करते, आणि enable --now दोन्ही एका पायरीत करते। daemon-reload unit व्याख्या पुन्हा वाचते आणि चालू प्रक्रिया पुन्हा सुरू करत नाही किंवा संपादित प्रोफाइल लागू करत नाही। प्रोफाइल बदलल्यानंतर इन्स्टन्स पुन्हा सुरू करा, कारण फाइल पुन्हा वाचणारे तेच आहे।

त्याच टनलवर दुसरा व्यवस्थापक ठेवू नका

NetworkManager आणि OpenVPN 3 सत्र व्यवस्थापकांची स्वतःची कनेक्शन अवस्था असते, आणि त्यांपैकी एकाच्या शेजारी systemd इन्स्टन्स ठेवल्यास त्याच टनलवर दोन मालक होतात। लक्षण म्हणजे टनल वर येते आणि काही सेकंदांनी बदलली जाते, किंवा थांबलेली राहण्यास नकार देते। तुमचे वितरण डेस्कटॉपसाठी ज्या व्यवस्थापकाचे दस्तऐवजीकरण करते तो निवडा, आणि सर्व्हरवर systemd जाणीवपूर्वक वापरा।

इन्स्टन्स सुरू करण्यापूर्वी विद्यमान मालक आहे का ते तपासा। डेस्कटॉप अॅपलेट कनेक्शन दाखवताना, तुम्ही सुरू केलेला इन्स्टन्स ते पूर्ण करण्याऐवजी त्याच्याशी स्पर्धा करतो। दोन्ही चालवून क्रम टिकेल अशी आशा ठेवण्याऐवजी न वापरता येणारा व्यवस्थापक बंद करा। तो संघर्ष त्या जर्नल्सचेही स्पष्टीकरण देतो जिथे टनल प्रस्थापित होते आणि नंतर तुम्ही कधीच सुरू न केलेल्या प्रक्रियेने ती तोडली जाते।

मूळ प्रश्नाचे उत्तर इन्स्टन्सचे नाव, त्याने वाचलेली फाइल आणि अयशस्वी झालेली जर्नल ओळ यांनी द्या। systemd एकत्रीकरणाबद्दल OpenVPN च्या नोंदी टेम्पलेट मांडणी आणि इन्स्टन्सचे नाव सोडवले जाणारे फाइल मॅपिंग वर्णन करतात।