बूट होताना OpenVPN टनेल तयार होण्यापूर्वी RRAS सुरू होते

सर्व्हर पुन्हा बूट होतो, OpenVPN सुरू होते, आणि RRAS ज्या अॅडॉप्टर किंवा मार्गावर अवलंबून आहे ते अजून नसतानाच वर येते। एका मिनिटानंतर RRAS हाताने पुन्हा सुरू केल्यास ते ठीक होते, ज्यामुळे समस्या सुटल्यासारखी दिसते आणि खरी समस्या लपते। येथे दोन वेगळ्या अटी गोंधळल्या जातात: पूर्वअट सेवा चालू आहे, आणि RRAS ला खरोखर आवश्यक असलेले नेटवर्क संसाधन वापरण्यायोग्य झाले आहे। Windows सेवा अवलंबन पहिली अट व्यक्त करू शकते आणि दुसरी कधीही नाही, म्हणून संसाधन परिभाषित न करता अवलंबन जोडल्यास अधिक नीटनेटके दिसणारे बूट आणि तोच अपयश मिळते।

थंड बूटवर लक्षण कसे दिसते

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

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

«पुन्हा सुरू केल्यावर चालते» या आधारावर जोडलेले अवलंबन तेच अपयश फक्त पूर्वअट सेवेला RUNNING नोंदवण्यासाठी लागणाऱ्या वेळेइतकेच पुढे ढकलते। ते बूट समजणेही कठीण करते, कारण क्रमाची अट आता स्पष्टीकरणासारखी दिसते। अवलंबन कोणत्या वस्तूची हमी देते आणि ती वस्तूच RRAS पाहू न शकलेली आहे का, असे विचारा।

संसाधनाचे नाव द्या, फक्त सेवेचे नाही

गहाळ असलेली ठोस गोष्ट लिहा। ती पत्त्यासह टनेल अॅडॉप्टर, पीअर सबनेटचा मार्ग, DNS उत्तर, किंवा अजून पुरवले जात असलेले प्रमाणपत्र असू शकते। «VPN सेवा चालू आहे» हे संसाधनाचे वर्णन नाही, आणि क्लायंटमधील हिरवे चिन्हही नाही। वस्तू आणि ती दाखवणारी आज्ञा नावाने सांगू शकत नाही तोपर्यंत, तुम्ही ज्या अटीची वाट पाहू इच्छिता ती परिभाषित केलेली नाही।

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

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

जोडण्यापूर्वी अवलंबन साखळी वाचा

Service Control Manager START_PENDING आणि RUNNING सारख्या स्थिती नोंदवते, आणि SERVICE_STATUS reference प्रत्येक फील्डचा अर्थ नेमका परिभाषित करते। या स्थितींपैकी कोणतीही पीअर, DNS नाव किंवा खालचे अनुप्रयोग पोहोचण्यायोग्य आहेत असे वचन देत नाही। हीच तफावत या अपयशाला योग्यरीत्या संरचित अवलंबनातूनही टिकून राहण्याचे संपूर्ण कारण आहे।

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

sc.exe qc मधील DEPENDENCIES ओळ ही तुम्ही जतन करावयाची यादी आहे, कारण sc.exe config RemoteAccess depend= संपूर्ण यादी बदलते, त्यात भर घालत नाही। VPN सेवा जोडताना असंबंधित पूर्वअट वगळल्यास दुसऱ्या बूटवर दिसणारी दुसरी बिघाड तयार होते, आणि तिचे निदान मूळपेक्षा खूप कठीण असते। तिला हात लावण्यापूर्वी सध्याची यादी तुमच्या बदल-नोंदीत कॉपी करा।

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

पुन्हा सुरू करणे टाइमरवर नाही, अटीवर अवलंबून ठेवा

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

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

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

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

संक्रमण लॉग करा जेणेकरून पुढील बूट स्वतःच स्पष्ट होईल

एकाच ओळीत तीन वेळमुद्रा नोंदवा: अवलंबन सेवा RUNNING ला कधी पोहोचली, आवश्यक संसाधन कधी प्रकट झाले, आणि RRAS ने शेवटी ते कधी स्वीकारले। तीच एक ओळ पुढील अभियंता विचारेल त्या प्रश्नाचे उत्तर देते, आणि ती तयार करण्यास जवळपास काहीही खर्च होत नाही। ती नसल्यास पुढील तपास या तपासाच्याच अंदाजापासून सुरू होते।

ठरलेल्या प्रयत्नांनंतर ऑटोमेशन थांबवा आणि अनंत पुनःप्रयत्नाऐवजी अपयश नोंदवा। «संसाधन कधीच प्रकट झाले नाही» अशा स्पष्ट संदेशाने संपणारा बूट अंधारात सेवा पुन्हा सुरू करत राहणाऱ्या बूटपेक्षा अधिक मूल्यवान आहे। तो संदेश आल्यावर, दुसऱ्या विभागात तुम्ही लिहिलेले संसाधनाचे नावच पुढील व्यक्ती शोधेल।