नेटवर्क सुरू होण्यापूर्वी OpenVPN सुरू होणे हे अपयश नाही

तुम्ही बूटच्या वेळी क्लायंट सुरू करता, युनिट सक्रिय दाखवते, पण बोगदा तिथे नसतो। साहजिक निष्कर्ष असा निघतो की सेवा सुरू होण्यात अपयश आले, आणि साहजिक उपाय म्हणजे ती पुन्हा सुरू करणे। दोन्ही चुकीचे आहेत आणि तेवढ्या वेळा घडतात की त्यावर एक नियम बनवावा: पुन्हा प्रयत्न करणारा सुरू असलेला क्लायंट बाहेरून तंतोतंत बिघडलेल्या क्लायंटसारखा दिसतो। फरक प्रक्रिया काय करत आहे यात आहे, युनिटच्या स्थितीत नाही।

समजूत: सुरू झालेली सेवा म्हणजे कार्यरत बोगदा

सक्रिय युनिट हे सिद्ध करते की प्रक्रिया सुरू झाली आणि थांबली नाही। प्रोफाइल लोड झाले, प्रमाणपत्र स्वीकारले गेले किंवा पलीकडच्या टोकाने उत्तर दिले, हे ते सिद्ध करत नाही। पॅकेज केलेला क्लायंट मिनिटभर पुनःप्रयत्नाच्या फेर्यात बसू शकतो, तर systemd यशाखेरीज दुसरे काहीही कळवत नाही। स्थिती आणि वर्तन यातील हे अंतर हाच संपूर्ण विषय आहे।

उलट बाजूची गोष्टही तितकीच सामान्य आहे। की वाचता न आल्याने प्रक्रिया बाहेर पडली असेल, आणि मग युनिट अयशस्वी स्थिती दाखवते जी का ते सांगत नाही। दोन्ही स्थिती वेगळ्या करण्यासाठी लॉगची गरज असते।

युनिटच्या स्थितीऐवजी त्या इन्स्टन्सचा जर्नल वाचा। कारणाची ओळ लॉगमध्ये असते, स्थिती लेबलमध्ये नाही।

समजूत: पुनःप्रयत्न सेटिंग्ज प्रत्येक अपयश झाकतात

नाव रिझोल्यूशन आणि ट्रान्सपोर्ट पुनःप्रयत्न ही स्वतंत्र नियंत्रणे आहेत आणि त्यांचे स्वतंत्र डीफॉल्ट आहेत। resolv-retry रिमोट होस्टनावाच्या पुन्हा पुन्हा होणाऱ्या शोधांना नियंत्रित करते, आणि नोंदवलेले डीफॉल्ट अमर्यादपणे प्रयत्न चालू ठेवते। connect-retry प्रयत्नांमधील अंतर ठरवते, तर connect-retry-max प्रत्येक रिमोट नोंद किती वेळा प्रयत्न केली जाईल याला मर्यादा घालू शकते। यापैकी काहीही बदलण्यापूर्वी लॉग कोणता टप्पा सांगतो ते पहा।

यापैकी काहीही विकृत प्रोफाइल, वाचता न येणारी खाजगी की किंवा नाकारलेल्या खात्याला लागू होत नाही। त्यांना दुरुस्ती हवी असते, आणि त्यांना पुन्हा पुन्हा प्रयत्न करणारा क्लायंट पुढे सरकत नाही।

मंजूर न केलेल्या प्रमाणपत्रासाठी कायम प्रयत्न करणे हे पडताळणी काढून टाकण्याचे कारण नाही। ते त्रुटी वाचण्याचे कारण आहे।

समजूत: एक लाँचर पुरतो, म्हणून दुसरा जोडा

NetworkManager किंवा पॅकेज केलेल्या युनिटने आधीच व्यवस्थापित केलेल्या जोडणीला दुसरा लाँचर जोडण्याची गरज नाही। त्याच मार्गांसाठी स्पर्धा करणाऱ्या दोन प्रक्रिया दुहेरी इंटरफेस, गोंधळलेले लॉग आणि कोणालाही दिसू न देणाऱ्या कारणांनी वारंवार बंद-चालू होणारा बोगदा निर्माण करतात। पहिला हळू आहे यावर उपाय म्हणून दुसरी प्रत सहसा येते।

बोगदा कोणत्या घटकाच्या मालकीचा आहे ते ठरवा, काहीही जोडण्यापूर्वी। मग दुसरा लाँचर बंद करून आशा ठेवण्याऐवजी तो काढून टाका।

मालक कोण हे पुनःप्रयत्न आणि क्रेडेन्शियल कुठून येतात हेही ठरवते, म्हणूनच हा निर्णय काहीही ट्यून करण्यापूर्वी येतो। नेमक्या त्याच कारणाने मालकी आधी येते।

प्रत्यक्षात क्रम लावण्याची गरज कशाला आहे

क्रम लावणे कॉन्फिगर केलेल्या पत्त्यासाठी थांबू शकते, आणि ते एवढीच हमी देते। network-online.target व्यवस्थापकाला नेटवर्क वर आले असे वाटेपर्यंत सक्रियता उशिरा करते, आणि नेटवर्क वर आहे याची व्याख्या व्यवस्थापकावर ठरते। VPN होस्टनाव रिझॉल्व्ह होते का, लिसनर उत्तर देतो का, किंवा कॅप्टिव्ह पोर्टलने डिव्हाइसला प्रवेश दिला का, याबद्दल ते काहीही सांगत नाही।

डिपेंडन्सी जोडण्यापूर्वी इन्स्टॉल केलेले युनिट आणि कोणतेही ड्रॉप-इन वाचा। प्रत्येक नेटवर्क सेवेवर रुंद After= बूट उशिरा करते, पण तुम्हाला प्रत्यक्ष गरज असलेली जोडणी प्रस्थापित करत नाही।

ज्याची चाचणी करता येते त्या डिपेंडन्सीचा क्रम लावा, आणि बाकी सर्व तयारी-तपासणीने तपासा। बोगदा उघडणारी तपासणी अंदाज लावणाऱ्या टायमरपेक्षा चांगली असते।

बोगदा पहिल्यांदा वर आल्यानंतर काय होते

बूट ही अनेक घटनांपैकी एक घटना आहे। प्रवेश दुवा बदलतो, पोर्टल सत्र संपते, पीअर पुन्हा सुरू होतो। अंतर्गत पुन्हा-जोडणी आणि सेवा व्यवस्थापक हाताळणारा प्रक्रिया-निर्गम वेगळे ओळखा, कारण दोघांचे मालक वेगळे आणि पुरावे वेगळे असतात।

परस्परसंवादी प्रमाणीकरण लक्ष न देता होणारी पुनर्प्राप्ती मर्यादित करते। पार्श्वभूमी युनिट डेस्कटॉप कीरिंग उघडत नाही किंवा MFA विचारण्याला उत्तर देत नाही, म्हणून सेवा संदर्भासाठी मंजूर केलेली क्रेडेन्शियल व्यवस्था पाळा।

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