IPv4 VPN सर्व्हरमधून IPv6 गेल्यावरही खरा IPv6 एक्झिट लागतो

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

लक्षण: पत्ता आहे, मार्ग नाही

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

क्लायंटला हात लावण्यापूर्वी सर्व्हरचा स्वतःचा राउटिंग तक्ता वाचा, कारण मार्गाचा गहाळ अर्धा भाग तिथेच राहतो। एकच IPv4 डीफॉल्ट मार्ग असलेल्या सर्व्हरने तुम्हाला उत्तर आधीच दिले आहे।

डीकॅप्स्युलेशननंतर पॅकेटचा माग घ्या

बोगद्यात पॅकेट सामान्य IPv6 आहे आणि त्याचा स्रोत क्लायंटचा पत्ता आहे। सर्व्हर वाहतूक कॅप्स्युलेशन काढून टाकतो आणि नंतर पुढील IPv6 हॉपला पाठवावे लागणारे मूळ IPv6 पॅकेट धरून ठेवतो। IPv4 डीफॉल्ट मार्ग ते वाहू शकत नाही, आणि त्याचे IPv4 मध्ये भाषांतर करणे हे कोणीही तैनात न केलेले दुसरे कार्य आहे। हेच संपूर्ण अपयश आहे, आणि VPN ऐकणाऱ्याने IPv4 वर उत्तर दिले की नाही याच्याशी त्याचा काहीही संबंध नाही।

IPv4 वर IPv6 च्या कॅप्स्युलेशनची यांत्रिकी RFC 4213 मध्ये वर्णन केली आहे, आणि तिथली महत्त्वाची गोष्ट म्हणजे टोकांना बोगद्याच्या पलीकडे अजूनही खरे IPv6 कनेक्टिव्हिटी लागते। हेडर गुंडाळल्याने अपस्ट्रीम जादूने तयार होत नाही।

दोन बोगदा स्तर, दोन स्वतंत्र तपासण्या

प्रत्येक स्तर स्वतंत्रपणे तपासा, कारण चालणारा बाहेरील बोगदा तुटलेला आतील बोगदा लपवतो। बाहेरील मार्ग क्लायंटपासून सर्व्हरपर्यंत IPv4 पिंगने तपासा आणि तुम्ही वापरत असलेल्या पोर्टची खात्री करा। नंतर सर्व्हरवर आतील मार्ग तपासा, जिथे ip -6 route डीफॉल्ट किंवा खऱ्या अपस्ट्रीमकडून शिकलेला विशिष्ट मार्ग दाखवला पाहिजे, आणि ip -6 addr अपस्ट्रीम स्वीकारतो असा स्रोत प्रीफिक्स दाखवला पाहिजे। त्यापेक्षा कमी काहीही इंटरफेसवरचे सजावट आहे।

युनिक-स्थानिक पत्ता, किंवा जागतिक दिसणारा प्रीफिक्स ज्याकडे काहीही परत राउट होत नाही, आनंदाने इंटरफेसवर दिसेल आणि कुठेही जाणार नाही। सार्वजनिक पोहोच अपस्ट्रीम देतो, पत्त्याचा आकार नाही।

हेच क्लायंटलाही लागू होते: ip -6 route get 2001:4860:4860::8888 बोगदा उपकरणाचे नाव द्यायला हवे, आणि जर ते भौतिक उपकरणाचे नाव देते, तर क्लायंट IPv6 साठी VPN अजिबात वापरत नाही।

स्रोत प्रीफिक्स, आकार आणि ICMPv6

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

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

कोणती पूर्णपणे वेगळी समस्या आहे

फक्त IPv4 चालणाऱ्या अनुप्रयोगापर्यंत फक्त IPv6 चालणाऱ्या क्लायंटपासून पोहोचणे हे भाषांतर आहे, बोगदा नाही, आणि त्यासाठी जाणूनबुजून तैनात केलेल्या NAT64 सारखी व्यवस्था लागते। गंतव्य फक्त तुम्ही एक अतिरिक्त बोगदा हेडर जोडले म्हणून ते समजून घेणार नाही। ऐतिहासिक संक्रमण सेवांनाही तितकीच काळजी हवी: RFC 7526 ने 6to4 anycast रिले मॉडेल रद्द केले, म्हणून त्याभोवती लिहिलेला मार्गदर्शक अशी गोष्ट वर्णन करतो ज्याच्याकडे आता देखभाल केलेला सार्वजनिक रिले नाही।

सर्व्हरकडे वापरण्यायोग्य IPv6 अपस्ट्रीम नसल्यास, पर्याय म्हणजे समर्थित अपस्ट्रीम, दुसरे एक्झिट, किंवा IPv6 बोगद्याबाहेर राहील असा दस्तऐवजी निर्णय। अस्वीकारार्ह गोष्ट म्हणजे क्लायंटना IPv6 सेवा आहे असे सांगणे, तर त्यांचे सामान्य IPv6 कनेक्शन शांतपणे VPN टाळत आहे।