Windows VPN कनेक्ट नहीं हो रहा? कोड को इवेंट लॉग से मिलाएँ

शुक्रवार को यह काम कर रहा था। सोमवार को वही Windows क्लाइंट एक डायलॉग के साथ जवाब देता है जो कहता है कि कनेक्शन का प्रयास विफल रहा, और उसके नीचे का वाक्य वही है जो आपने दर्जन भर असंबंधित समस्याओं के लिए पहले ही देखा है। वह डायलॉग एक शृंखला का अंत है, उसकी शुरुआत नहीं। Windows उस चरण को छिपाता है जहाँ प्रयास वास्तव में मरा, और दो छोटे साक्ष्य उसका नाम लेते हैं: संख्यात्मक परिणाम कोड और उसी मिनट का एक RasClient इवेंट। यह वह क्रम है जो मैं इस्तेमाल करता हूँ — प्रयास को स्थिर करें, कोड पढ़ें, इवेंट निकालें, फिर ठीक एक परत बदलें।

डायलॉग का पाठ अंतिम चरण है, कारण नहीं

आप जो वाक्य पढ़ते हैं वह प्रयास के पहले ही खुल जाने के बाद चुना जाता है। "कनेक्शन स्थापित होने से पहले दूरस्थ कंप्यूटर द्वारा कनेक्शन समाप्त कर दिया गया" तब दिखता है जब कोई सर्वर बातचीत के बीच में फोन रख देता है, जब आपका उपयोगकर्ता नाम भेजे जाने से पहले ही IPsec विफल हो जाता है, और जब कोई नीति टनल को सीधे अस्वीकार कर देती है। तीन अलग मालिक, एक वाक्य। शब्दावली को लक्षण-वर्ग मानिए और जब तक कोड उससे सहमत न हो, इसे कुछ भी निर्देशित करने न दें।

जो आप अब भी स्थिर कर सकते हैं वह प्रयास स्वयं है। कनेक्शन का नाम, प्रोफ़ाइल में संग्रहीत टनल प्रकार — PPTP, L2TP/IPsec, SSTP या IKEv2 — सेकंड तक का समय, और कोड लिख लें। यदि आप निश्चित नहीं हैं कि वास्तव में कौन-सा प्रोटोकॉल चला, तो स्मृति पर भरोसा करने के बजाय %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk खोलें और प्रविष्टि पढ़ें; नए प्रोटोकॉल के लिए दोबारा इस्तेमाल की गई प्रोफ़ाइल अपना पुराना प्रदर्शित नाम रखती है।

शब्द पढ़ने से पहले संख्या पढ़ें

कोड तीन चरणों में पड़ते हैं, और चरण सटीक शब्दावली से अधिक मायने रखता है: एक प्रमाणीकरण विनिमय जहाँ पहुँचा गया और अस्वीकार किया गया, एक सर्वर जिसने कभी उत्तर नहीं दिया, या एक बातचीत जो लिंक उठने के बाद ढह गई। 691 पहला प्रकार है — क्रेडेंशियल जाँच चली और विफल रही, चाहे खराब पासवर्ड के कारण, बंद या समाप्त खाते के कारण, या ऐसे प्रमाणीकरण प्रोटोकॉल के कारण जिसे सर्वर स्वीकार नहीं करता। 812 भी अस्वीकृति है, पर मान्य क्रेडेंशियल के साथ: दूरस्थ पहुँच सर्वर पर एक नीति ने आपके विरुद्ध निर्णय लिया। Microsoft आधिकारिक डायल-अप और VPN कनेक्शन के लिए त्रुटि कोड की सूची रखता है, और संदेश का पाठ खोजने से पहले वहाँ अपना नंबर पढ़ना उचित है।

809 विपरीत वर्ग है: कुछ भी वापस नहीं आया। यह पथ की समस्या है — SSTP के लिए TCP 443 फ़िल्टर, PPTP के लिए GRE अवरुद्ध, IPsec पास-थ्रू के लिए UDP 500 और 4500 या ESP गिराए गए। नया पासवर्ड इसे ठीक नहीं कर सकता और नया प्रमाणपत्र भी नहीं। 720 का अर्थ है कि लिंक उठा और PPP ने बातचीत कभी पूरी नहीं की, जो प्रोटोकॉल की असंगति या ऐसे सर्वर की ओर संकेत करता है जो पता निर्दिष्ट नहीं कर सका। 789, या IKEv2 पर 13801, IPsec के भीतर की पहचान है: ऐसा प्रमाणपत्र जिसका विषय उस नाम से मेल नहीं खाता जिसे आप डायल करते हैं, अस्थिर शृंखला, या दोनों सिरों के बीच भिन्न पूर्व-साझा कुंजी।

उसी मिनट का RasClient इवेंट निकालें

