OpenVPN: बूट पर स्थानीय बाइंड विफल — प्रतीक्षा या पुनः प्रयास

बूट पर शुरू न होने वाले OpenVPN सर्वर के लिए दो समाधान सुझाए जाते हैं: पते की प्रतीक्षा करें, या सेवा को तब तक पुनः प्रयास करने दें जब तक बाइंड सफल न हो। दोनों एक ही लक्षण को अलग विफलता-व्यवहार के साथ संबोधित करते हैं। प्रतीक्षा एक विशिष्ट पूर्वापेक्षा को कूटबद्ध करती है और उसके अभाव में ज़ोर से विफल होती है; पुनः प्रयास पूर्वापेक्षा को छिपाता है और प्रयास करता रहता है। आपकी यूनिट में कौन-सा जाएगा, यह इस पर निर्भर है कि वह पता डिज़ाइन की गई निर्भरता है या समय का संयोग।

दोनों एक निश्चित स्लीप से बेहतर हैं, जो न किसी चीज़ की प्रतीक्षा करती है और न बताती है कि किसकी प्रतीक्षा कर रही थी।

local विकल्प वास्तव में क्या मांगता है

local उस पते का नाम देता है जिस पर डेमन अपना सॉकेट बाइंड करता है, और ऐसे पते पर बाइंड करना जो अभी मौजूद नहीं है, अनुरोधित पते के बारे में त्रुटि के साथ तुरंत विफल हो जाता है। जब विकल्प अनुपस्थित होता है, तो डेमन सभी पतों पर सुनता है, इसीलिए वही प्रोफ़ाइल ऐसी मशीन पर काम करती है जिसका इंटरफ़ेस अभी ऊपर नहीं आया: यह आपके बताए एक पते के बजाय हर जगह सुन रहा है। यही अंतर पूरी विफलता है, और रीबूट तक यह अदृश्य रहता है।

आवश्यकता यह नहीं है कि इंटरफ़ेस किसी सामान्य अर्थ में ऊपर हो। बाइंड के क्षण में पता सही इंटरफ़ेस को सौंपा होना चाहिए, और वह अंतर्निहित इंटरफ़ेस होना चाहिए, न कि कोई टनल जिसे वही डेमन बाद में बनाएगा। लॉगिन के कुछ मिनट बाद किया गया कोई जाँच बूट-क्रम के बारे में कुछ सिद्ध नहीं करता।

पते की प्रतीक्षा बनाम बाइंड का पुनः प्रयास

प्रतीक्षा का अर्थ है एक ExecStartPre जो पता दिखने तक पूछताछ करता है, सीमित प्रयासों और समय खत्म होने पर गैर-शून्य निकास के साथ। पुनः प्रयास का अर्थ है मुख्य प्रक्रिया को विफल होने देना और सेवा प्रबंधक से उसे फिर से शुरू करने के लिए कहना, उदाहरण के लिए Restart=on-failure के साथ RestartSec=5। पहला अनुपस्थित पूर्वापेक्षा को विफल यूनिट के रूप में बताता है, जबकि दूसरा उसे रीस्टार्ट की श्रृंखला के रूप में बताता है जो अंततः रुक जाती है; यह जर्नल में अधिक शोर करता है पर ऐसे पते को सह लेता है जो आपके अनुमान से बाहर के कारणों से देर से आता है।

जब पता डिज़ाइन की गई निर्भरता हो तो प्रतीक्षा को प्राथमिकता दें, और जब पता सामान्यतः प्रकट होता हो पर उसका समय बदलता हो तो पुनः प्रयास को। दोनों को मिलाना उचित है: सीमित प्रतीक्षा सामान्य स्थिति को कवर करती है और रीस्टार्ट नीति अपवाद को। न तो अनंत काल तक चलना चाहिए, क्योंकि अनिश्चित काल तक पुनः प्रयास करने वाली यूनिट गलत कॉन्फ़िगरेशन को बताने के बजाय छिपा देती है।

network-online.target पर्याप्त क्यों नहीं है

network-online.target वह वादा करता है जो सक्रिय नेटवर्क कार्यान्वयन online से समझता है, और उससे अधिक कुछ नहीं। systemd-networkd के साथ, systemd-networkd-wait-online तय करता है कि वह लक्ष्य कब प्राप्त होता है, और इसकी डिफ़ॉल्ट online धारणा आपके विशिष्ट पते के अस्तित्व में आने से पहले ही संतुष्ट हो सकती है। NetworkManager के अधीन, wait-online सेवा अपने नियम लागू करती है। लक्ष्य के बाद क्रमबद्ध करना एक ठोस आधार-रेखा है, यह गारंटी नहीं कि कोई एक पता, DNS उत्तर या दूरस्थ साथी तैयार है।

वही तर्क सामान्य विकल्पों को बाहर करता है। डेस्कटॉप ऑटोस्टार्ट प्रविष्टि ऐसे उपयोगकर्ता सत्र की प्रतीक्षा करती है जो सर्वर पर कभी न खुले, और विलंबित cron कमांड उस संसाधन का नाम लिए बिना बीता समय जोड़ देता है जिसके प्रकट होने की उसे आशा थी। दोनों महीनों तक सफल दिख सकते हैं और फिर उस एक बूट पर विफल हो सकते हैं जो मायने रखता है।

कोल्ड बूट के बाद बाइंडिंग जाँचें

सेवा रीस्टार्ट के बजाय वास्तविक कोल्ड बूट से सत्यापित करें, क्योंकि रीस्टार्ट उस पते को विरासत में लेता है जिसे बूट-क्रम को बनाना था। बूट के बाद ss -lntp या ss -lunp दिखाता है कि प्रत्येक श्रोता ने वास्तव में किस स्थानीय पते पर बाइंड किया, और journalctl -b -u openvpn-server@server दिखाता है कि पहला प्रयास विफल हुआ या नहीं। बाइंड किए गए पते की तुलना प्रोफ़ाइल वाले से करें, फिर नेटवर्क पुनः कनेक्ट होने के बाद तुलना दोहराएँ।

यदि प्रोफ़ाइल को कभी निश्चित पते की आवश्यकता नहीं थी, तो local हटाना वैध सरलीकरण है, पर इसे ट्रबलशूटिंग की आदत के बजाय सुरक्षा निर्णय बनाएँ।

श्रोता को चौड़ा करने से बदलता है कि कौन उस तक पहुँच सकता है, इसलिए उस बदलाव को उस फ़ायरवॉल नीति के साथ जोड़ें जिसे उसे सीमित करना चाहिए था। जो सेवा हर इंटरफ़ेस पर भरोसेमंद ढंग से शुरू होती है, उसने मूल समस्या हल नहीं की; उसने समस्या को नेटवर्क के किनारे पर स्थानांतरित कर दिया है।