OpenVPN सुरंग से IPv6: घरेलू राउटर के लिए चरण-दर-चरण मार्गदर्शिका

लैपटॉप के पास IPv6 पता है, सुरंग IPv4 पर चालू है, फिर भी हर IPv6 परीक्षण विफल होता है। या इससे भी बुरा: परीक्षण सफल हो जाता है और ट्रैफ़िक सुरंग में कभी प्रवेश किए बिना ISP के रास्ते से बाहर चला जाता है। दोनों नतीजे एक ही गुम निर्णय की ओर लौटते हैं: किसी ने राउटर को ऐसा उपसर्ग नहीं दिया जिसे वह क्लाइंट की ओर रूट कर सके। क्लाइंट से बाहर की ओर रास्ता चलने पर पता चलता है कि कौन-सा टुकड़ा गुम है।

वहीं से शुरू करें जहाँ क्लाइंट है

सर्वर को छूने से पहले क्लाइंट देखें। ip -6 addr को पूल से सुरंग पता दिखाना चाहिए, और ip -6 route को सुरंग उपकरण की ओर इशारा करता धकेला गया उपसर्ग दिखाना चाहिए। जब पता हो पर रूट न हो, तो धक्का गुम है या क्लाइंट ने उसे अनदेखा किया। जब दोनों में से कोई न हो, तो सर्वर ने बिलकुल कुछ भी आवंटित नहीं किया।

फिर देखें कि क्लाइंट बाहरी दुनिया के बारे में क्या मानता है। सुरंग पर डिफ़ॉल्ट रूट सारा IPv6 ट्रैफ़िक दावा करता है, जबकि 2000::/3 के लिए रूट केवल वैश्विक यूनिकास्ट का दावा करता है। दोनों सही हो सकते हैं, और वे लीक के बारे में अलग-अलग सवालों के जवाब देते हैं।

बिना किसी IPv6 डिफ़ॉल्ट वाला क्लाइंट हर सार्वजनिक परीक्षण में विफल होता है जबकि सुरंग खुद पूरी तरह स्वस्थ है। यह नीति की खाई है, टूटी सुरंग नहीं।

वह पूल जाँचें जिसे सर्वर वास्तव में रूट कर सकता है

सर्वर केवल उसी उपसर्ग से आवंटित कर सकता है जिसे वह वास्तव में नियंत्रित करता है। अगर ISP /56 प्रत्यायोजित करता है, तो सुरंग के लिए एक /64 आरक्षित रखें और बाकी LAN के लिए छोड़ दें। जहाँ ISP WAN पर केवल एक /64 सौंपता है और आगे कुछ रूट नहीं करता, वहाँ LAN उपसर्ग को छोड़ दें और सुरंग को एक अद्वितीय स्थानीय श्रेणी दें, यह स्वीकार करते हुए कि क्लाइंट के पास कोई वैश्विक निकास नहीं होगा।

पूल और धक्का साथ चलते हैं। server-ipv6 2001:db8:80:10::/64 पते आवंटित करता है, और push "route-ipv6 2000::/3" क्लाइंट को बताता है कि सुरंग में क्या भेजना है। 2000::/3 धकेलने से वैश्विक यूनिकास्ट ढक जाता है और link-local तथा multicast श्रेणियाँ सुरंग से बाहर रहती हैं।

चुना गया उपसर्ग तैनाती रिकॉर्ड में लिखें। अगली बार ISP हैंडऑफ़ बदलने वाले को जानना होगा कि सुरंग कौन-सा /64 पहले से रखती है।

दूसरे परिवार के लिए फ़ॉरवर्डिंग चालू करें

IPv4 फ़ॉरवर्डिंग का अर्थ IPv6 फ़ॉरवर्डिंग नहीं है। net.ipv6.conf.all.forwarding=1 सेट करें और वह सब दोहराएँ जो IPv4 FORWARD नीति पहले से अनुमति देती है। ऐसे राउटर पर जिसकी FORWARD श्रृंखला डिफ़ॉल्ट रूप से गिरा देती है, नियम-समूह का गुम होना ठीक मृत सुरंग जैसा दिखता है।

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

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

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

जब ऊपरी छोर रूट न करे तो पड़ोसी खोज का जवाब दें

ऊपरी छोर का उपकरण कभी-कभी प्रत्यायोजित /64 को अपने ही लिंक का मानता है और VPN बॉक्स की ओर कोई उप-उपसर्ग रूट करने से मना कर देता है। ऐसा होने पर किसी को हर क्लाइंट पते के लिए अलग-अलग पड़ोसी अनुरोधों का जवाब देना पड़ता है।

OpenVPN आवंटित पते को client-connect हुक के सामने रखता है, इसलिए प्रविष्टियाँ हाथ से रखी सूची के बजाय असली पूल का पालन कर सकती हैं। हुक ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 जोड़ता है, और मेल खाता client-disconnect हुक उसे हटा देता है। हटाने के बिना प्रॉक्सी तालिका पुरानी पड़ जाती है और बाद का क्लाइंट ऐसे पते की प्रविष्टि विरासत में पा सकता है जो उसे कभी मिला ही नहीं। ip -6 neigh show proxy से स्थिति की पुष्टि करें।

प्रॉक्सी को एक कामचलाऊ उपाय मानें। सुरंग के /64 के लिए राउटर की ओर इंगित स्थिर रूट क्लाइंट बदलावों को सह लेता है और विशेषाधिकार प्राप्त शेल हुक की ज़रूरत ही नहीं पड़ती।

बाहर की ओर रास्ता फ़ॉलो करें, एक-एक हॉप

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

सुरंग के MTU पर नज़र रखें, क्योंकि रास्ते के IPv6 राउटर आपके लिए विखंडन नहीं करेंगे। बहुत बड़ा MTU स्वच्छ विफलता के बजाय packet-too-big त्रुटि और अटका TLS बनकर दिखता है। इसे स्पष्ट रूप से सेट करें और सीमा के करीब पेलोड से परीक्षण करें।