इवेंट व्यूअर में, स्रोत RasClient पर फ़िल्टर किया गया Windows Logs > Application पहली जगह है जहाँ देखना चाहिए। त्रुटि 720 पर Microsoft का लेख उस लॉग में इवेंट 20227 की ओर संकेत करता है। वही प्रदाता अन्य परिणामों के लिए अन्य पहचानकर्ता देता है, इसलिए ID को निदान मानने के बजाय संदेश और उसमें अंतर्निहित परिणाम कोड पढ़ें; एक सामान्य डायलॉग और 720 ले जाने वाला 20227 पहले से ही कहीं अधिक सीमित कहानी है।

PowerShell से, GUI में क्लिक किए बिना:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

खाली परिणाम जानकारीपूर्ण है। इसका अर्थ आमतौर पर यह है कि डायल कभी इतना दूर नहीं गया कि RAS कुछ लॉग कर सके, या जो सॉफ़्टवेयर विफल हुआ वह मूल क्लाइंट ही नहीं है — तृतीय-पक्ष क्लाइंट अपना निदान रखते हैं और अक्सर Application लॉग में कुछ नहीं लिखते। यह निष्कर्ष निकालने से पहले कि इवेंट लॉगिंग टूटी है, विक्रेता का लॉग जाँचें।

इवेंट के ढेर के बजाय एक समयरेखा बनाएँ

पुनः प्रयास के लूप शोर पैदा करते हैं। पाँच स्वचालित पुनःकनेक्शन इवेंट का एक समूह छोड़ते हैं, और प्रलोभन यह है कि उन्हें एक ही कारण वाला एक क्रम पढ़ा जाए। वे पाँच अलग प्रयास हैं, और उनमें से केवल कुछ ही किसी सर्वर तक पहुँचे। दो या तीन मिनट की एक विंडो, एक कनेक्शन नाम लें, और कुछ भी व्याख्या करने से पहले हर इवेंट को उसके अपने कोड के साथ सूचीबद्ध करें।

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

दोहराने योग्य कैप्चर के लिए, कमांड लाइन से डायल करें और उसे परिणाम प्रिंट करने दें:

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

कंसोल वह संख्या दिखाता है जिसे GUI मैत्रीपूर्ण पाठ के पीछे छिपाता है, और दो बार चलाने से पता चलता है कि कोड स्थिर है या रुक-रुक कर आने वाला।

हर चरण आपको क्या बदलने के लिए कहता है

चरण का नाम देना तभी उपयोगी है जब वह परिवर्तन-समुच्चय को एक परत तक घटा दे:

• 691 — प्रमाणीकरण: क्लाइंट जो EAP विधि देता है उसके मुकाबले वह जिसे सर्वर स्वीकार करता है, खाते की स्थिति, पासवर्ड की समाप्ति, डायल-इन अनुमति।
• 812 — सर्वर नीति: इस उपयोगकर्ता और इस समय-विंडो से मेल खाने वाली दूरस्थ पहुँच नीति या NPS नियम।
• 809 — पहुँच: पथ पर फ़ायरवॉल नियम, NAT और प्रोटोकॉल पास-थ्रू, वह पोर्ट जो चुने गए टनल प्रकार को चाहिए।
• 720 — PPP बातचीत: प्रमाणीकरण प्रोटोकॉल की असंगति, पता निर्दिष्ट करना, सर्वर-पक्ष का PPP सेटिंग।
• 789 / 13801 — IPsec पहचान: जिस नाम को आप डायल करते हैं उसके मुकाबले प्रमाणपत्र का विषय, विश्वास शृंखला, पूर्व-साझा कुंजी।

इनमें से एक बदलें, वही प्रोफ़ाइल दोबारा जाँचें, और नया कोड लिख लें। बदलाव के बाद अलग कोड विरोधाभास नहीं बल्कि प्रगति है: आपने विफलता को बाद के चरण में खिसका दिया, और बहु-चरणीय हैंडशेक ठीक करना ऐसा ही दिखता है। जो आपको नहीं करना चाहिए वह है एक ही बैठक में फ़ायरवॉल, प्रमाणपत्र और पासवर्ड बदलकर फिर जो सबसे बाद में आया उसे श्रेय देना।

साक्ष्य साझा करें, वातावरण नहीं

इवेंट संदेश दिखने से अधिक समृद्ध होते हैं। वे कनेक्शन का नाम, खाता, अक्सर गेटवे का आंतरिक नाम या पता, और कभी-कभी प्रमाणपत्र का थंबप्रिंट ले जाते हैं। मूल को वहीं रखें जहाँ उसका स्थान है, और किसी भी अन्य के लिए अलग संपादित प्रति बनाएँ; स्मृति से समयरेखा दोबारा टाइप करने से ठीक वही विवरण खो जाते हैं जो उसे उपयोगी बनाते हैं।

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

कुछ भी बंद करने से पहले, उसी प्रोफ़ाइल पर प्रयास दोबारा चलाएँ और पुष्टि करें कि कोड अब कहाँ पड़ता है। सफलता उसे समाप्त कर देती है; अलग विफलता का अर्थ है कि मूल चरण ठीक हो गया और अगला आपके हाथ में है।