AnyConnect मध्ये कनेक्शन सबसिस्टम सुरू होऊ शकला नाही ही त्रुटी दुरुस्त करा

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

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

काहीही बदलण्यापूर्वी वेळ वाचा

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

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

पायरी 1: एजंट सेवा चालू आहे याची खात्री करा

तुम्ही क्लिक करता ती विंडो फक्त पुढचा भाग आहे; काम Cisco AnyConnect Secure Mobility Agent सेवेत होते, जी vpnagent म्हणून नोंदणीकृत आहे. ती सेवा थांबवलेली किंवा अक्षम केलेली असेल तर GUI कडे बोलण्यासाठी कुणीच नाही आणि ते नेमके हेच सुरुवातीचे अपयश नोंदवते. उन्नत PowerShell प्रॉम्प्टवरून स्थिती आणि स्टार्टअप प्रकार तपासा:

Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent

पूर्वी हाताने ठरवलेल्या स्टार्टअप प्रकाराचा आदर करणारा इंस्टॉलर हेच अक्षम होण्याचे नेहमीचे कारण आहे, म्हणून फक्त Start न दाबता StartType तपासा. सेवा काही सेकंदांत सुरू होऊन थांबली तर Repair क्लिक करण्यापूर्वी System लॉगमध्ये Service Control Manager नोंदी वाचा:

Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40

अवरोधित ड्राइव्हर, क्वारंटाइन केलेली फाइल किंवा तृतीय-पक्षीय सुरक्षा उत्पादनाचा फिल्टर ड्राइव्हर त्या घटनांमध्ये स्वतःचे नाव घेईल. Repair तीच अवरोधित फाइल वरून पुनर्स्थापित करते आणि काहीही बदलत नाही, म्हणून घटना लॉग आधी येतो.

पायरी 2: HTTP स्टॅक नोंदवत असलेली ऑफलाइन स्थिती साफ करा

क्लायंट Windows HTTP घटकांद्वारे त्याचे प्रोफाइल डाउनलोड करतो आणि धोरण मूल्यांकन करतो, त्यामुळे वापरकर्त्याच्या इंटरनेट सेटिंग्जमध्ये ठरवलेला ऑफलाइन फ्लॅग प्रत्येक ब्राउझर पाने लोड करत असतानाही सुरुवात खंडित करू शकतो. मूल्य थेट तपासा:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline

मूल्य 1 असा अर्थ WinINet स्टॅक कॉल करणाऱ्यांना सांगत आहे की मशीनला कनेक्शन नाही; ही स्थिती सहसा Internet Explorer मधील Work Offline मेनू आयटम किंवा ऑटोमेशन स्क्रिप्ट ठरवते. ते पुन्हा 0 वर ठेवा, साइन आउट करून पुन्हा साइन इन करा आणि दुसरे काही बदलण्यापूर्वी कनेक्शन पुन्हा प्रयत्न करा.

हे मशीन तुम्हाला वारसाहक्काने मिळाले असेल आणि फ्लॅग का ठरवला गेला ते सांगू शकत नसाल, तर तिकीटमध्ये नोंदवा. मशीनवरील दुसरे काही तो जाणूनबुजून ठरवले असेल आणि पुढील लॉगऑनला तो परत येईल.

पायरी 3: व्हर्च्युअल अ‍ॅडॉप्टर Hyper-V किंवा ICS पासून मुक्त करा

Windows च्या दोन भूमिका क्लायंटला त्याचा अ‍ॅडॉप्टर तयार करण्यासाठी लागणारे भाग धरून ठेवू शकतात. Hyper-V पहिली आहे: व्हर्च्युअल स्विच सेवा चालू असताना अ‍ॅडॉप्टर तयार करणे या त्रुटीच्या स्वरूपात अपयशी होऊ शकते. सेवा थांबवणे हे निदान आहे, उपाय नाही:

Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"

त्या सेवा थांबलेल्या असताना क्लायंट कनेक्ट झाला तर संघर्ष निश्चित होतो आणि Hyper-V होस्टच्या मालकाशी कशावर बोलणी करायची हे आता तुम्हाला माहीत आहे. मशीनला आता व्हर्च्युअलायझेशनची गरज नसेल तर नंतर त्या पुन्हा सुरू करा.

इंटरनेट कनेक्शन शेअरिंग हा दुसरा मालक आहे. एखादे कनेक्शन शेअर होत असेल तर क्लायंट टनेल तयार करण्यापूर्वीच अपयशी होऊ शकतो. Get-Service SharedAccess ने खात्री करा आणि ते चालू असून स्वयंचलितवर ठेवले असेल, तर अ‍ॅडॉप्टरांमध्ये शेअर केलेले कनेक्शन शोधा आणि फक्त त्या अ‍ॅडॉप्टरवर शेअरिंग बंद करा.

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

तपासा, नंतर गरज नसलेले परत घ्या

तपासणी म्हणजे ट्रेतील हिरवी ढाल नाही. अ‍ॅडॉप्टर अस्तित्वात आहे, पत्ता धरतो आणि रहदारी पार करतो याची खात्री करा: Get-NetAdapter -Name "Cisco AnyConnect*" ते त्याला चालू दाखवले पाहिजे, ipconfig /all नेमून दिलेला पत्ता आणि DNS सर्व्हर दाखवले पाहिजेत, आणि अंतर्गत नावासाठीची खरी विनंती स्थानिक रिझॉल्व्हरऐवजी टनेलमधून सोडवली पाहिजे.

प्रत्येक बदलाची छोटी यादी ठेवा, सापडलेले मूल्य आणि ठरवलेले मूल्य यासह. तिसऱ्या पायरीनंतर कनेक्शन चालले तर तिकीट बंद करण्यापूर्वी Hyper-V सेवा पुनर्संचयित करा आणि पुन्हा तपासा, कारण व्हर्च्युअलायझेशन गुपचूप बंद करणारा उपाय लक्षात येणाऱ्या पुढील प्रशासकाकडून रद्द केला जाईल.

तीनही पायऱ्यांपैकी कोणतीही त्रुटी हलवत नसेल तर एंडपॉइंट बदलणे थांबवा. क्लायंट आवृत्ती, सेवेची स्थिती, या पानाच्या वरची वेळ आणि क्लायंट तयार करू शकणारे निदान बंडल गोळा करा, आणि तुम्ही प्रयत्न केलेल्या नेमक्या क्रमासह ते सुपूर्द करा. ते बंडल पुढील अभियंत्यासाठी संवादपटलाच्या स्क्रीनशॉटपेक्षा जास्त मौल्यवान आहे, आणि सबसिस्टम नेटवर्कला स्पर्श करण्यापूर्वी अपयशी झाले की नंतर हे दाखवणारी ती एकमेव वस्तू आहे.