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 काढणे हे वैध सरलीकरण आहे, पण ते ट्रबलशूटिंगची सवय नाही तर सुरक्षा निर्णय करा.

श्रोता रुंदावल्याने त्याच्यापर्यंत कोण पोहोचू शकते ते बदलते, म्हणून तो बदल ते मर्यादित ठेवायला हवे होते त्या फायरवॉल धोरणासोबत जोडा. प्रत्येक इंटरफेसवर विश्वासार्हपणे सुरू होणाऱ्या सेवेने मूळ समस्या सोडवली नाही; तिने समस्या नेटवर्कच्या काठावर हलवली आहे.