Windows VPN कनेक्ट होत नाही? कोड इव्हेंट लॉगशी जुळवा

Windows VPN संवाद त्या टप्प्याला लपवतो जो अयशस्वी झाला. निकाल कोड वाचा, त्या प्रयत्नाचा RasClient इव्हेंट काढा आणि फक्त तुटलेला स्तर बदला.

शुक्रवारी हे चालत होते। सोमवारी तोच 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 ओळख: तुम्ही डायल करता त्या नावाविरुद्ध प्रमाणपत्राचा विषय, विश्वास साखळी, पूर्व-सामायिक की।

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

पुरावे सामायिक करा, वातावरण नाही

इव्हेंट संदेश दिसतात त्यापेक्षा समृद्ध असतात। ते कनेक्शनचे नाव, खाते, बऱ्याचदा गेटवेचे अंतर्गत नाव किंवा पत्ता, आणि कधीकधी प्रमाणपत्राचा बोटांचा ठसा वाहतात। मूळ जिथे हवे तिथे ठेवा, आणि इतर कोणासाठीही वेगळी संपादित प्रत तयार करा; स्मरणशक्तीतून कालरेषा पुन्हा टाइप केल्यास तिला उपयुक्त बनवणारे तंतोतंत तपशील हरवतात।

ज्यावर काम होईल अशा हस्तांतरणाला पाच क्षेत्रे लागतात: कोड, तो ज्या टप्प्याचा आहे तो टप्पा, क्लायंट आणि बोगदा प्रकार, त्याच्या वेळ क्षेत्रासह वेळेचा शिक्का, आणि गेटवेने विनंती अजिबात पाहिली का। बाकी सर्व ऐच्छिक आहे। या पाचांसह पुढची व्यक्ती तपासणी पुन्हा न करता क्रेडेन्शियलची वादळ आणि मार्गनिर्देशनाची वादळ वेगळी करू शकते।

काहीही बंद करण्यापूर्वी, त्याच प्रोफाइलवर प्रयत्न पुन्हा चालवा आणि कोड आता कुठे पडतो याची खात्री करा। यश ते संपवते; वेगळी अयशस्वीता म्हणजे मूळ टप्पा दुरुस्त झाला आहे आणि पुढचा तुमच्या हातात आहे।

संबंधित लेख