कसैले तपाईंलाई .pcf फाइल र ल्यापटप दिन्छ र वर्षौं अघि जस्तै जडान काम गर्ने अपेक्षा गर्छ। सामान्यतया त्यसो हुँदैन, र फाइलको ढाँचा विरलै कारण हुन्छ। PCF ले एक विशेष केन्द्रकसम्म पुग्न पुरानो Cisco VPN Client लाई आवश्यक पर्ने प्यारामिटरहरू अभिलेख गर्छ; वर्तमान क्लाइन्ट अझै त्यो सेवासँग बोल्न सक्छ कि भन्ने कुरा यसले बताउँदैन। फाइल विगतको जडानको प्रमाण हो, अर्कोको सम्झौता होइन।

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

तपाईंको हातको फाइलले वास्तवमा के अभिलेख गर्छ

PCF जडान प्रविष्टिहरूको सानो प्रोफाइल हो: एउटा होस्ट वा प्राथमिक र ब्याकअप जोडी, एउटा समूह नाम, र क्लाइन्टले प्रमाणहरू कसरी प्रस्तुत गर्नुपर्ने भन्ने सङ्केत। यसमा प्रोटोकल वार्ता छैन, विश्वास निर्णय छैन र गेटवेको वर्तमान क्षमताको कुनै कथन छैन। यसलाई पढ्दा पुरानो क्लाइन्टले कहाँ र कुन समूह नाममा डायल गर्थ्यो थाहा हुन्छ, र त्यो भाग प्रमुख टुप्पोको मालिकका लागि साँच्चै उपयोगी सन्दर्भ हो।

यसले बताउन नसक्ने कुरा हो — त्यो होस्टनाम पछाडिको सेवाले अझै त्यही प्रोटोकल स्वीकार्छ कि, वा खाता सङ्केतसँग मिल्ने रूपमा रहेको छ कि। ती उत्तरहरू गेटवेमा र पहिचान भण्डारमा हुन्छन्, त्यसैले बनाउनु अघि त्यहीँ सोध्नुहोस्।

एउटै जस्तो देखिने तीन आवश्यकता

पहिलो आवश्यकता तारसम्बन्धी अनुकूलता हो: क्लाइन्टले गेटवेले अन्त्य गर्ने टाढा-पहुँच प्रोटोकल लागू गर्नुपर्छ। दोस्रो प्रमाणीकरण हो, जहाँ गेटवेले माग्ने विधि — प्रमाणपत्र, समूह प्रमाण र MFA, वा EAP — क्लाइन्टले वास्तवमै सम्पादन गर्न सक्ने हुनुपर्छ। तेस्रो नीति हो: विभाजित सुरुङ, DNS, ठेगाना पूल र कुनै पनि अवस्था जाँच, सबै गेटवेमा कन्फिगर गरी क्लाइन्टले स्वीकार गर्नुपर्ने प्रोफाइलमा पुर्याइन्छ।

PCF ले दोस्रो आवश्यकताबारे कमजोर प्रमाण दिन्छ र अरू दुईबारे व्यावहारिक रूपमा केही दिँदैन। आयात सुविधाले सीमा अझ धमिलो बनाउँछ: पुराना फिल्डलाई आफ्नै ढाँचामा म्याप गर्ने क्लाइन्ट आयातमा सफल भएर जडानमा असफल हुन सक्छ, र उल्टो पनि सम्भव छ।

उपयोगी उत्तर दिने पाँच प्रश्न

फाइलको सट्टा प्रश्नहरू पठाउनुहोस्। आज कुन टाढा-पहुँच सेवा र क्लाइन्ट संयोजन समर्थित छ; त्यो सेवाले इन्टरनेटमा कुन प्रोटोकल प्रस्तुत गर्छ; कुन प्रमाणीकरण विधि र दर्ता मार्ग लागू हुन्छ; यससँग कुन प्रोफाइल, विश्वास आधार र समूह वा MFA नीति सम्बन्धित छ; र कुन भागहरू पुरानो जडानभन्दा फरक छन्। प्रत्येक उत्तर माथिका तीन आवश्यकतामध्ये एकसँग मिल्छ।

यो सूचीले फाइल ढाँचाबारेको छलफललाई समर्थनबारेको निर्णयमा बदल्छ, र सामान्यतया काँध हल्लाउने सट्टा कागजात लिङ्क र नाम खुलेको जिम्मेवार व्यक्ति फर्काउँछ। स्थानान्तरण अवस्थित सेवाविरुद्ध नयाँ प्रोफाइल हो कि अझै कसैले योजना नगरेको गेटवे परिवर्तन हो, त्यो पनि यसले चाँडै बताउँछ। लिखित रूपमा सोध्नुहोस्, किनकि उत्तरहरू अगाडि तपाईंले बनाउने कुराको स्वीकृति मापदण्ड बन्छन्। पुरानो समूह नाम टिकटमा पनि राख्नुहोस्, किनकि अपरेटरलाई मिल्ने नीति भेट्टाउने सबैभन्दा छिटो बाटो प्रायः यही हुन्छ।

नाम बदल्दा केही पनि अनुवाद हुँदैन

Cisco Secure Client ले आफ्नै प्रोटोकल विकल्पसहित XML प्रोफाइल कागजातीकरण गर्छ, त्यसैले .pcf को नाम बदलेर .xml गर्दा न XML बन्छ न सेटिङ। OpenVPN फाइलमा होस्टनाम टाँस्दा IPsec गेटवे OpenVPN बोल्न थाल्दैन, र मूल IKEv2 क्लाइन्ट दुवैलाई IPsec भनिन्छ भनेर मात्र पुरानो सेवासँग अनुकूल हुँदैन।

यी प्रत्येक कदमले एउटा लेबल बदल्छ र तारको व्यवहारलाई छुँदैन, त्यसैले परिणामस्वरूप हुने खराबी सम्पादनसँग असम्बन्धित देखिन्छ। गेटवेले नयाँ क्लाइन्टले लागू गर्ने कुरा दिन नसक्दा, इमानदार विकल्प भनेको अझै पुरानो प्रोटोकल बोल्ने क्लाइन्ट वा योजनाबद्ध गेटवे स्थानान्तरण हो। दुईबीच अनुमान गर्दा हप्ता बित्छ र केही सिकिँदैन।

पुरानो प्रोफाइललाई संवेदनशील सामग्री मान्नुहोस्

पुरानो प्रोफाइलमा आन्तरिक होस्टनाम, समूह नाम र कहिलेकाहीँ भण्डारण गरिएको प्रमाण सामग्री हुन सक्छ, जुन सार्वजनिक कन्भर्टर र फोरम थ्रेडले सङ्कलन गर्ने वस्तुकै ठ्याक्कै रूप हो। फाइल कतै अपलोड गर्नुको सट्टा प्रशासकलाई स्वीकृत माध्यमबाट फिल्ड पढ्न दिनुहोस्।

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

सम्बन्धित लेखहरू