OpenVPN प्रयोगशालामा निजी IPv6 थप्नुहोस्, एक पटकमा एउटा जाँच बिन्दु

तपाईंसँग पहिले नै एउटा ग्राहक छ जसले IPv4 मार्फत जोडिन्छ र सर्भरको पछाडिको निजी IPv4 कार्यभारसम्म पुग्छ। लक्ष्य भनेको बाहिरी यातायात नछोई उही सुरुङबाट निजी IPv6 कार्यभारसम्म पुग्नु हो। त्यो क्रम महत्त्वपूर्ण छ: बाहिरी बाटो IPv4 नै रहन्छ, र भित्री ठेगाना योजना, ग्राहकको रुट र सर्भरबाट LAN सम्म फर्कने बाटो मात्र बदलिन्छ। पाँच जाँच बिन्दु, प्रत्येकमा अगाडि बढ्नुअघि हेर्नुपर्ने ठोस कुरा छ।

जाँच बिन्दु एक: पहिले नै चलिरहेको जडान

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

तपाईं पहिले नै भरोसा गर्ने पूल, टोपोलोजी र पुश गरिएका रुटहरू टिप्नुहोस्। IPv6 कामले त्यो कन्फिगरेसन विस्तार गर्छ; प्रतिस्थापन गर्दैन।

जाँच बिन्दु दुई: भित्री प्रिफिक्स छान्नुहोस्

साइटका लागि एउटा ULA /48 छान्नुहोस् र त्यसबाट दुई /64 काट्नुहोस्: एउटा सुरुङ ग्राहकका लागि, एउटा IPv6 कार्यभार भएको LAN खण्डका लागि। उदाहरण प्रिफिक्स प्रतिलिपि गर्नुको सट्टा 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 परीक्षण हो, डिजाइन होइन।

IPv6 बाटो सुरुदेखि अन्त्यसम्म जवाफ दिएपछि मात्र AAAA रेकर्ड प्रकाशित गर्नुहोस्। IPv4 बाट सोधिएको DNS ले अझै IPv6 ठेगाना फर्काउन सक्छ, त्यसैले समाधान हुने नाम कुनै कुरा सुनिरहेको प्रमाण होइन। RFC 4193 ULA मार्गदर्शन ले यी प्रिफिक्सलाई प्रतिलिपि होइन तपाईंको बनाउने विश्वव्यापी ID उत्पादन समेट्छ।