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 माथि बोकिन्छ वर्णन गर्छ, जुन दुई तह सधैं छुट्टै निर्णय थिए भन्ने उपयोगी सम्झना हो। यदि सूचीमा तपाईंले व्याख्या गर्न नसक्ने पङ्क्ति छ भने, रोक्नुहोस् र त्यसमा के निर्भर छ पत्ता लगाउनुहोस्। सूची नीरस भएपछि स्थानान्तरण पूरा हुन्छ।