OpenVPN शेलमध्ये चालते पण cron अंतर्गत अयशस्वी होते: कारण PATH आहे

तोच आदेश शेलमधून जोडतो आणि cron अंतर्गत मरतो, त्यामुळे टनेल किंवा प्रमाणपत्र दोषी आहे असा नैसर्गिक निष्कर्ष निघतो। ते मानण्यापूर्वी दोन्ही फेऱ्यांमध्ये काय सामायिक आहे ते पाहा: बाइनरी, कॉन्फिगरेशन आणि क्रेडेन्शियल्स सारखीच आहेत, आणि फक्त प्रक्रियेचे वातावरण बदलले आहे। जेव्हा कार्यक्रमच सापडत नाही, तेव्हा कितीही TLS डीबगिंग उपयोगी पडत नाही। दुरुस्ती सहसा एका पथात, कार्यरत डिरेक्टरीत आणि मूठभर वातावरण चलांमध्ये असते, VPN मध्ये नाही।

जे शेल चालते त्यात command -v openvpn उत्तर छापते, आणि ते बऱ्याचदा /usr/sbin/openvpn असते, म्हणजे अशी डिरेक्टरी जी cron आपल्या शोधमार्गात ठेवत नाही।

टनेल कधीच सुरू झाले नाही, त्यामुळे टनेल ही समस्या नाही

cron ने सुरू केलेल्या कामांना किमान वातावरण वारसाहक्काने मिळते, पारंपरिकपणे PATH=/usr/bin:/bin, आणि नियंत्रक टर्मिनल मिळत नाही। /usr/sbin किंवा /usr/local/sbin मध्ये स्थापित केलेली कोणतीही गोष्ट त्या यादीत सहज गैरहजर असते, आणि लॉगची ओळ TLS त्रुटीऐवजी openvpn: not found वाचते। Python चे subprocess वेगळ्या पद्धतीने अयशस्वी होते: ते इंटरप्रिटर प्रक्रियेचे वातावरण वारसाहक्काने घेते, जे cron पेक्षा समृद्ध असू शकते पण टिल्डा विस्तारण्यासाठी अजूनही शेल नाही। दोन्ही अपयश एकही पॅकेट यजमान सोडण्यापूर्वी घडतात।

त्यांना वेगळे ओळखण्याचा जलद मार्ग म्हणजे शेवटच्या ऐवजी पहिली त्रुटी वाचणे। गहाळ बाइनरी शेल किंवा Python अपवाद निर्माण करते, खराब कॉन्फिगरेशन OpenVPN चा वापर संदेश निर्माण करते, आणि खरा हँडशेक अपयश वेळ-छाप आणि समवयस्क पत्ते निर्माण करते। फक्त तिसरेच टनेलची समस्या आहे।

निरपेक्ष पथ आणि वितर्क याद्या शेल स्ट्रिंगवर मात करतात

निराकरण केलेला पथ स्पष्टपणे द्या आणि शेल पूर्णपणे वगळा। subprocess.run(["/usr/sbin/openvpn", "--config", config, "--verb", "4"], capture_output=True, text=True, timeout=90) तुम्हाला परतीचा कोड, stdout आणि stderr देतो, शेलला फाइलनाव अर्थ लावायला न सांगता। कॉन्फिगरेशनचा पथ os.environ["HOME"] किंवा pathlib.Path.home() वरून तयार करा, जेणेकरून टिल्डा कधीही विस्तारावा लागणार नाही। जेव्हा खरोखर शेल सिंटॅक्स हवा असेल, तेव्हा shlex.split वापरा, कारण .split() ने स्ट्रिंग विभागल्यास जागा असलेल्या कोणत्याही पथावर ती तुटते। stderr देखील वाचा, कारण OpenVPN आपली बहुतेक सुरुवातीची अपयशे तिथेच लिहिते।

हाच नियम cron लाही लागू होतो: कामाची ओळ लॉगिन शेल नाही, त्यामुळे काहीही तुमची प्रोफाइल लोड करत नाही आणि काहीही तुमची टोपणनावे ठरवत नाही।

crontab प्रत्यक्षात काय वारसाहक्काने घेते

crontab नोंदीला crontab जे वातावरण घोषित करते ते आणि काही वारसाहक्काने मिळालेली डीफॉल्ट मूल्ये मिळतात, म्हणून पथ पूर्ण लिहा किंवा ते करणाऱ्या स्क्रिप्टमध्ये कॉल गुंडाळा। फाइलच्या वरच्या बाजूला PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin सारखी ओळ नेहमीची प्रतिष्ठापन स्थळे व्यापते, आणि >> cron.log 2>&1 ने पुनर्निर्देशन करणे हेच पुढील अपयश वाचनीय करते। पासफ्रेजने संरक्षित प्रोफाइलला cron अंतर्गत आपले रहस्य मागण्याचा मार्ग नाही, कारण विचारायला टर्मिनल नाही। असे जोडणी क्रेडेन्शियल फाइल वाचू शकणाऱ्या systemd युनिटमध्ये असावी, स्वतःला परस्परसंवादी दाखवणाऱ्या कामात नाही।

सापेक्ष पथ हा दुसरा सापळा आहे। चाचणीची फेरी बऱ्याचदा प्रोफाइल असलेल्या फोल्डरमधून होते, आणि cron काम पूर्णपणे दुसरीकडे सुरू होते, त्यामुळे --config office.ovpn तिथे नसलेल्या फाइलमध्ये निराकरण होते आणि संदेश गहाळ टनेलऐवजी गहाळ फाइल म्हणून वाचला जातो।

वातावरण सोलून ते सिद्ध करा

किमान वातावरण थेट पुन्हा निर्माण करा: env -i PATH=/usr/bin:/bin /usr/sbin/openvpn --config office.ovpn --verb 4। त्या फेरीतून पथ किंवा टर्मिनलबद्दल तक्रार आली तर समस्या VPN च्या वर आहे। जर ते जोडले तर उरलेले संशयित म्हणजे ज्या खात्याखाली ते चालते ते, ज्या डिरेक्टरीत ते सुरू होते ती, आणि जे क्रेडेन्शियल ते सादर करते ते। दोन्हीपैकी कोणताही निकाल प्रमाणपत्र तपासणीच्या अजून एका फेरीपेक्षा बरा आहे।

मग रॅपरला स्वतःहून अहवाल देणारे करा। ज्या टप्प्यापर्यंत ते पोहोचले त्यासाठी वेगळ्या स्थितीसह बाहेर पडा, दोन्ही प्रवाह वेळ-छापेसह नोंदवा, आणि पुढील अपयश तुम्हाला सांगेल की ते पथ निराकरणात, प्रमाणीकरणात, की टनेल आधीच वर असताना मरण पावले।

युनिटला योग्य क्रमही हवा: Wants=network-online.target सोबत After=network-online.target क्लायंटला पत्ता किंवा डीफॉल्ट मार्ग तयार होण्यापूर्वी सुरू होण्यापासून रोखतात, जे अन्यथा प्रमाणपत्र किंवा TLS त्रुटी म्हणून दिसते आणि हाताने पुन्हा सुरू केल्यावर नाहीशी होते।