क्रेडेन्शियल देण्याआधीच गोठणे, प्रोफाइल हटवण्यास नकार, कोणालाही न ओळखता येणारे नाव असलेला अॅडाप्टर दाखवणे: हे एकाच बिघाडाचे तीन चेहरे आहेत। 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 दुरुस्ती नाही, आणि जे मशीन तो क्लायंट चालवत नाही तिथे ती कधीही लागू करू नये।

तिकीट बंद करण्यापूर्वी दुसऱ्या प्रोटोकॉलने पुष्टी करा

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

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

संबंधित लेख