OpenVPN चा up स्क्रिप्ट खूप लवकर चालला, की तो कधीच तयार नव्हता?

up स्क्रिप्ट चालते, शून्याने बाहेर पडते, आणि तिच्यातील कार्य टर्मिनलवरून दोन सेकंदांनंतर उत्तम प्रकारे चालणाऱ्या खाजगी सेवेपर्यंत पोहोचू शकत नाही. सहजवृत्ती वेळेचा विचार करते, आणि नेहमीचा उपाय स्लीप आहे, जो शर्यत न समजता ती लपवतो. अधिक उपयुक्त वाचन असे आहे की “up” हे हुकचे नाव आहे, तयारीची हमी नाही. टनेल उपकरण संरचित झाल्यावर तो चालू होतो, आणि ते मार्ग, DNS आणि टनेलच्या मागील कोणत्याही अनुप्रयोगापेक्षा लवकर असते.

शेल चाचणी यशस्वी झाली कारण ती सर्व काही स्थिर झाल्यानंतर चालली. हुक एका विशिष्ट क्षणी चालला.

सुरुवातीच्या क्रमात up कुठे आहे

OpenVPN टनेल उपकरण संरचित करते आणि नंतर up हुक चालवते. मार्ग स्थापित करणे हा नंतरचा टप्पा आहे आणि त्याचा स्वतःचा हुक आहे, म्हणून up मध्ये ठेवलेले मार्ग-अवलंबून कार्य उपयुक्त मार्ग नसलेले उपकरण पाहू शकते. मार्गाचे काम route-up मध्ये ठेवा आणि वेळेची समस्या सहसा नाहीशी होते.

पुस्तिका हा क्रम आणि प्रत्येक हुकला मिळणारे वातावरण नोंदवते. हा क्रम “माझ्या शेलमधून चालते” या पारंपरिक अहवालाचे संपूर्ण स्पष्टीकरण आहे, आणि तोच स्क्रिप्ट एका मशीनवर उत्तीर्ण होऊन मंद मार्ग टप्पा असलेल्या दुसऱ्या मशीनवर अपयशी होण्याचे कारण आहे. दोन्हीपैकी कोणताही निकाल स्क्रिप्टच्या गुणवत्तेबद्दल काही सांगत नाही.

DNS आणि अनुप्रयोगाची तयारी आणखी उशिरा येते. स्थापित मार्गही दूरचा एंडपॉइंट ऐकत आहे, नाव सोडवले जात आहे, किंवा वापरकर्ता-व्याप्तीच्या कार्यासाठी डेस्कटॉप सत्र अस्तित्वात आहे याचा पुरावा नाहीत.

हुक प्रत्यक्षात काय वारसा घेतो

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

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

हुकमध्ये कार्य अयशस्वी झाल्यावर खाते, वातावरण आणि अयशस्वी झालेली पहिली क्रिया नोंदवा. यामुळे अकाली वेळ आणि परवानगी किंवा संदर्भाची समस्या वेगळी होते, आणि दोन्हींची दुरुस्ती पूर्णपणे वेगळी आहे. त्यांच्यात अंदाज लावणे म्हणजे पाच मिनिटांची दुरुस्ती संपूर्ण दुपार होणे.

स्लीप जोडणे हे तयारीची तपासणी का नाही

स्लीप स्क्रिप्ट उशिरा करते आणि शर्यतीची खिडकी हलवते. वेगवान दिवशी कार्य यशस्वी होते; संथ दिवशी ते पुन्हा अयशस्वी होते, आणि उशीर चालत असल्यासारखे दिसत असल्याने अपयश पुन्हा निर्माण करणे कठीण होते. केवळ हलक्या भाराखाली चालणारा उशीर हा योगायोग आहे, दुरुस्ती नाही.

अवलंबन मार्ग असल्यास, मार्ग स्थापनेशी जुळणारा हुक वापरा. अवलंबन टनेलच्या मागील सेवा असल्यास, ती विशिष्ट अट वाट पाहणारी आणि ती कधीच न आल्यास स्पष्टपणे अयशस्वी होणारी मर्यादित तपासणी वापरा.

अपयश स्पष्ट ठेवा. प्रत्यक्ष काम अयशस्वी झाले तरी शून्याने बाहेर पडणारा हुक अयशस्वी होणाऱ्या हुकपेक्षा वाईट आहे, कारण सेवा व्यवस्थापक यश नोंदवतो आणि पुन्हा कोणी पाहत नाही. स्क्रिप्टमधूनच येणारी एक लॉग ओळ हे प्रामाणिक ठेवण्याचा सर्वात स्वस्त मार्ग आहे.

स्वच्छता आणि पुन्हा कनेक्ट होणे यांनाही तितकीच काळजी हवी

सामायिक स्थिती बदलणाऱ्या स्क्रिप्टला जुळणारा पूर्वस्थिती मार्ग हवा. हुकने जोडलेले मार्ग, रिझोल्व्हर नोंदी आणि फायरवॉल खुणा इडेंपोटेंट आणि परत करण्यायोग्य असाव्यात, अन्यथा पुन्हा कनेक्ट होणे दुसरी प्रत पहिल्यावर चढवेल.

पुन्हा कनेक्ट होणे सेवेच्या पूर्ण सुरुवातीपेक्षा जास्त वेळा हुक चालवू शकते. सत्र पुन्हा प्रस्थापित करणारा स्थायी इंटरफेस up आणि route-up चक्र पुन्हा सुरू करू शकतो, म्हणून प्रत्येक बूटला एकच अंमलबजावणी गृहीत धरणारी स्क्रिप्ट शेवटी चुकीचे वागेल. एका दिवसाच्या डळमळीच्या लॉगमधील अंमलबजावणी मोजा आणि ती प्रत्यक्षात किती वेळा चालते ते पाहा. नंतर स्क्रिप्ट तितक्या वेळा चालवण्यास सुरक्षित करा.

अयशस्वी झालेले जीवनचक्र तपासा, नंतरची आज्ञा नाही. बूट किंवा पुन्हा कनेक्ट होणे पुन्हा निर्माण करा, हुक चालताना पाहा, आणि ते प्रत्यक्षात चालते त्या क्षणी कार्य यशस्वी झाले याची पुष्टी करा. नंतर संवादात्मक शेलमधून मिळणारे यश हे अवलंबनाबद्दलचा पुरावा आहे, सुरुवातीचा मार्ग चालतो याचा पुरावा नाही.

प्रत्येक कार्य ज्या घटनेवर अवलंबून आहे तिला नाव द्या, नंतर ते त्या घटनेशी जोडा. बाकी सर्व तपासणीचे नाटक करणारा उशीर आहे.