Windows ले आफ्नो VPN क्लाइन्टका लागि पुनः डायल गर्ने कुनै नीति दिँदैन, त्यसैले मध्यरातमा टुट्ने जडान बिहानको खाजासम्म पनि बन्द रहन्छ। विच्छेदन हेर्ने र rasdial चलाउने तालिकाबद्ध कार्यले तेस्रो-पक्ष क्लाइन्टबिना त्यो खाली ठाउँ भर्छ। कार्य अपरेटरजस्तो व्यवहार गर्छ कि लूपजस्तो, त्यो तीन विवरणमा निर्भर गर्छ: यसले कुन घटनासँग मिलाउँछ, कुन प्रमाणहरू देख्न सक्छ, र नतिजासँग के गर्छ। तीनमध्ये कुनै पनि गाह्रो छैन, र यीमध्ये कुनै एक छुट्नु नै सधैं डायल गर्ने कार्य बनाउने कुरा हो।

टाइमर किन गलत ट्रिगर हो

टाइमर सुरुङ बन्द होस् वा नहोस्, आफ्नै तालिकाअनुसार डायल गर्छ। यसले कसैलाई पनि नचाहिने प्रयासहरू बनाउँछ, र कामको सत्रका बेला गरिएको प्रयासले त्यसलाई बाधा पुर्याउन सक्छ। घटना ट्रिगर जडानको अवस्था बदलिँदा मात्र सक्रिय हुन्छ, जुन सस्तो र बुझ्न सजिलो छ। घटनाले कारण पनि बोक्छ, र कारणले नै नेटवर्क विफलतालाई जानाजान विच्छेद गर्ने व्यक्तिबाट अलग गर्छ।

त्यो भिन्नता नै उपयोगी कार्य र हरेक साँझ प्रयोगकर्तासँग लड्ने कार्यबीचको भिन्नता हो। यो केवल कार्यको वर्णन गर्ने विधिहरूमा सामान्यतया हराउने भाग पनि हो।

घटनाहरूको जोडी, र दबाउनुपर्ने एउटा

Remote Access Service क्लाइन्टले जीवनचक्रका रेकर्डहरू RasClient प्रदायकअन्तर्गत Application लगमा लेख्छ। 20226 ले सकिएको जडान र 20227 ले असफल प्रयास चिन्ह लगाउँछ, त्यसैले दुवैमध्ये कुनैले नयाँ डायललाई न्यायोचित ठहराउन सक्छ। कार्यमा बाँकी सबै कुरा यी दुई पहिचानकर्ताहरू ठ्याक्कै मिलाउनमा निर्भर छ। ती वर्षौंदेखि स्थिर छन्, त्यसैले तिनमा बनेका विधिहरू अझै चल्तीमा छन्, तर प्रदायक वा पहिचानकर्ताको नाम बदल्ने निर्माणले क्वेरीलाई केही पनि फर्काउन नदिने बनाउँछ। हरेक सुविधा अद्यावधिकपछि प्रमाणको चरण फेरि चलाउनुहोस्, कार्य सक्रिय हुन छोड्ने प्रतीक्षा गर्नुको सट्टा।

एउटा अन्त्य बहिष्कृत गर्नुपर्छ। त्रुटि 631 भन्नाले प्रयोगकर्ताले पोर्ट विच्छेद गरेको हो, र त्यो क्षणमा पुनः डायल गर्नु भर्खरै जानाजान नेटवर्क बदलेको व्यक्तिसँग लड्नु हो। बहिष्करण स्क्रिप्टमा नभई ट्रिगर फिल्टरमा राख्नुहोस्, ताकि कार्य बिल्कुल सुरु नहोस्। यो एउटा घटना आईडीमा मात्र लागू हुनुपर्छ, किनकि EventData विधेय नाम दिइएको तत्व अवस्थित भएमा मात्र मिल्छ, र साझा खण्डले अर्को आईडीको हरेक घटना चुपचाप छोडिदिन्थ्यो। फिल्टर लेख्नुअघि वास्तविक रेकर्डबाट तत्वको नाम पढ्नुहोस्:

Get-WinEvent -LogName Application -MaxEvents 5 -FilterXPath "*[System[Provider[@Name='RasClient'] and EventID=20226]]" | Select-Object -First 1 -ExpandProperty ToXml

XML ले त्यो रेकर्डमा Data का ठ्याक्कै नामहरू देखाउँछ। ErrorCode सामान्य हिज्जे हो, र अरू केही प्रयोग गर्ने रेकर्डले तलको फिल्टरमा त्यो नाम बदल्नुपर्छ।

<QueryList><Query Id="0" Path="Application"><Select Path="Application">*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])</Select></Query></QueryList>

त्यसलाई ट्रिगरको अनुकूलन फिल्टरमा टाँस्नुहोस्, र ट्रिगर बन्नुअघि क्वेरीका रूपमा प्रमाणित गर्नुहोस्। त्यही XPath PowerShellबाट जीवित लगविरुद्ध चल्छ, जुन कार्य इतिहास अझै संलग्न नहुँदा यो केसँग मिल्छ हेर्ने सस्तो तरिका हो।

Get-WinEvent -LogName Application -MaxEvents 40 -FilterXPath "*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])" | Select-Object TimeCreated,Id,Message

