VPN माइग्रेसन: इजाजतपत्र, सुविधा र नीति एउटै अभिलेखमा

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

चार स्तम्भ, एउटा जाँचसूची होइन

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

चारै स्तम्भ भर्ने हक भएको व्यक्तिले भर्दा अभिलेख पूरा हुन्छ। गलत मालिकले हस्ताक्षर गरेको स्तम्भ मिति भएको हल्ला हो।

प्लेटफर्म र हक

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

हकका लागि उत्पादन, इजाजतपत्रको प्रकार, अवधि र गणनाको आधार अभिलेख गर्नुहोस्, त्यसपछि खाता मालिकमार्फत मिलाउनुहोस्। ऐतिहासिक सत्र काउन्टरबाट हक निकाल्नु भनेको संस्थाले स्विचओभरपछि कमी भेट्टाउने तरिका हो, अघि होइन।

आपूर्तिकर्ताका अर्डर मार्गदर्शिकाले यी भिन्नता किन महत्त्वपूर्ण छन् देखाउँछन्। उदाहरणका लागि, Ciscoको Secure Client अर्डर मार्गदर्शिका ले Advantage, Premier र VPN Only तहहरू छुट्याउँछ, प्रत्येकको आफ्नै मापन र सुविधा-दायरा। पुरानो लेबलको यान्त्रिक अनुवाद गर्नुको सट्टा हालको सम्झौता प्रयोग गर्नुहोस्।

सुविधा र लागू नीति

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

जब लक्ष्य ASA हुन्छ, सुविधा स्तम्भ सम्झौताबाट होइन उपकरणबाट पढिन्छ, त्यसैले स्विचओभरको दिनअघि गेटवे क्याप्चर गर्नुहोस्। show vpn-sessiondb summary ले जीवित सत्रको सूची र तपाईंको हक जुन संख्यासँग मापन हुन्छ त्यो दिन्छ, show vpn-sessiondb detail anyconnect ले प्रत्येक आरोपित सत्रले वास्तवमा कुन ग्राहक प्रकार र प्रोफाइल प्रयोग गर्यो देखाउँछ, र show running-config webvpn ले ती सत्र निर्भर गेटवे कन्फिगरेसन क्याप्चर गर्छ, र यो अभिलेखको त्यो एउटै भाग हो जुन कुनै इजाजतपत्र कागजातमा हुन सक्दैन।

show vpn-sessiondb summary
show vpn-sessiondb detail anyconnect
show running-config webvpn

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

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

अनुमति दिइएका केसजत्तिकै होसियारीसाथ अस्वीकारका केस लेख्नुहोस्। प्रशासक जोडिन सक्छ भनेर मात्र प्रमाणित गर्ने योजनाले सबैभन्दा सजिलो मार्ग परीक्षण गरेको छ, कुनै सीमा होइन।

निर्णयका दुवै पक्षमा स्वीकार गर्नुहोस्

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

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

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