IPv4 VPN सर्वर से IPv6 जाने पर भी असली IPv6 एग्ज़िट चाहिए
IPv4 सुरंग के अंदर 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 को दरकिनार कर रहा हो।