RRAS बूट पर OpenVPN टनल तैयार होने से पहले शुरू हो जाता है

सर्वर रीबूट होता है, 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 ने अंत में उसे कब स्वीकार किया। वही एक पंक्ति अगले इंजीनियर के सवाल का जवाब देती है, और इसे बनाने में लगभग कुछ भी खर्च नहीं होता। इसके बिना अगली जाँच इसी अनुमान से शुरू होती है।

निश्चित संख्या के प्रयासों के बाद ऑटोमेशन रोकें और अनंत पुनः प्रयास के बजाय विफलता बताएं। «संसाधन कभी प्रकट नहीं हुआ» जैसे स्पष्ट संदेश के साथ समाप्त होने वाला बूट अंधेरे में सेवा रीस्टार्ट करते रहने वाले बूट से अधिक मूल्यवान है। जब वह संदेश आएगा, दूसरे खंड में आपने जो संसाधन का नाम लिखा था, अगला व्यक्ति उसी को खोजेगा।