VPN पर IPv6: प्रत्यायोजित प्रीफ़िक्स कोई पता पूल नहीं है

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

चरण एक: तय करें कि आप कौन-सी भूमिका निभा रहे हैं

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

कोई भी कॉन्फ़िगरेशन खोलने से पहले उस प्रश्न का उत्तर दें। इस चरण के बाद की हर बात इस पर निर्भर है कि आपने कौन-सा उत्तर दिया।

चरण दो: एक अकेले होस्ट के लिए पता आवंटन

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

दोनों सिरों पर पता और मार्ग तालिकाओं से सत्यापित करें, फिर एक अनुरोध भेजें। अगर अनुरोध ठीक से निकलता है और कुछ वापस नहीं आता, तो गड़बड़ी क्लाइंट के पते में नहीं, दूर के सिरे के मार्ग में है।

चरण तीन: टनल के पीछे के राउटर के लिए प्रत्यायोजन

प्रीफ़िक्स प्रत्यायोजन पता आवंटन से अलग तंत्र है, इसका अपना अनुरोध और अपना पट्टा है। प्रत्यायोजक पक्ष को नीचे के नेटवर्क के लिए पर्याप्त बड़ा प्रीफ़िक्स देने के लिए कॉन्फ़िगर किया जाना चाहिए, और अनुरोध करने वाले राउटर को अपना भीतरी इंटरफ़ेस उसी प्रीफ़िक्स से संख्या देनी चाहिए।

यह न मानें कि मोबाइल क्लाइंट की सेवा करने वाला पूल प्रत्यायोजित कर सकता है। कई VPN उत्पाद अकेले पते आवंटित करते हैं और उनकी प्रत्यायोजन की भूमिका ही नहीं होती, और आपके किनारे पर आने वाला प्रदाता प्रीफ़िक्स अपने आप किसी सहकर्मी को नहीं भेजा जाता। लिख लें कि हर पूल कौन-सी भूमिका निभाता है, क्योंकि दोनों अलग जगहों पर कॉन्फ़िगर होते हैं।

चरण चार: वापसी मार्ग को स्पष्ट करें

दोनों सिरों को सहमत होना चाहिए कि कौन-सा सहकर्मी कौन-सा प्रीफ़िक्स ढोता है। दूर के सिरे पर, प्रत्यायोजित नेटवर्क के लिए टनल की ओर इशारा करने वाला मार्ग जोड़ें, और पुष्टि करें कि कोई अतिव्यापी श्रेणी पहले से उस पर दावा नहीं कर रही।

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

चरण पाँच: राउटर के पीछे से सत्यापित करें

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

अंतिम जाँच दो बार करें, एक बार राउटर से ही और एक बार उसके पीछे के उपकरण से। जो राउटर गंतव्य तक पहुँचता है पर उसके क्लाइंट नहीं पहुँच पाते, वह प्रत्यायोजन या अग्रेषण की समस्या है, ऊपर की ओर की समस्या नहीं।

वापस लेना

बदलाव से पहले पिछला पता कॉन्फ़िगरेशन रखें, और लिखें कि दो तंत्रों में से आपने कौन-सा बदला। मार्ग हटाए बिना प्रत्यायोजित प्रीफ़िक्स हटाने से एक काला छेद रह जाता है, और प्रीफ़िक्स के बिना मार्ग हटाने से ऐसे पते रह जाते हैं जहाँ कुछ नहीं पहुँच सकता। दोनों बदलाव अलग-अलग लिखें, क्योंकि एक को वापस लेकर दूसरे को छोड़ देने से साइट केवल एक ही दिशा में अगम्य हो जाती है।

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