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

एकाच दिवशी दोन विनंत्या येतात: लॅपटॉपला बोगद्यावरून IPv6 हवे, आणि एका लहान साइटला तिच्या राउटरमागील उपकरणांसाठी IPv6 हवे। दोन्हींना पत्त्याने उत्तर दिले जाते, आणि दुसरे नंतर एक आठवडा अयशस्वी होण्यात घालवते। भूमिका वेगळ्या आहेत, आणि तसेच यंत्रणा, संरचना आणि ते काम करते हे सिद्ध करणारी तपासणी। हे मार्गदर्शक त्यांना वेगळे ठेवते।

पायरी एक: तुम्ही कोणती भूमिका निभावता ते ठरवा

एका एकट्या होस्टला त्याच्या बोगदा इंटरफेसवर एक पत्ता हवा, दूरच्या बाजूला मार्ग आणि खाली क्रमांक देण्यासारखे काहीही नाही। बोगद्यामागील राउटरला वाटून देता येईल असे संपूर्ण नेटवर्क हवे, शिवाय दूरच्या बाजूला ते पत्ते त्याच्याकडे परत पाठवणारा मार्ग हवा। बोगद्यामागे काय आहे यावर पुढील प्रत्येक निर्णय ठरतो।

कोणतीही संरचना उघडण्यापूर्वी त्या प्रश्नाचे उत्तर द्या। या पायरीनंतरचे सर्व काही तुम्ही कोणते उत्तर दिले यावर अवलंबून आहे।

पायरी दोन: एका एकट्या होस्टसाठी पत्ता वाटप

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

दोन्ही टोकांना पत्ता आणि मार्ग तक्त्यांनी तपासा, नंतर एक विनंती पाठवा। विनंती योग्यरीत्या बाहेर पडली आणि काहीही परत आले नाही तर दोष क्लायंटच्या पत्त्यात नसून दूरच्या बाजूच्या मार्गात आहे।

पायरी तीन: बोगद्यामागील राउटरसाठी प्रत्यायोजन

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

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

पायरी चार: परतीचा मार्ग स्पष्ट करा

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

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

पायरी पाच: राउटरच्या मागून तपासा

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

शेवटची तपासणी दोन वेळा करा, एकदा राउटरकडूनच आणि एकदा त्याच्या मागील उपकरणाकडून। गंतव्यापर्यंत पोहोचणारा पण त्याचे क्लायंट पोहोचू न शकणारा राउटर ही प्रत्यायोजन किंवा अग्रेषणाची समस्या आहे, वरची समस्या नाही।

परत आणणे

बदलापूर्वी मागील पत्ता संरचना जतन करा, आणि दोन यंत्रणांपैकी तुम्ही कोणती बदलली ते नोंदवा। मार्ग न काढता प्रत्यायोजित प्रीफिक्स काढल्यास काळे भोक राहते, आणि प्रीफिक्सशिवाय मार्ग काढल्यास काहीही पोहोचू न शकणारे पत्ते राहतात। दोन्ही बदल वेगळे नोंदवा, कारण एक परत आणून दुसरा ठेवल्यास साइट फक्त एकाच दिशेने पोहोचण्यायोग्य राहत नाही।

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