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

चार स्तंभ, एक चेकलिस्ट नाही

हार्डवेअर किती सहन करू शकते, करार काय परवानगी देतो आणि नियमसंच काय अनुमती देतो हे तीन वेगळे प्रश्न आहेत, आणि ते मिसळल्याने अशी योजना तयार होते जिचे कोणीही ऑडिट करू शकत नाही। ते वेगळ्या स्तंभांत ठेवा आणि प्रत्येकाने आपला स्रोत नमूद करावा। कनेक्शन स्वीकारणारे उपकरण हे सिद्ध करते की उपकरण जोडले जाऊ शकते, आणि ते वैशिष्ट्यांच्या व्याप्तीबद्दल किंवा मोजणीच्या आधाराबद्दल काहीही स्पष्ट करत नाही। परस्पर विसंगत तीन स्तंभ आत्मविश्वासाने वाटणाऱ्या एका परिच्छेदापेक्षा खूप उपयुक्त आहेत।

चारही स्तंभ भरण्याचा हक्क असलेल्या व्यक्तीने ते भरल्यावर नोंद पूर्ण होते। चुकीच्या मालकाने स्वाक्षरी केलेला स्तंभ म्हणजे तारखेसह अफवा।

प्लॅटफॉर्म आणि हक्क

समर्थित गेटवे, क्लायंटच्या ऑपरेटिंग सिस्टम, प्रमाणीकरणाचा मार्ग आणि व्यवस्थापन साधने नोंदवा। जुनी प्रोफाइल अजून उघडते म्हणूनच अप्रचलित क्लायंट जिवंत ठेवू नका, कारण ती प्रोफाइल पुरवठादार आता पाळणार नसलेला सुसंगततेचा दावा आहे। तुम्ही तैनात करण्याच्या तयारीत असलेल्या आवृत्तीशी सध्याचे समर्थन विधान तपासा।

हक्कासाठी उत्पादन, परवान्याचा प्रकार, मुदत आणि मोजणीचा आधार नोंदवा, नंतर खाते मालकामार्फत त्याची जुळवणी करा। ऐतिहासिक सत्र काउंटरवरून हक्क काढणे म्हणजे संस्था स्विचओव्हरपूर्वी नाही तर नंतर तुटवडा शोधते।

पुरवठादारांचे ऑर्डर मार्गदर्शक हे फरक का महत्त्वाचे आहेत हे दाखवतात। उदाहरणार्थ, 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 ब्लॉक हाच शोध आहे, आणि तो तिकिटातील टिप्पणीत नाही तर स्पष्टीकरणासह नोंदीत असावा। फरकांसोबतच कच्चे कॅप्चरही जतन करा, कारण पुढील पुनरावलोककाला काय तुलना केली हे पाहायचे असेल। दुसऱ्या पुरवठादाराकडे समतुल्य गोष्ट म्हणजे त्या प्लॅटफॉर्मचे स्वतःचे सत्र सारणी आणि प्रोफाइल निर्यात, अशा स्वरूपात जे जुळणार नाही, म्हणून मजकुराची नाही तर त्याला विचारलेल्या प्रश्नांची तुलना करा।

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

परवानगी असलेल्या प्रकरणांइतक्याच काळजीने नाकारण्याची प्रकरणे लिहा। व्यवस्थापक जोडू शकतो एवढेच सिद्ध करणारी योजना सर्वात सोपा मार्ग तपासते आणि एकही सीमा नाही।

निर्णयाच्या दोन्ही बाजूंना स्वीकारा

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

माइग्रेट होत असलेल्या गोष्टीवर अवलंबून नसलेला रोलबॅक मार्ग आणि व्यवस्थापन मार्ग ठेवा। कॉन्फिगरेशन आणि ओळख नोंदी सुरक्षितपणे जतन करा, आणि अप्रचलित क्रिप्टोग्राफिक सेटिंग्ज पुढे नेण्याऐवजी मागे सोडा। परवाना ओळखकर्ते किंवा वापरकर्ता नोंदी कधीही सार्वजनिक टिपांमध्ये पेस्ट करू नका।

मालकाने हक्क आणि धोरण-मॅपिंगवर एकत्र स्वाक्षरी करावी। पूर्ण झालेली नोंद एकाच वेळी दोन प्रश्नांची उत्तरे देते: संस्थेला काय तैनात करण्याचा परवाना आहे, आणि कोणते नियम तिच्या वापरकर्त्यांना प्रत्यक्षात प्रवेश देतात आणि मर्यादित करतात।

संबंधित लेख