Mac पर Cisco Secure Client: विंडो, ऑटो कनेक्ट या फिर से कनेक्ट?

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

जो व्यवहार आप वास्तव में देख रहे हैं उसे नाम दें

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

scutil --nc list
ps aux | grep -i [v]pnagentd
ifconfig | grep -A3 utun

तीनों आउटपुट साथ पढ़ें, क्योंकि scutil --nc list सिस्टम के VPN कॉन्फ़िगरेशन की सूची देता है और खाली सूची का मतलब सिर्फ़ यह है कि कोई भी सिस्टम VPN सेवा टनल नहीं रखती. Cisco Secure Client ऐसा कोई दर्ज नहीं करता: यह vpnagentd और utun इंटरफ़ेस के ज़रिए समाप्त होता है, इसलिए प्रोसेस और इंटरफ़ेस ही वे साक्ष्य हैं जो इसे देखते हैं। जब vpnagentd चल रहा हो और utun इंटरफ़ेस के पास पता हो, तो विंडो बंद होने पर भी टनल मौजूद रहता है; जब दोनों में से कोई न हो, तो ऑटोमैटिक कनेक्शन बंद है और विंडो ही चर्चा का विषय है। फ्रंट एंड तब भी चल सकता है जब कोई अलग बैकग्राउंड सेवा टनल रखती हो, इसलिए मालिकाना का सवाल प्रोफ़ाइल वाले हिस्सों का है, इसका नहीं।

लॉगिन पर दिखने वाली विंडो लॉन्च का सवाल है

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

प्रबंधित Mac पर, व्यवहार को स्थानीय प्राथमिकता मानने से पहले पुष्टि करें कि क्या वह इंस्टॉल किए गए कॉन्फ़िगरेशन प्रोफ़ाइल के ज़रिए आता है। सिस्टम अपने पास मौजूद प्रोफ़ाइलों की सूची दे सकता है, और प्रबंधित लॉगिन आइटम आपका हटाने के लिए नहीं है:

profiles show -type configuration

जहाँ सेटिंग उपयोगकर्ता के नियंत्रण में है, उसे क्लाइंट की प्राथमिकताओं में बदलें और जाँच के लिए लॉगआउट करें। जहाँ वह लॉक है, प्रोफ़ाइल का मालिक ही उसे बदल सकता है। स्थानीय रूप से फ़ाइलें हटाने से ऐसा अंतर बनता है जिसे अगला अपडेट चुपचाप ठीक कर देता है, जिससे वह उपलब्ध सबसे कम टिकाऊ समाधान बन जाता है। धुँधला चेकबॉक्स टूटा हुआ क्लाइंट नहीं है; वह नीति का बयान है।

Auto Connect on Start एक अलग प्राथमिकता है

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

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

Auto Reconnect तीसरी सेटिंग का है

रीकनेक्ट तय करता है कि स्थापित सत्र का रास्ता खोने के बाद क्या होता है: ढक्कन बंद होना, Wi-Fi नेटवर्क बदलना, वायर्ड लिंक गिरना। Cisco इसे स्टार्टअप व्यवहार से अलग दस्तावेज़ करता है, इसलिए स्टार्टअप का बदलाव उसे नहीं छुएगा। इसे नेटवर्क को पल भर के लिए डिस्कनेक्ट करके और यह देखकर जाँचें कि टनल बिना इनपुट के लौटता है या नहीं।

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

सबसे छोटा बदलाव माँगें, फिर उसे जाँचें

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

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

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