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 त्रुटिका रूपमा देखा पर्छ र हातले पुनः सुरु गर्दा हराउँछ।