PPP-आधारित VPN से उसकी मान्यताओं को दोहराए बिना पलायन

VPN माइग्रेशन तब पूरा होता है जब उपयोगकर्ता, गंतव्य, नाम-विश्लेषण और विफलता व्यवहार सब अब भी सही हों, तब नहीं जब नया क्लाइंट हरा आइकन दिखाए। पुराने PPP-आधारित परिनियोजन ऐसी मान्यताएँ ढोते हैं जो कभी लिखी नहीं गईं: एक साझा रहस्य जो एकमात्र पहचान जाँच भी था, एक स्थिर पता पूल जिसे फ़ायरवॉल अनुमत सूची में रखता है, एक DNS प्रत्यय जो सर्वर भेजता है। उन मान्यताओं की सूची बनाए बिना प्रोटोकॉल बदलने से ऐसा टनल मिलता है जो हैंडशेक पूरा करता है और ऐसी सीमा जो मौजूद ही नहीं है। नीचे दिया क्रम वही है जो मैं उपयोग करता हूँ, और अंतिम चरण वही है जिसे टीमें छोड़ देती हैं।

चरण 1: सूची बनाएँ कि पुराना कनेक्शन क्या देता है

सूची याद नहीं रखी जाती, लिखी जाती है। समर्थित क्लाइंट, प्रमाणीकरण की भूमिकाएँ, पता पूल, संरक्षित नेटवर्क, DNS आवश्यकताएँ और हर उपयोगकर्ता समूह को चाहिए सेवा अनुमतियाँ दर्ज करें।

L2TP/IPsec के लिए दोनों परतों को स्पष्ट रूप से अलग करें। IPsec पीयर की पहचान मशीनों को प्रमाणित करती है; PPP उपयोगकर्ता को प्रमाणित करता है, आमतौर पर CHAP या MSCHAPv2 से।

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

चरण 2: प्रतिस्थापन को जानबूझकर डिज़ाइन करें

प्रतिस्थापन चुनना आवश्यकता-दर-आवश्यकता मैपिंग है: एक प्रोटोकॉल और एक अनुरक्षित क्लाइंट जिसे संगठन समर्थन देता है, और हर पहचान व एक्सेस आवश्यकता किसी वास्तविक तंत्र में उतरती है। साझा रहस्य अपने आप प्रति-डिवाइस कुंजी या प्रमाणपत्र के बराबर नहीं होता, और प्रति-उपयोगकर्ता PPP खाता डिवाइस प्रमाणपत्र के बराबर नहीं होता।

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

चरण 3: चरणबद्ध लागू करें और अनुमति व निषेध दोनों सत्यापित करें

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

फिर ऐसा गंतव्य जाँचें जो निषिद्ध ही रहना चाहिए। व्यापक अस्थायी अनुमति नियम नए टनल को स्वस्थ दिखा सकता है जबकि वह चुपचाप वह प्राधिकरण सीमा हटा देता है जो पुरानी सेवा लागू करती थी, और ऑडिट तक किसी को पता नहीं चलता। अनुमति और निषेध परिणामों की तुलना साथ-साथ करें, उसी क्लाइंट से, उसी सत्र में। दोनों स्तंभ डिज़ाइन से मेल खाने तक पुरानी सेवा चलती रखें।

व्यवस्थापक पहुँच स्थानांतरित करने से पहले पुष्टि करें कि आपके पास अधिकृत पुनर्प्राप्ति मार्ग है जो उस टनल पर निर्भर नहीं है जिसे आप बदल रहे हैं।

चरण 4: पुरानी पहचान को सेवानिवृत्त करें

पुरानी पहचान को ठीक से सेवानिवृत्त करने का अर्थ है पुराने उपयोगकर्ताओं और डिवाइस क्रेडेंशियल को उस सेवा के माध्यम से रद्द करना जो उनकी मालिक है, फिर कोई निर्भरता न बचने पर पुरानी प्रोफ़ाइल और श्रोताओं को हटाना। स्थानीय फ़ाइल मिटाना कहीं और की प्रति को रद्द नहीं करता, और पुराना साझा रहस्य अब भी स्वीकार करने वाला पुराना श्रोता बिना निगरानी का दरवाज़ा है।

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

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

परिणाम को प्रोटोकॉल के नाम के बजाय सेवा की ज़रूरत से बाँधे रखें, क्योंकि पुरानी मान्यताएँ भीतर दोहराया गया आधुनिक प्रोटोकॉल बेहतर ढाँचे के साथ वही जोखिम है। RFC 3193 बताता है कि L2TP को IPsec पर कैसे ढोया जाता है, जो यह याद दिलाता है कि दोनों परतें हमेशा अलग निर्णय थीं। अगर सूची में कोई पंक्ति ऐसी है जिसे आप समझा नहीं सकते, तो रुकें और पता करें कि उस पर क्या निर्भर है। सूची उबाऊ हो जाने पर माइग्रेशन पूरा होता है।