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 सेवाएँ बहाल करें और फिर परीक्षण करें, क्योंकि वर्चुअलाइज़ेशन को चुपचाप बंद करने वाला कामचलाऊ उपाय अगला प्रशासक जो ध्यान देगा, वही रद्द कर देगा।

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