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

प्रोफ़ाइल वास्तव में किससे बँधा है

हर मूल Windows टनल प्रकार अपने अलग वर्चुअल अडैप्टर से सेवा पाता है, और वे अडैप्टर भौतिक कार्ड नहीं, मिनिपोर्ट ड्राइवर हैं। प्रोफ़ाइल टनल प्रकार चुनता है, प्रकार अडैप्टर चुनता है, और इसलिए एक ही अस्वस्थ ड्राइवर उसे साझा करने वाले हर प्रोफ़ाइल को तोड़ सकता है, जबकि फ़ाइल साझाकरण और ब्राउज़िंग चलती रहती है। यह निर्भरता प्रोफ़ाइल के गुणों में अदृश्य है।

ये इंटरफ़ेस डिफ़ॉल्ट रूप से छिपे रहते हैं, डिवाइस मैनेजर और अडैप्टर सूची दोनों में। ऐसे ही कोई ख़राब इंटरफ़ेस अदृश्य रहता है, जबकि मशीन का मालिक ज़ोर देता है कि कुछ नहीं बदला।

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

अडैप्टर की स्थिति से तय करें, त्रुटि कोड से नहीं

त्रुटि संख्या बताती है कि कौन-सा चरण विफल हुआ और यह नहीं बताती कि कौन-सा घटक दोषी है। पता आवंटन, प्रमाणपत्र चयन और टनल प्रोटोकॉल के अपने नंबर हैं, परंपरागत रूप से 720, 789 और 806, और इन तीनों में से कोई भी मिनिपोर्ट के बारे में सबूत नहीं है। इस संख्या का उपयोग अगली जाँच चुनने के लिए करें, मरम्मत चुनने के लिए नहीं।

भेद करने वाले अवलोकन कम हैं। यह तालिका हर एक को एक केवल-पढ़ने वाले अगले कदम से जोड़ती है:

What you observeWhat it impliesRead-only step
Every profile on one protocol failsThat protocol's miniport is unusableRead the hidden adapter status
Adapter reports healthy, tunnel never startsA binding is missing or disabledList every binding on the adapter
Only the vendor client failsThe vendor adapter or its registered nameRead the vendor service key
The profile will not deleteThe interface underneath is stuckConfirm the adapter before removing the profile

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

ज़्यादातर टिकट सुलझाने वाली दो पढ़ाइयाँ

दोनों पढ़ाइयाँ केवल-पढ़ने वाली हैं और कोई भी ड्राइवर को नहीं छूती। पहली छिपे मिनिपोर्ट इंटरफ़ेस को उनकी स्थिति सहित सूचीबद्ध करती है, और दूसरी सूचीबद्ध करती है कि नामित अडैप्टर किससे बँधा है:

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -like 'WAN Miniport*' | Select-Object Name, InterfaceDescription, Status
Get-NetAdapterBinding -Name 'WAN Miniport (IKEv2)' -IncludeHidden -AllBindings

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

स्वस्थ अडैप्टर वे बंधन दिखाता है जिनकी आप अपेक्षा करते हैं और ऐसा कोई फ़िल्टर नहीं जिसे आप समझा न सकें। जब सूची साफ़ हो, सबूत ड्राइवर के पास चला गया है और अगला खंड वही है जो लागू होता है।

अडैप्टर हटाने से पहले उसका नाम और ड्राइवर संस्करण सहेजें

जब अडैप्टर वास्तव में अनुपयोगी हो, मानक मरम्मत यह है कि उसे हटाने योग्य बनाएँ, अनइंस्टॉल करें, और अगली बार जब कोई प्रोफ़ाइल उस प्रोटोकॉल का उपयोग करे तो Windows को नया इंस्टेंस बनाने दें। डिवाइस मैनेजर में ड्राइवर अपडेट करें, सूची से चुनें, संगत हार्डवेयर फ़िल्टर साफ़ करें, और अनइंस्टॉल का विकल्प देने वाला सामान्य Microsoft अडैप्टर चुनें।

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

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

HKLM\SYSTEM\CurrentControlSet\Services\CVirtA
DisplayName = Cisco Systems VPN Adapter for 64-bit Windows

वह कुंजी एक ही क्लाइंट की है। यह सामान्य Windows मरम्मत नहीं है, और इसे कभी भी ऐसी मशीन पर लागू नहीं करना चाहिए जो वह क्लाइंट न चलाती हो।

टिकट बंद करने से पहले दूसरे प्रोटोकॉल से पुष्टि करें

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

अगर मूल शिकायत ऐसी प्रोफ़ाइल थी जो मिटाई नहीं जा सकती, तो उसे भी फिर जाँचें, क्योंकि अडैप्टर के स्वस्थ होने के बाद भी मिटाने से इनकार करने वाली प्रोफ़ाइल अलग ख़राबी है और अडैप्टर पर आगे का काम बेकार है। खाते और गेटवे को रिपोर्ट से बाहर रखें जब तक कि कोई बात उनकी ओर इशारा न करे। प्रमाणीकरण से पहले मरने वाली टनल आम तौर पर मशीन का वर्णन करती है, और ईमानदार नोट अडैप्टर, प्रोटोकॉल और उस जाँच का नाम लेता है जिसने इसे पुष्ट किया।

संबंधित लेख