AnyConnect आपकी प्रोफ़ाइल को ओवरराइट करता है? यह नाम का टकराव है
दो गेटवे, एक फ़ाइल नाम: क्लाइंट आपके फ़ोल्डर में अंतिम प्रोफ़ाइल रखता है जबकि लाइब्रेरी पूरी मशीन की है। दोनों रखने के लिए प्रतियों का नाम बदलें।
चलती हुई कहानी यह है कि AnyConnect ने आपका दूसरा गेटवे खो दिया, या क्लाइंट दो प्रोफ़ाइल रखने के लिए बहुत पुराना है। इनमें से कुछ भी नहीं हुआ। जो हुआ वह यह है कि क्लाइंट हर देखी गई प्रोफ़ाइल को उस नाम की फ़ाइल के रूप में सहेजता है जो सर्वर ने भेजा, और आपके दोनों गेटवे अपनी फ़ाइल को एक ही नाम देते हैं। डिस्क पर उस नाम के लिए एक ही जगह है, इसलिए दूसरा डाउनलोड पहले की जगह ले लेता है।
दो फ़ोल्डर, और उनमें से सिर्फ़ एक आपका है
जो प्रति बदलती रहती है वह आपके अपने उपयोगकर्ता प्रोफ़ाइल के अंतर्गत कार्यशील प्रति है, आमतौर पर %LOCALAPPDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\preferences.xml। वह फ़ाइल आपके द्वारा बनाए गए अंतिम कनेक्शन और उसमें इस्तेमाल हुई प्रोफ़ाइल को दर्ज करती है। चूँकि वह आपके फ़ोल्डर में रहती है, क्लाइंट हर कनेक्शन पर उसे बिना अधिकार बढ़ाने की माँग किए फिर से लिखता है।
ड्रॉप-डाउन में जो सूची दिखती है वह कुछ और है। मशीन ने आज तक जो भी प्रोफ़ाइल प्राप्त की है वह %PROGRAMDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile में कॉपी होती है, और क्लाइंट वहाँ मौजूद फ़ाइलों को सूचीबद्ध करता है। उस फ़ोल्डर में लिखने के लिए व्यवस्थापक अधिकार चाहिए, जो एक ऐसा लक्षण समझाता है जिसे लोग गलत पढ़ते हैं: सामान्य उपयोगकर्ता के रूप में हाथ से प्रोफ़ाइल जोड़ना काम करता दिखता है, फिर प्रविष्टि गायब हो जाती है।
इसलिए प्रति-उपयोगकर्ता फ़ाइल एक सूचक है और पूरी मशीन का फ़ोल्डर लाइब्रेरी है। गायब प्रविष्टि का मतलब है कि लाइब्रेरी बदली, सूचक नहीं।
क्लाइंट फ़ाइलों का मिलान नाम से करता है, गेटवे से नहीं
इस क्लाइंट में प्रोफ़ाइल की पहचान फ़ाइल का नाम है। जो दो उपकरण दोनों company.xml भेजते हैं, स्थानीय प्रोफ़ाइल भंडार की दृष्टि से वे एक ही प्रोफ़ाइल हैं जो दो बार प्रकाशित हुई है। दूसरा डाउनलोड पहले को ओवरराइट कर देता है, और विंडो की प्रविष्टि अब भी एक ऐसी फ़ाइल की ओर इशारा करती है जो अब दूसरी साइट का वर्णन करती है।
इसीलिए विफलता इतनी अजीब लगती है। सूची का नाम अब भी वैसा ही पढ़ा जाता है जैसी आप अपेक्षा करते हैं, प्रमाणीकरण अब भी उसी गेटवे के विरुद्ध सफल होता है जो वास्तव में कॉन्फ़िगर है, और कोई त्रुटि की सूचना नहीं देता। जो बदला वह उस लेबल के पीछे की सामग्री है जिस पर आपने भरोसा किया था।
HostAddress पढ़ें, लेबल नहीं
फ़ाइल को टेक्स्ट एडिटर में खोलें और सर्वर सूची देखें। प्रोफ़ाइल में HostName तत्व होता है, जो प्रदर्शन लेबल है, और HostAddress तत्व होता है, जो वह गेटवे है जिससे क्लाइंट वास्तव में संपर्क करता है। लेबल मुक्त पाठ है जिसे कोई भी संपादित कर सकता है, और पता तय करता है कि आप कहाँ पहुँचेंगे।
क्लाइंट खराब है यह निष्कर्ष निकालने से पहले उन दोनों की तुलना उस गेटवे से करें जहाँ आप पहुँचना चाहते थे।
दोनों गेटवे रखना, क्रम से
हर साइट के लिए स्वीकृत प्रोफ़ाइल लें, या तो साइट से या ऐसी मशीन से जो पहले से जुड़ती है। हर फ़ाइल का नाम ऐसे बदलें कि दोनों नाम अलग हों, उदाहरण के लिए site-a.xml और site-b.xml। व्यवस्थापक के रूप में दोनों को पूरी मशीन के प्रोफ़ाइल फ़ोल्डर में रखें और जो मूल प्रतियाँ आपको मिलीं उन्हें सहेजें। फिर क्लाइंट को फिर से शुरू करें और पुष्टि करें कि दोनों प्रविष्टियाँ ड्रॉप-डाउन में दिखती हैं।
हर एक से जुड़ने के बाद preferences.xml फिर से खोलें और देखें कि अब वह किस प्रोफ़ाइल नाम को अंतिम रूप से इस्तेमाल हुआ दर्ज करता है। अगर नाम उस प्रविष्टि से मेल खाता है जिस पर आपने क्लिक किया, तो स्थानीय मैपिंग ठीक व्यवहार कर रही है। अगर नहीं, तो कुछ अब भी आपकी नाम-बदली प्रति के ऊपर फ़ाइल धकेल रहा है।
नाम बदलने से जो ठीक नहीं होता
नया फ़ाइल नाम सिर्फ़ एक स्थानीय लेबल बदलता है और कुछ नहीं। गेटवे का पता, प्रमाणीकरण का तरीका, सर्वर द्वारा प्रस्तुत प्रमाणपत्र और प्रोफ़ाइल के भीतर कोई भी समूह चयन सब वैसे ही रहते हैं। गलत प्रोफ़ाइल की नाम-बदली प्रति अब भी गलत प्रोफ़ाइल है, और वह विश्वसनीय नाम के नीचे आपको गलत साइट से जोड़ेगी।
वह मूल फ़ाइल नाम को लक्षित करने वाले प्रबंधन पुश का भी सामना नहीं करती।
जब अगला पुश इसे रद्द कर देता है
अगर आपका संगठन प्रोफ़ाइल नाम के आधार पर वितरित करता है, तो अपडेट उस नाम वाली हर फ़ाइल को बदल देता है। नाम-बदली प्रतियों को स्थानीय सुविधा मानें और हर क्लाइंट अपडेट के बाद कनेक्शन परीक्षण दोहराएँ, लेबल नहीं पता जाँचते हुए।
स्थायी व्यवस्था के लिए हाथ से फ़ाइलें बनाए रखने के बजाय समर्थित बहु-गेटवे सेटअप माँगें। प्रोग्राम निर्देशिका के अंदर के संपादन वह पहली चीज़ हैं जो अपग्रेड हटाता है, और प्रति-उपयोगकर्ता वरीयता फ़ाइल डिज़ाइन से ही फिर से लिखी जाती है।
हर गेटवे के लिए एक पंक्ति रखें: फ़ाइल नाम, HostAddress और वह किस फ़ोल्डर में है। वह टिप्पणी अगली गलत-साइट रिपोर्ट का जवाब फिर से इंस्टॉल करने से तेज़ देती है।