चुपचाप केहीसँग नमिल्ने ट्रिगर चल्ने र असफल हुने कार्यजस्तै देखिन्छ। दुवै "स्वचालन काम गर्दैन" भनेर देखिन्छन्, र कुनैले पनि कुन आधा भाग छुटेको छ भन्दैन। पहिले क्वेरीको आउटपुट जाँच्नुहोस्, किनकि यसले दुई अवस्था एकै चरणमा अलग गर्छ।

पासवर्ड टाइप गर्न कोही नभएकाले डायल असफल हुन्छ

कार्यले जडानको नामसँग rasdial चलाउँछ। प्रोफाइलमा क्यास गरिएका प्रमाणहरू नभएमा, सङ्केतको जवाफ दिन कोही नभएकाले डायल तुरुन्तै असफल हुन्छ। ठीकसँग ट्रिगर भएको कार्यले देखिने केही पनि नगर्नुको सबैभन्दा सामान्य कारण यही हो, त्यसैले ट्रिगर छुनुअघि यो जाँच्नुहोस्। कमाण्ड प्रम्प्टबाट हातले डायल गर्नु प्रमाणको समस्यालाई तालिकाको समस्याबाट अलग गर्छ।

प्रमाणहरू कार्य चल्ने खाताअन्तर्गत एकचोटि सुरक्षित गर्नुहोस्, र त्यो खातालाई डिजाइनको भाग बनाउनुहोस्। SYSTEM का रूपमा चल्ने कार्यले तपाईंको अन्तरक्रियात्मक खाताले क्यास गरेका प्रमाणहरू पढ्न सक्दैन, र अरू कसैका रूपमा चल्ने कार्यले पनि सक्दैन। नाम पनि प्रयोगकर्ता फिल्डमा कुनै पनि डोमेन उपसर्गसहित प्रोफाइलसँग ठ्याक्कै मिल्नुपर्छ।

rasdial
rasdial "Office VPN"
(Start-Process rasdial -ArgumentList '"Office VPN"' -Wait -PassThru -NoNewWindow).ExitCode

पहिलो कमाण्डले Windows ले जान्ने नामहरूको सूची दिन्छ। दोस्रोले क्यास गरिएका प्रमाणहरू प्रयोग गरी नामबाट डायल गर्छ, र तेस्रो त्यो रूप हो जुन PowerShell कार्यले प्रयोग गर्नुपर्छ, किनकि यो पर्खन्छ र कार्यले रेकर्ड गर्न सक्ने मान फर्काउँछ।

विन्डोको सट्टा एक्जिट कोड पढ्नुहोस्

पर्खन नगरी प्रक्रिया सुरु गर्ने कार्यले प्रक्रिया अवस्थित हुनासाथ सफलताको जानकारी दिन्छ। एक सेकेन्डपछि असफल हुनसक्ने डायलका लागि त्यो निर्णय बेकार छ। एक्जिट कोडको प्रतीक्षा गर्दा कार्यलाई वास्तविक नतिजा बनाउँछ। कार्य इतिहासले एक्लै प्रक्रिया सुरु भएको मात्र देखाउँछ, सुरुङ माथि आएको कहिल्यै देखाउँदैन।

हरेक पटक चल्दा टाइमस्ट्याम्पसहित मान लग गर्नुहोस्। अवरोधपछि एकल विफलता सामान्य हो, तर एउटै कोडसँग लगातार तीन विफलताले नेटवर्कतिर नभई प्रमाण वा प्रोफाइलतिर सङ्केत गर्छ। त्यही ढाँचाले इतिहासलाई पढ्नयोग्य बनाउँछ।

बीमाका रूपमा छोटो दोहोरिने अन्तराल थप्नुहोस्, र यो घटना ट्रिगरसँग कसरी अन्तरक्रिया गर्छ स्पष्ट भन्नुहोस्। पाँच मिनेटसम्म हरेक मिनेट दोहोरिनुले इन्टरनेट सुरुङसँगै फर्किएपछि दोस्रो प्रयास दिन्छ, र सेटिङमा, "यदि कार्य पहिले नै चलिरहेको छ भने निम्न नियम लागू हुन्छ", कार्यले "नयाँ इन्स्टेन्स सुरु नगर्नु" चाहन्छ ताकि दोहोरिने क्रम चलिरहेको डायलमाथि नपरोस्। त्यो सेटिङबिना दुई rasdial प्रक्रियाहरू एउटै पोर्टका लागि प्रतिस्पर्धा गर्न सक्छन् र दोस्रो कुनै उपयोगी कारणबिना असफल हुन्छ।

पुनःप्राप्तिको बाटो प्रमाणित गर्नुहोस्

दुवै दिशा जानाजान परीक्षण गर्नुहोस्। हातले विच्छेद गर्नुहोस् र पुनः डायल नहुने पुष्टि गर्नुहोस्, त्यसपछि नेटवर्क एडाप्टर अक्षम गर्नुहोस् र लिङ्क फर्किएपछि कार्य सक्रिय हुने पुष्टि गर्नुहोस्। ती दुई परीक्षणले दमन नियम र वास्तविक विफलताको अवस्था समेट्छन्, र अरू कुनैले त्यो गर्दैन।

त्यसपछि जडान आइकनको सट्टा कार्य इतिहास पढ्नुहोस्। इतिहासले कार्य कहिले चल्यो, कुन खाता प्रयोग गर्यो र कार्यले के फर्कायो रेकर्ड गर्छ, र अर्को महिना त्यही मेसिन फेरि टुट्दा त्यही प्रमाण चाहिन्छ।

सम्बन्धित लेखहरू