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 र त्यो कुन फोल्डरमा छ। त्यो टिप्पणीले अर्को गलत-साइट रिपोर्टलाई पुनःस्थापना भन्दा छिटो जवाफ दिन्छ।