DS-Lite ले आगमन IPv4 होस्टिङ रोक्छ, बाहिरिने VPN होइन

अनुवाद स्थिति जडान सुरु गर्ने पक्षलाई पछ्याउँछ। B4 र AFTR हुँदै जाने बाहिरिने अनुरोध पछ्याउनुहोस्, त्यसपछि होस्टिङ किन असफल हुन्छ हेर्नुहोस्।

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

कुन पक्षले जडान सुरु गर्छ

जडान सुरु गर्ने क्लाइन्टले अगाडि बढ्दै अनुवाद स्थिति बनाउँछ। प्रदायकको अनुवादकले पहिलो प्याकेट देख्छ, म्यापिङ तोक्छ र त्यसलाई अगाडि पठाउँछ। फर्किने ट्राफिक त्यही म्यापिङसँग मिल्छ किनकि म्यापिङ पहिले नै अवस्थित छ।

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

बाहिरिने अनुरोध पछ्याउनुहोस्

आर्किटेक्चर RFC 6333 दुवै छेउको नाम दिन्छ। ग्राहक पक्षको तत्व B4 हो, जसले IPv4 लाई IPv6 भित्र समेट्छ। प्रदायक पक्षको तत्व AFTR हो, जसले ठेगाना अनुवाद गर्छ र प्याकेटलाई IPv4 को रूपमा अगाडि पठाउँछ।

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

VPN सर्भरले प्रदायकको अनुवादित ठेगानाबाट साधारण IPv4 जडान प्राप्त गर्छ। यसलाई DS-Lite मोड, विशेष पोर्ट वा ग्राहकको पहुँच सञ्जाल IPv6 मात्र छ भन्ने जानकारी आवश्यक पर्दैन। मानिसहरूले छुटाउने भाग यही हो: टाढाको छेउले त्यो थाहा पाउन सक्दैन।

ग्राहकको आफ्नै कन्फिगरेसन पनि त्यत्तिकै साधारण छ। यसलाई B4 र AFTR ले दिने, सर्भरसम्मको काम गर्ने IPv4 मार्ग चाहिन्छ, र सर्भरको होस्टनेम IPv4 ठेगानामा समाधान हुनुपर्छ।

आगमन होस्टिङ किन असफल हुने अवस्था हो

घरमा IPv4 VPN सर्भर चलाउनु प्रदायकको साझा ठेगानाकरणसँग ठोकिने डिजाइन हो। प्रदायकको अनुवादकसँग सार्वजनिक ठेगाना र म्यापिङ तालिका हुन्छ, र एक ग्राहकका लागि स्थायी आगमन म्यापिङ बनाउने कुनै कारण हुँदैन।

घरको राउटरमा पोर्ट-फर्वार्ड नियमले AFTR कन्फिगर गर्न सक्दैन। नियम स्थानीय उपकरणमा वास्तविक र सही छ, र यसले माथि केही पनि बदल्दैन, त्यसैले लक्षण नहट्ने फायरवाल समस्याजस्तो देखिन्छ।

यहीँ अपरेटर-स्तरको अनुवाद एकल सार्वजनिक ठेगानाबाट फरक पर्छ: सही स्थानीय फर्वार्ड पनि धेरै ग्राहकले साझा गर्ने ठेगानामा पर्न सक्छ।

पहुँच योजना बदल्नुअघि निदान गर्नुहोस्

पहिले प्रदान गरिएको मोड पुष्टि गर्नुहोस्। मूल दोहोरो स्ट्याक, DS-Lite र अर्को अनुवाद संयन्त्र प्रयोग गर्ने IPv6-मात्र सञ्जाल तीन फरक व्यवस्था हुन्, र प्रदायकका मार्केटिङ नाम सधैं प्राविधिक नामसँग मिल्दैनन्।

त्यसपछि बाहिरिने असफलताका लागि चार अवलोकन स्थापित गर्नुहोस्। क्लाइन्टले VPN होस्टनेमलाई IPv4 गन्तव्यमा समाधान गर्छ? ब्राउजर अनुरोधको सट्टा सादा IPv4 जडान चल्छ — त्यो अनुरोधले चुपचाप IPv6 प्रयोग गरेको हुन सक्छ? क्लाइन्टले कुन यातायात र पोर्ट प्रयास गर्छ, र इन्डपोइन्ट लगहरूले त्यो प्रयास देख्छन्? असफलता सुरुको आदानप्रदानमा, निष्क्रिय अवधिपछि, वा ठूला स्थानान्तरणमा मात्र हुन्छ?

ती चार उत्तरले फिल्टरिङ, अनुवाद स्थितिको समय समाप्ति, गलत इन्डपोइन्ट वा प्याकेट आकार व्यवस्थापनतर्फ संकेत गर्छन्। खाता पृष्ठमा DS-Lite देखेर तीमध्ये कुनै पनि स्थापित हुँदैन।

प्रदायकका परिवर्तन ध्यानपूर्वक पढ्नुहोस्

खाता परिवर्तन काम गरिरहेको जडानसँगै पर्न सक्छ र एकैचोटि धेरै गुण बदल्न सक्छ। कुन गुण बदलियो लेख्नुहोस्, किनकि नयाँ प्याकेज नाम प्राविधिक व्याख्या होइन।

दोहोरो स्ट्याक सक्षम गर्ने निर्देशन प्रदायकले वास्तवमै के प्रदान गर्छ कसैले पुष्टि नगरेसम्म अस्पष्ट हुन्छ। यसलाई IPv4 VPN क्लाइन्टका लागि सार्वभौमिक आवश्यकता मान्नु अनुमानलाई नीति बनाउनु हो।

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

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