तपाईंको /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 विकल्प समेट्छ, र तपाईंको प्रदायकको रुटिङ पुष्टिले पुस्तिकाले समेट्न नसक्ने आधा भाग समेट्छ।