बुट हुँदा 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 सेवा थप्दा असम्बन्धित पूर्वसर्त छोड्दा अर्को बुटमा देखिने दोस्रो दोष बन्छ, र त्यसको निदान मूलभन्दा धेरै गाह्रो हुन्छ। छुनुअघि विद्यमान सूची आफ्नो परिवर्तन-रेकर्डमा प्रतिलिपि गर्नुहोस्।

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

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