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 आणि एक वाहतूक तपासा, आणि दिशेला खरोखर गरज असेल तरच प्रवेश योजना बदला.

संबंधित लेख