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

लक्षण: ठेगाना छ, बाटो छैन

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

क्लाइन्ट छुनुअघि सर्भरको आफ्नै राउटिङ तालिका पढ्नुहोस्, किनकि मार्गको हराएको आधा भाग त्यहीँ बस्छ। एउटै IPv4 पूर्वनिर्धारित मार्ग भएको सर्भरले तपाईंलाई उत्तर पहिले नै दिइसकेको छ।

डिक्याप्सुलेसनपछि प्याकेटलाई पछ्याउनुहोस्

सुरुङभित्र प्याकेट साधारण IPv6 हो र त्यसको स्रोत क्लाइन्टको ठेगाना हो। सर्भरले यातायात क्याप्सुलेसन हटाउँछ र त्यसपछि अर्को IPv6 हपमा पठाउनुपर्ने मूल IPv6 प्याकेट समात्छ। IPv4 पूर्वनिर्धारित मार्गले त्यो बोक्न सक्दैन, र त्यसलाई IPv4 मा अनुवाद गर्नु अरू कसैले तैनाथ नगरेको फरक कार्य हो। यही नै सम्पूर्ण असफलता हो, र VPN सुन्नेले IPv4 मार्फत जवाफ दियो कि दिएन भन्नेसँग यसको कुनै सम्बन्ध छैन।

IPv4 माथि IPv6 क्याप्सुलेसनको यान्त्रिकी RFC 4213 मा वर्णन गरिएको छ, र त्यहाँको महत्त्वपूर्ण विवरण यो हो कि टुप्पोहरूलाई सुरुङको अर्को छेउमा अझै साँचो IPv6 जडान चाहिन्छ। हेडर बेरेर अपस्ट्रिम जादुले बन्दैन।

दुई सुरुङ तह, दुई स्वतन्त्र जाँच

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

अद्वितीय-स्थानीय ठेगाना, वा विश्वव्यापी देखिने प्रिफिक्स जसतर्फ केही पनि फर्केर राउट हुँदैन, खुसीसाथ इन्टरफेसमा देखा पर्छ र कतै जाँदैन। सार्वजनिक पहुँच अपस्ट्रिमले दिन्छ, ठेगानाको आकारले होइन।

त्यही कुरा क्लाइन्टमा पनि लागू हुन्छ: ip -6 route get 2001:4860:4860::8888 सुरुङ उपकरणको नाम बताउनुपर्छ, र यदि भौतिक उपकरणको नाम बताउँछ भने क्लाइन्टले IPv6 का लागि VPN बिल्कुलै प्रयोग गर्दैन।

स्रोत प्रिफिक्स, आकार र ICMPv6

अपस्ट्रिमलाई सोध्नुहोस् कि फर्वार्डिङका लागि कुन स्रोत प्रिफिक्सहरू स्वीकार गर्छ, र तीमध्ये एउटा क्लाइन्ट पूलका लागि प्रयोग गर्नुहोस्। जुन प्रदायकले तपाईंलाई सर्भरको आफ्नै इन्टरफेसका लागि /64 दिन्छ, त्यसले तपाईंतर्फ दोस्रो /64 वा ठूलो ब्लक राउट गर्छ भन्ने छैन, र फरक भनेको एक दिउँसोको डिबगिङ हो जुन सपोर्ट टिकटले एउटै प्रश्नमा टुंग्याउँछ। लिखित रूपमा सोध्नुहोस् र उत्तर कन्फिगरेसनसँगै राख्नुहोस्।

तपाईंको स्ट्याकले वास्तवमै प्रयोग गर्ने थप क्याप्सुलेसनका लागि बजेट राख्नुहोस्, र ICMPv6 लाई Packet Too Big सहित चलिराख्नुहोस्। दोस्रो हेडरले उपयोगी पेलोड सानो बनाउँछ, त्यसैले सानो पिङको जवाफ दिने मार्ग पनि फाइल स्थानान्तरणमा असफल हुन सक्छ, र सबै ICMPv6 फाल्ने फायरवालले सुधार्न सकिने आकारको समस्यालाई कालो प्वाल बनाउँछ। सेवा घोषणा गर्नुअघि एउटा ठूलो स्थानान्तरण परीक्षण गर्नुहोस्।

कुन चाहिँ पूर्ण रूपमा फरक समस्या हो

IPv4 मात्र चल्ने अनुप्रयोगसम्म IPv6 मात्र चल्ने क्लाइन्टबाट पुग्नु भनेको अनुवाद हो, सुरुङ होइन, र यसका लागि जानाजान तैनाथ गरिएको NAT64 जस्तो केही चाहिन्छ। गन्तव्यले तपाईंले एउटा थप सुरुङ हेडर थप्नुभयो भनेर मात्र बुझ्दैन। ऐतिहासिक संक्रमण सेवाहरूले पनि उत्तिकै ध्यान पाउनुपर्छ: RFC 7526 ले 6to4 anycast रिले मोडेल रद्द गर्यो, त्यसैले त्यसको वरिपरि लेखिएको मार्गदर्शिकाले अब संरक्षित सार्वजनिक रिले नभएको कुरा वर्णन गर्छ।

यदि सर्भरसँग प्रयोगयोग्य IPv6 अपस्ट्रिम छैन भने विकल्पहरू समर्थित अपस्ट्रिम, अर्को एक्जिट, वा IPv6 सुरुङबाहिर रहने भन्ने अभिलेखित निर्णय हुन्। अस्वीकार्य कुरा भनेको क्लाइन्टहरूलाई IPv6 सेवा छ भनेर भन्नु हो, जब कि तिनीहरूको सामान्य IPv6 जडान चुपचाप VPN लाई छलिरहेको हुन्छ।

सम्बन्धित लेखहरू