OpenVPN लैब में निजी IPv6 जोड़ें, एक बार में एक जाँच बिंदु

आपके पास पहले से एक क्लाइंट है जो IPv4 पर जुड़ता है और सर्वर के पीछे के निजी IPv4 वर्कलोड तक पहुँचता है। लक्ष्य है बाहरी परिवहन को छुए बिना उसी टनल से निजी IPv6 वर्कलोड तक पहुँचना। यह क्रम मायने रखता है: बाहरी मार्ग IPv4 ही रहता है, और केवल भीतरी पता योजना, क्लाइंट का रूट और सर्वर से LAN तक वापसी का रास्ता बदलता है। पाँच जाँच बिंदु, हर एक में आगे बढ़ने से पहले देखने लायक कुछ ठोस।

जाँच बिंदु एक: वह कनेक्शन जो पहले से काम करता है

कुछ भी जोड़ने से पहले क्लाइंट जोड़ें और IPv4 मार्ग की पुष्टि करें। चलती हुई टनल आपको आधार-रेखा देती है जो नई IPv6 गलती को पुरानी कनेक्टिविटी समस्या से अलग करती है। यह यह भी बताती है कि आप वास्तव में कौन-सा सर्वर इंस्टेंस संपादित कर रहे हैं।

उस पूल, टोपोलॉजी और पुश किए गए रूटों को नोट करें जिन पर आप पहले से निर्भर हैं। IPv6 का काम उस कॉन्फ़िगरेशन का विस्तार करता है; उसे बदलता नहीं।

जाँच बिंदु दो: भीतरी प्रीफ़िक्स चुनें

साइट के लिए एक ULA /48 चुनें और उसमें से दो /64 काटें: एक टनल क्लाइंट के लिए, एक उस LAN सेगमेंट के लिए जिसमें IPv6 वर्कलोड है। उदाहरण प्रीफ़िक्स कॉपी करने के बजाय 40-बिट वैश्विक ID उत्पन्न करें, और दोनों सबनेट को हर उस नेटवर्क के विरुद्ध जाँचें जिसे साइट पहले से रूट करती है:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

दो स्वतंत्र /64 क्लाइंट पूल को LAN सेगमेंट से कटने से रोकते हैं, जो बाद में वापसी रूट लिखते समय मायने रखता है। ऊपर के मान एक हल किया गया उदाहरण हैं, दोबारा उपयोग का प्रीफ़िक्स नहीं।

जाँच बिंदु तीन: सहायक और रूट पुश जोड़ें

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

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

पहली एक सुविधाजनक सहायक है जो इंटरफ़ेस और क्लाइंट पूल सेट करती है। दूसरी उस LAN गंतव्य का नाम लेती है जहाँ क्लाइंट को पहुँचना है। क्लाइंट को IPv6 पता देना यह नहीं बताता कि सर्वर के पीछे कौन-से नेटवर्क हैं, इसलिए दोनों पंक्तियाँ ज़रूरी हैं।

सहायक स्थिर IPv6 पूल के साथ या nopool के साथ सह-अस्तित्व नहीं रखता। यदि परिनियोजन जानबूझकर पते स्थिर रूप से आवंटित करता है, तो वह नीति रखें और उदाहरण में फ़िट करने के लिए नीति हटाने के बजाय IPv6 समकक्ष को स्पष्ट रूप से डिज़ाइन करें।

जाँच बिंदु चार: फ़ॉरवर्डिंग और उत्तर का रूट

सर्वर पर IPv6 फ़ॉरवर्डिंग सिस्टम के अपने कॉन्फ़िगरेशन स्वामी के माध्यम से चालू करें, न कि ऐसे एकबारगी रनटाइम लेखन से जिसे आप भूल जाएँगे। रनटाइम रूप तेज़ परीक्षण के लिए उपयोगी है। स्थायी कॉन्फ़िगरेशन उस drop-in फ़ाइल में जाता है जिसे वितरण का नेटवर्क स्वामी पढ़ता है:

sysctl -w net.ipv6.conf.all.forwarding=1

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

फिर LAN को टनल पूल तक वापसी का रूट दें। वर्कलोड का IPv6 गेटवे VPN सर्वर नहीं बल्कि LAN राउटर है, इसलिए रूट उसी राउटर पर रहता है और सर्वर के LAN पते की ओर इंगित करता है:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

लिंक को ज़रूरी ICMPv6 प्रकार रखें, जिसमें पथ-MTU प्रतिक्रिया भी शामिल है। IPv4 फ़ायरवॉल नियम IPv6 नियम नहीं दर्शाता, और व्यापक IPv6 अवरोध पड़ोसी खोज को ऐसे तोड़ता है जो रूटिंग खराबी जैसा दिखता है।

जाँच बिंदु पाँच: क्लाइंट पढ़ें, फिर परीक्षण करें

क्लाइंट को फिर से जोड़ें और सर्वर के सहायक पते से अनुमान लगाने के बजाय वे पते पढ़ें जो उसे वास्तव में मिले। इंटरफ़ेस सूची एक ही डिवाइस पर दोनों परिवार दिखाती है:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

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

एप्लिकेशन को हर परिवार पर बारी-बारी परखें, फिर दोबारा कनेक्ट और होस्ट रीस्टार्ट के बाद दोहराएँ। केवल रीबूट तक टिकने वाला रूट या sysctl परीक्षण है, डिज़ाइन नहीं।

AAAA रिकॉर्ड तभी प्रकाशित करें जब IPv6 पथ शुरू से अंत तक उत्तर दे। IPv4 पर पूछा गया DNS अब भी IPv6 पता लौटा सकता है, इसलिए हल होने योग्य नाम इस बात का प्रमाण नहीं कि कुछ सुन रहा है। RFC 4193 ULA मार्गदर्शन वैश्विक ID बनाने को कवर करता है जो इन प्रीफ़िक्स को नकल नहीं बल्कि आपका बनाता है।