Windows VPN सुरू ठेवा: डिस्कनेक्ट घटनेवर rasdial सक्रिय करा

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 प्रक्रिया एकाच पोर्टसाठी स्पर्धा करू शकतात आणि दुसरी कोणत्याही उपयुक्त कारणाशिवाय अयशस्वी होते.

पुनर्प्राप्तीचा मार्ग सिद्ध करा

दोन्ही दिशा जाणीवपूर्वक तपासा. हाताने डिस्कनेक्ट करा आणि पुन्हा डायल होत नाही याची खात्री करा, नंतर नेटवर्क अडॅप्टर अक्षम करा आणि दुवा परत आल्यावर कार्य सक्रिय होते याची खात्री करा. ते दोन चाचण्या दमन नियम आणि खऱ्या अयशस्वीतेची स्थिती व्यापतात, आणि दुसरे काहीही ते करत नाही.

त्यानंतर कनेक्शन चिन्हाऐवजी कार्य इतिहास वाचा. इतिहास नोंदवतो की कार्य कधी चालले, कोणते खाते वापरले आणि कृतीने काय परत दिले, आणि पुढच्या महिन्यात तेच मशीन पुन्हा तुटल्यावर तोच पुरावा लागतो.