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 रेकर्ड गलत थियो भनी प्रमाणित गर्दैन:

तालिकालाई निदानको रूपमा होइन, छुट्याउने अवलोकनहरूको समूहको रूपमा पढ्नुहोस्। पहिलो पङ्क्ति नामको समस्या हो, दोस्रो क्लाइन्टको अवस्था हो, र तेस्रो कहिल्यै सही नभएको प्रोफाइल हो। प्रत्येकले फरक व्यक्ति र फरक सुधारतर्फ लैजान्छ।

प्रशासकका लागि के सङ्कलन गर्ने

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

पुराना बिल्डको वैकल्पिक उपाय व्यवहार अस्तित्वमा थियो भन्ने प्रमाण हो, त्यही सेवा पुनः सुरु गर्दा हालको मेसिन ठीक हुन्छ भन्ने वाचा होइन। कागजात गरिएको होस्टनामलाई शाब्दिक ठेगानाले बदल्नु पनि मर्मत होइन।

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