OpenVPN TAP अडॅप्टर स्थापित झाला नाही: कोणता टप्पा बिघडला?

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

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

तीन टप्पे, तीन वेगवेगळे लॉग

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

सारांश संकेत व्यवहाराचा आहे, तर अयशस्वी कृती त्याच लॉगमध्ये कुठेतरी आधी आहे। संकेताचे स्पष्टीकरण देण्याऐवजी संकेतापासून मागे शोधा।

प्रयत्नाभोवतीचा setupapi.dev.log वाचा

प्रत्येक उपकरण स्थापना C:\Windows\INF\setupapi.dev.log मध्ये एक विभाग लिहिते, आणि SetupAPI लॉग मार्गदर्शक ते विभाग आणि त्यांची अंतिम स्थिती कशी रचलेली आहे हे स्पष्ट करतो। ज्या विभागाची वेळमुद्रा तुमच्या प्रयत्नाला व्यापते तो शोधा, मग तुमच्या नजरेस पडलेल्या पहिल्या त्रुटी ओळीऐवजी तो पूर्ण वाचा। असंबंधित उपकरणांबद्दलचे इशारे लांब लॉगमध्ये सर्वत्र दिसतात आणि या अयशस्वी स्थितीबद्दल काहीही स्पष्ट करत नाहीत। जुळणाऱ्या विभागाची अंतिम स्थिती ही अहवालात उद्धृत करण्याजोगी तथ्य आहे।

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

पॅकेज आणि उपकरण स्वतंत्रपणे तपासा

तयार केलेले पॅकेज फक्त एवढेच सिद्ध करते की स्वाक्षरी केलेले INF ड्राइव्हर स्टोअरपर्यंत पोहोचले। या Windows पिढीवर pnputil /enum-drivers तृतीय-पक्ष पॅकेजेस पुरवठादार, वर्ग, आवृत्ती आणि प्रकाशित नावानुसार सूचीबद्ध करते, ज्यामुळे oem क्रमांकावरून अंदाज करण्याऐवजी तुम्हाला OpenVPN अडॅप्टरचे पॅकेज सापडते। त्या सूचीत उपकरण आहे, सुरू झाले किंवा तुम्हाला सापडलेल्या पॅकेजशी जोडले आहे असे काहीही नमूद नाही। ते वेगवेगळ्या उत्तरांचे वेगवेगळे प्रश्न आहेत।

उपकरणाच्या बाजूला स्वतःचा दृष्टिकोन असतो। फक्त-वाचनीय अडॅप्टर यादी Windows सध्या इंटरफेसबद्दल काय मानते ते दाखवते, आणि लपलेल्या नोंदी अस्तित्वात असलेल्या पण निष्क्रिय उपकरणांचा समावेश करतात। दोन्ही याद्या तुलना केल्यावर कोणता टप्पा अयशस्वी झाला ते कळते: पॅकेज नाही, उपकरण नाही, किंवा उपकरण आहे पण समस्या स्थितीत आहे।

स्वाक्षऱ्यांना स्पर्श करण्यापूर्वी अडॅप्टर सत्यापित करा

स्थिती इन्स्टॉलरच्या सारांशातून नव्हे, तर मशीनमधून वाचा। खालील आदेश तयार केलेली ड्राइव्हर पॅकेजेस, लपलेल्या नोंदींसह अडॅप्टर यादी आणि OK नोंदवत नसलेली नेटवर्क उपकरणे सूचीबद्ध करतात। रीबूटनंतर ते चालवा, जेणेकरून प्रलंबित उपकरण क्रिया स्थिरावतील।

pnputil /enum-drivers
Get-NetAdapter -IncludeHidden | Select-Object Name, InterfaceDescription, Status
Get-PnpDevice -Class Net | Where-Object Status -ne 'OK'

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

स्वाक्षरी अंमलबजावणी बंद करणे, नेटवर्क स्टॅक रीसेट करणे किंवा सर्व अडॅप्टर हटवणे यामुळे पुरावे नाहीसे होतात। या तिन्हींपैकी कोणतेही अजून न ओळखलेला टप्पा दुरुस्त करत नाही, आणि प्रत्येकजण कोणता टप्पा होता हे सांगणारी गोष्ट काढून टाकतो।