IP पत्त्यासह त्रुटी 868? Windows प्रथम काय सोडवते

संवाद सांगतो की सर्व्हरचे नाव सोडवता आले नाही, आणि तुम्ही ज्याकडे पाहत आहात ते प्रोफाइल फील्ड एक पत्ता आहे. हे संयोजन विरोधाभास नाही: क्लायंट तुम्हाला वाटते ते मूल्य वाचतो त्यापेक्षा वेगळे काही सोडवत आहे. DNS खराब आहे असा निष्कर्ष काढण्यापूर्वी तो प्रत्यक्षात कशाला डायल करतो ते शोधा. क्लायंटच्या स्वतःच्या पायऱ्यांचा क्रम कुठे पाहावे हे तुम्हाला सांगते.

क्लायंट डायल करण्यापूर्वी नाव सोडवतो

Windows चे मूळ VPN कनेक्शन त्याचे प्रोफाइल वाचते, सर्व्हरचा पत्ता सोडवते, टनेल सुरू करते आणि त्यानंतरच प्रमाणीकरण करते. त्रुटी 868 दुसऱ्या पायरीची आहे. पुढील पायऱ्या कधीच चालत नाहीत, म्हणून लुकअप आधी अपयशी ठरला असता संवाद क्रेडेन्शियल समस्येसारखा दिसू शकतो.

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

कोणते नाव, जेव्हा फील्ड पत्ता दाखवते

दाखवलेल्या नावाऐवजी साठवलेले मूल्य वाचा. कनेक्शनचे लेबल त्याचा सर्व्हर पत्ता नाही, आणि सारखी लेबल असलेल्या दोन नोंदी तुम्हाला चुकीच्यामागे पाठवतात:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

प्रोफाइल सर्व वापरकर्त्यांसाठी तयार केले असेल, तर ती व्याप्तीही यासह विचारा -AllUserConnection. नंतर कमांडने छापलेले मूल्य नेमके तेच, अपयश येते त्या नेटवर्कवरून सोडवा. ऑपरेटरचे दस्तऐवजीकृत गेटवे वापरा, टनेल उभे राहिल्यावरच सोडवले जाणारे अंतर्गत अनुप्रयोग नाव नाही. ती दुसरी क्वेरी अपेक्षित कारणाने अपयशी ठरते आणि डायलबद्दल तुम्हाला काहीही सांगत नाही:

Resolve-DnsName vpn.example.com

जेव्हा साठवलेले मूल्य खरोखर संख्यात्मक असेल, तेव्हा क्लायंट नाव वाचतो ते दुसरे ठिकाण शोधा. EAP संरचना सर्व्हरचा संदर्भ देऊ शकते, दुसऱ्या साधनातून आयात केलेले प्रोफाइल स्वतःचे मूल्य बाळगू शकते, आणि पूर्वीचा इंस्टॉलर डुप्लिकेट नोंद मागे ठेवू शकतो. संवादातील फील्ड नेहमी एकमेव इनपुट नसते.

Windows 7 पुन्हा-कनेक्ट नमुना

या त्रुटीमागील थ्रेड अशा मशीनचे वर्णन करतो ज्या एकदा जोडल्या गेल्या आणि नंतरच्या प्रयत्नात 868 सह अपयशी ठरल्या, प्रोफाइलमध्ये काहीही न बदलता. सहभागींनी नोंदवले की Remote Access Connection Manager सेवा पुन्हा सुरू करणे किंवा साइन आउट करून पुन्हा साइन इन करणे यामुळे कनेक्शन तात्पुरते पुनर्संचयित झाले. हे पर्यायी उपाय आहेत, सिद्ध मूळ कारण नाही.

त्या नमुन्याकडे स्वतंत्र गृहीतक म्हणून पाहा. पुन्हा सुरू करणे क्लायंटची स्थिती रीसेट करते, म्हणून नंतरचे तात्पुरते यश DNS नोंद चुकीची होती हे सिद्ध करत नाही:

तक्ता निदान म्हणून नाही, तर वेगळे करणाऱ्या निरीक्षणांचा संच म्हणून वाचा. पहिली ओळ नावाची समस्या आहे, दुसरी क्लायंटची स्थिती आहे, आणि तिसरी अशी प्रोफाइल आहे जी कधीही बरोबर नव्हती. प्रत्येक वेगळ्या व्यक्तीकडे आणि वेगळ्या दुरुस्तीकडे नेते.

प्रशासकासाठी काय गोळा करावे

प्रोफाइलचे नाव, साठवलेला पत्ता, टनेलचा प्रकार, क्लायंट ज्या नेटवर्कवर होता, आणि अपयश डिस्कनेक्टनंतर आले का, हे लिहून ठेवा. ती नोंद कोणालाही अंदाज लावण्याची गरज न देता खऱ्या लुकअप अपयशाला ऐतिहासिक पुन्हा-कनेक्ट वर्तनापासून वेगळी करते. प्रयत्नाभोवतीचा क्लायंट इव्हेंट लॉगही ठेवा.

जुन्या बिल्डमधील पर्यायी उपाय हा वर्तन अस्तित्वात होते याचा पुरावा आहे, तोच सेवा पुन्हा सुरू केल्याने सध्याचे मशीन दुरुस्त होईल असे वचन नाही. दस्तऐवजीकृत होस्टनाव शब्दशः पत्त्याने बदलणेही दुरुस्ती नाही.

काही प्रोफाइल संरचित नावाशी जुळणारी सर्व्हर ओळख अपेक्षित करतात, म्हणून संख्यात्मक पर्यायी उपाय एक त्रुटी दुसऱ्याशी बदलू शकतो. नाव राहायचे असेल तर प्रोफाइल मजकूर नाही, सोडवण्याचा मार्ग दुरुस्त करा. कोणत्याही परिस्थितीत, काय बदलले आणि का ते लिहा.