अपने /64 को विभाजित करना IPv6 को VPN क्लाइंट तक रूट नहीं करता

क्लाइंट वैश्विक IPv6 पता दिखाता है, हैंडशेक पूरा हो चुका है, और इंटरनेट से कुछ भी वापस नहीं आता। पूल सेटिंग सही दिखती है क्योंकि वह सही है; पता वैध है और टनल उसे ले जाती है। जो विफल होता है वह है डिलीवरी, और डिलीवरी VPN सर्वर के ऊपर लिए गए उस निर्णय पर निर्भर करती है जिसे कोई भी क्लाइंट-साइड कॉन्फ़िगरेशन प्रभावित नहीं कर सकता।

मिथक: आपका /64 का एक हिस्सा पहले से ही पहुँच योग्य है

कहानी आकर्षक है: सर्वर के पास एक सार्वजनिक /64 है, उसे आधा काटें, दूसरा आधा VPN पूल को दें, और वे क्लाइंट अब इंटरनेट पर हैं। प्रीफ़िक्स को विभाजित करना टकराव के बिना पते आवंटित करता है। लेकिन यह नहीं बदलता कि अपस्ट्रीम नेटवर्क तय करता है कि उन पतों में से किसी एक के लिए पैकेट कहाँ जाना चाहिए।

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

यही पूरी विफलता है: आगे की दिशा काम करती है क्योंकि आपका सर्वर उसे भेजता है, और वापसी दिशा एक हॉप दूर मर जाती है क्योंकि अपस्ट्रीम को कभी पता ही नहीं चला कि क्लाइंट मौजूद है।

लिंक पर डिलीवरी वास्तव में क्या माँगती है

जब अपस्ट्रीम पूरे /64 को भौतिक लिंक पर मानता है, तो वह प्रत्येक गंतव्य पते को पड़ोसी खोज से हल करता है। वह उस लिंक पर एक अनुरोध भेजता है और अपेक्षा करता है कि पते का मालिक उत्तर देगा। टनल के पीछे बैठा VPN क्लाइंट उस लिंक पर नहीं है और उत्तर नहीं दे सकता, इसलिए अनुरोध बिना उत्तर रह जाता है और पैकेट गिरा दिया जाता है।

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

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

रूटेड डिलीवरी क्या माँगती है

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

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

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

दो स्वतंत्र रूट सही करने हैं

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

ऊपर का प्रीफ़िक्स दस्तावेज़ीकरण स्थान है, और रीडायरेक्ट केवल IPv6 पर लागू होता है, जो ड्यूअल-स्टैक तैनाती अक्सर तब चाहती है जब IPv6 डिलीवरी अभी ठीक की जा रही हो। IPv4 रीडायरेक्ट IPv6 कवरेज स्थापित नहीं करता, और कोई भी सेटिंग दूसरे को निहित नहीं करती।

आप जो भी नीति लागू करें, IPv6 जिस नियंत्रण ट्रैफ़िक पर निर्भर है उसे चालू रखें। Packet Too Big संदेश उस फ़ायरवॉल के पुराने शिकार हैं जो केवल TCP और UDP की अनुमति देता है, और उन्हें गिराने से ऐसे कनेक्शन बनते हैं जो स्थापित होकर बड़े स्थानांतरणों में अटक जाते हैं।

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

डिज़ाइन दर्ज करें ताकि पुनर्निर्माण उसे दोहराए

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

फिर वापसी दिशा का स्पष्ट रूप से परीक्षण करें, ऐसे पैकेट से जिसे बाहर से लौटना ही है। openvpn(8) मैनुअल server-ipv6 और redirect विकल्पों को कवर करता है, और आपके प्रदाता की रूटिंग पुष्टि उस आधे हिस्से को कवर करती है जो मैनुअल नहीं कर सकता।