DS-Lite इनबाउंड IPv4 होस्टिंग को रोकता है, आउटबाउंड VPN को नहीं
अनुवाद स्थिति उस पक्ष का अनुसरण करती है जो कनेक्शन शुरू करता है। B4 और AFTR से होकर जाने वाले आउटबाउंड अनुरोध को देखें, फिर समझें कि होस्टिंग क्यों विफल होती है।
DS-Lite किसी ग्राहक को ऐसे एक्सेस नेटवर्क पर IPv4 कनेक्टिविटी देने का तरीका है जो केवल IPv6 ले जाता है। घर के राउटर के पास अपना समर्पित सार्वजनिक 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 है। यही वह हिस्सा है जो लोग चूक जाते हैं: दूर का छोर इसे जान नहीं सकता।
ग्राहक का अपना कॉन्फ़िगरेशन भी उतना ही सामान्य है। उसे सर्वर तक एक काम करने वाला IPv4 पथ चाहिए, जो B4 और AFTR देते हैं, और उसे सर्वर का होस्टनाम IPv4 पते में हल होना चाहिए।
इनबाउंड होस्टिंग ही विफल होने वाला मामला क्यों है
घर पर IPv4 VPN सर्वर चलाना वह डिज़ाइन है जो प्रदाता के साझा पता-निर्धारण से टकराता है। प्रदाता के अनुवादक के पास सार्वजनिक पता और मैपिंग तालिका होती है, और उसके पास एक ग्राहक के लिए स्थायी इनबाउंड मैपिंग बनाने का कोई कारण नहीं होता।
घर के राउटर पर पोर्ट-फ़ॉरवर्ड नियम AFTR को कॉन्फ़िगर नहीं कर सकता। नियम स्थानीय डिवाइस पर वास्तविक और सही है, और वह ऊपर की ओर कुछ नहीं बदलता, इसलिए लक्षण ऐसी फ़ायरवॉल समस्या जैसा दिखता है जो जाती नहीं।
यहीं ऑपरेटर-स्तरीय अनुवाद एक सार्वजनिक पते से अलग होता है: सही स्थानीय फ़ॉरवर्ड भी ऐसे पते पर पहुँच सकता है जिसे कई ग्राहक साझा करते हैं।
एक्सेस योजना बदलने से पहले निदान करें
पहले प्रावधानित मोड की पुष्टि करें। मूल दोहरी स्टैक, DS-Lite और किसी अन्य अनुवाद तंत्र का उपयोग करने वाला केवल-IPv6 नेटवर्क तीन अलग व्यवस्थाएँ हैं, और प्रदाता के विपणन नाम हमेशा तकनीकी नाम से मेल नहीं खाते।
फिर आउटबाउंड विफलता के लिए चार अवलोकन स्थापित करें। क्या क्लाइंट VPN होस्टनाम को IPv4 गंतव्य में हल करता है? क्या सादा IPv4 कनेक्टिविटी काम करती है, न कि ब्राउज़र अनुरोध जिसने शायद चुपचाप IPv6 का उपयोग किया हो? क्लाइंट कौन-सा ट्रांसपोर्ट और पोर्ट आज़माता है, और क्या एंडपॉइंट लॉग उस प्रयास को देखते हैं? क्या विफलता प्रारंभिक अदला-बदली के दौरान, निष्क्रिय अवधि के बाद, या केवल बड़े स्थानांतरणों में होती है?
वे चार उत्तर फ़िल्टरिंग, अनुवाद-स्थिति के समय-समाप्त होने, गलत एंडपॉइंट या पैकेट-आकार के प्रबंधन की ओर संकेत करते हैं। इनमें से कोई भी खाता पृष्ठ पर DS-Lite देखकर सिद्ध नहीं होता।
प्रदाता के बदलाव ध्यान से पढ़ें
खाता बदलाव काम कर रहे कनेक्शन के साथ मेल खा सकता है और साथ ही कई गुण एक बार में बदल सकता है। लिखें कि कौन-सा गुण बदला, क्योंकि नया पैकेज नाम तकनीकी व्याख्या नहीं है।
दोहरी स्टैक सक्षम करने का निर्देश तब तक अस्पष्ट है जब तक कोई पुष्टि न करे कि प्रदाता वास्तव में क्या प्रावधान करता है। इसे IPv4 VPN क्लाइंट के लिए सार्वभौमिक आवश्यकता मानना अनुमान को नीति बना देता है।
यदि वास्तविक आवश्यकता इनबाउंड IPv4 होस्टिंग है, तो प्रदाता के साथ समर्थित इनबाउंड व्यवस्था, मूल पता-निर्धारण या कोई अन्य एक्सेस डिज़ाइन पर चर्चा करें। यदि आवश्यकता दूर के सर्वर तक पहुँचने वाला लैपटॉप है, तो इसके बजाय उसी सटीक आउटबाउंड प्रवाह के बारे में पूछें। कार्य क्रम: दिशा का नाम दें, प्रावधानित मोड की पुष्टि करें, सादा IPv4 और एक ट्रांसपोर्ट जाँचें, और एक्सेस योजना केवल तब बदलें जब दिशा वास्तव में इसकी माँग करे।