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 हटाउनु वैध सरलीकरण हो, तर यसलाई ट्रबलसुटिङको बानी नभई सुरक्षा निर्णय बनाउनुहोस्।

श्रोतालाई फराकिलो बनाउँदा त्यहाँ कसले पुग्न सक्छ भन्ने बदलिन्छ, त्यसैले त्यो परिवर्तनलाई त्यसलाई सीमित गर्नुपर्ने फायरवाल नीतिसँग जोड्नुहोस्। प्रत्येक इन्टरफेसमा भरपर्दो रूपमा सुरु हुने सेवाले मूल समस्या समाधान गरेको छैन; यसले समस्यालाई नेटवर्कको किनारमा सारेको छ।