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 स्टैंज़ा ही खोज है, और उसकी जगह टिकट की टिप्पणी में नहीं, व्याख्या के साथ रिकॉर्ड में है। अंतरों के साथ-साथ कच्चे कैप्चर भी सहेजें, क्योंकि अगला समीक्षक देखना चाहेगा कि क्या तुलना की गई। किसी दूसरे विक्रेता पर बराबर की चीज़ उस प्लेटफ़ॉर्म की अपनी सत्र-तालिका और प्रोफ़ाइल निर्यात है, ऐसे प्रारूप में जो मेल नहीं खाएगा, इसलिए पाठ की नहीं, उससे पूछे गए सवालों की तुलना करें।
फिर उपयोगकर्ताओं और उपकरणों को लक्ष्य के नियमों, संसाधन अनुमतियों और अस्वीकृति व्यवहार से जोड़ें। किसी सुविधा को सक्षम करने वाला लाइसेंस उसे लागू करने वाला कॉन्फ़िगरेशन नहीं है, और इन दोनों के बीच का अंतराल ही वह जगह है जहाँ ज़्यादातर माइग्रेशन आश्चर्य रहते हैं।
अस्वीकृति के मामलों को उतनी ही सावधानी से लिखें जितनी अनुमत मामलों को। जो योजना केवल यह साबित करती है कि कोई व्यवस्थापक जुड़ सकता है, उसने सबसे आसान रास्ता जाँचा है और कोई भी सीमा नहीं।
निर्णय के दोनों ओर स्वीकार करें
स्विचओवर से पहले, इच्छित क्लाइंट प्रकारों, प्रमाणीकरण विधियों और संसाधनों पर एक स्वीकृत स्वीकृति योजना चलाएँ। ऐसा उपकरण या पहचान शामिल करें जिसे अस्वीकार होना ही चाहिए, और पुष्टि करें कि किस नियम ने उसे चुना और परिणामी सत्र कहाँ तक पहुँच सकता है। परिवर्तन विंडो खुलने से पहले ही अस्वीकृति के मामलों पर सहमति बनाएँ, ताकि समय के दबाव में कोई उन्हें चुपचाप छोड़ न सके। जिस योजना में अस्वीकृति का कोई मामला नहीं, उसने केवल सुखद रास्ता जाँचा है, और कुछ नहीं।
ऐसा रोलबैक मार्ग और प्रबंधन मार्ग रखें जो माइग्रेट हो रही चीज़ पर निर्भर न हो। कॉन्फ़िगरेशन और पहचान रिकॉर्ड सुरक्षित रूप से सुरक्षित रखें, और अप्रचलित क्रिप्टोग्राफ़िक सेटिंग्स को आगे ले जाने के बजाय पीछे छोड़ दें। लाइसेंस पहचानकर्ता या उपयोगकर्ता रिकॉर्ड कभी सार्वजनिक नोट्स में न चिपकाएँ।
मालिक से हक़ और नीति-मैपिंग पर साथ में हस्ताक्षर कराएँ। पूरा रिकॉर्ड एक साथ दो सवालों का जवाब देता है: संगठन को क्या तैनात करने का लाइसेंस है, और कौन से नियम वास्तव में उसके उपयोगकर्ताओं को प्रवेश देते हैं और सीमित करते हैं।