VirtualBox NAT मागे तुमचा पाहुणा VPN का अयशस्वी होतो?

व्हर्च्युअल मशीनमधील ब्राउझर काम करतो, आणि त्याच पाहुण्यावरील VPN क्लायंट डेटा वाहून नेऊ शकत नाही. पाहुण्याकडे कनेक्टिव्हिटी स्पष्ट आहे, म्हणून दोष VPN च्या बाह्य प्रोटोकॉलला काय हवे आहे आणि व्हर्च्युअल NAT काय पास करेल यात आहे. निकाल तीन अटींवर ठरतो: कोणती प्रक्रिया VPN ची मालक आहे, तारेवर बाह्य देवाणघेवाण कशी दिसते, आणि अडॅप्टर मोड तुम्ही विचार करत असलेलाच आहे का. तुम्ही बदलू शकता त्या अटीचे नाव देणे हाच संपूर्ण निर्णय आहे.

नेटवर्कला दोष देण्यापूर्वी VPN प्रक्रिया शोधा

VPN पाहुण्याच्या आत चालतो की होस्टवर हे आधी ठरवा, कारण दोन्ही रचना वेगळ्या प्रकारे अयशस्वी होतात. पाहुण्याच्या आतला क्लायंट आपले बाह्य कनेक्शन पाहुण्याच्या अडॅप्टर आणि त्यामागील कोणत्याही भाषांतरातून बनवतो. होस्ट VPN होस्ट आणि हायपरव्हायझर धोरणानुसार पाहुण्याची रहदारी पकडतो, जो स्वतःच्या नियमांसह वेगळा पकडबिंदू आहे. दोन्ही एकाच वेळी चालू शकतात आणि पुरावे गोंधळू शकतात, म्हणून कोणत्याही एकाला स्पर्श करण्यापूर्वी ही रहदारी कोणी वाहून न्यायला हवी हे ठरवा.

काहीही बदलण्यापूर्वी आता पाहुण्याचा अडॅप्टर मोड लिहून ठेवा. ते एकच मूल्य पुढील बहुतेक गोष्टी स्पष्ट करते, आणि नंतर कोणीही तुम्हाला पहिल्यांदा तेच विचारेल.

बाह्य देवाणघेवाण सुसंगती ठरवते

VirtualBox नेटवर्किंग मार्गदर्शक येथे महत्त्वाच्या NAT मर्यादा मांडतो: तो TCP आणि UDP व्यतिरिक्त इतर प्रोटोकॉल पास करणार नाही, GRE असमर्थित म्हणून नमूद केले आहे, आणि PPTP प्रभावित उदाहरण म्हणून दिले आहे. PPTP नियंत्रण देवाणघेवाणीसाठी TCP आणि डेटासाठी GRE वापरतो, त्यामुळे नियंत्रण कनेक्शन यशस्वी होऊ शकते पण डेटा मार्ग तीच सीमा ओलांडू शकत नाही. हे दोन वेगळे पुरावे आहेत, आणि त्यातील फक्त एक रहदारी वाहून नेण्याबद्दल आहे. फायरवॉल नियमात TCP पोर्ट 47 ला परवानगी देणे हे IP प्रोटोकॉल 47 ला परवानगी देण्यासारखे नाही, आणि दोन्ही सतत गोंधळले जातात.

मर्यादा NAT हा शब्द वापरणाऱ्या प्रत्येक उपकरणाशी नाही, तर या NAT रचनेशी जोडून ठेवा. भौतिक राउटर तक्रार न करता GRE पास करू शकतो पण व्हर्च्युअल NAT तो टाकून देतो, आणि दुसरा हायपरव्हायझर काय पुढे पाठवायचे हे स्वतः ठरवतो. जिथे संस्था TCP किंवा UDP च्या आत मंजूर वाहतूक देते, तिथे त्या मार्गासाठी तिचा समर्थित क्लायंट आणि प्रोफाइल वापरा. सुसंगती अनेक आवश्यकतांपैकी एक आहे, आणि ती सर्व्हरवरील विश्वास, खाते परवानगी किंवा कार्यरत खाजगी मार्ग स्थापित करत नाही.

ब्रिजिंग प्रत्यक्षात काय बदलते

ब्रिज पाहुण्याचा MAC पत्ता भाषांतरामागे लपवण्याऐवजी भौतिक विभागाला देतो. मग पाहुणा त्या विभागाला सेवा देणाऱ्या कोणत्याही DHCP सर्व्हरकडून पत्ता घेतो, त्या पत्त्यासाठी ARP ला उत्तर देतो, आणि वरच्या स्विचला आणखी एक पोर्ट म्हणून दिसतो. यामुळे व्हर्च्युअल भाषांतर मार्ग काढला जातो, जुन्या पाककृतीची शिफारस करण्याचे नेमके कारण तेच आहे, आणि त्याच क्षणी आणखी तीन गोष्टी बदलतात. पत्ता आता हायपरव्हायझरकडून नाही तर स्थानिक विभागाकडून येतो, उघडकीचा अर्थ पाहुणा त्या विभागाला दिसतो, आणि प्रवेश स्विच पोर्ट आणि त्याच्या धोरणावर अवलंबून असतो. यातील प्रत्येकजण बदल नाकारण्याचे कारण होऊ शकते, आणि एकही VPN प्रोटोकॉलबद्दल नाही.

ब्रिजिंग गहाळ प्लगइन बसवत नाही, अनुपलब्ध गुप्त एजंट पुरवत नाही, आणि प्रमाणीकरणाचा नकार दुरुस्त करत नाही. ते जुन्या प्रोटोकॉलला चांगली निवडही बनवत नाही, आणि जिथे ऑपरेटरकडे देखभाल केलेला पर्याय आहे तिथे निर्णय हायपरव्हायझर बदलणे नाही तर तोच पर्याय आहे. पोर्ट फॉरवर्डिंग पूर्णपणे तिसरी भूमिका आहे: ते येणारी सेवा प्रकाशित करते आणि जाणाऱ्या क्लायंटच्या बाह्य प्रोटोकॉलसाठी काहीच करत नाही.

दोन बोगदे, दोन पुराव्यांचे मार्ग

पाहुणा VPN ला कोणताही अंतर्गत पत्ता किंवा खाजगी मार्ग महत्त्वाचा होण्यापूर्वी पाहुण्याच्या इंटरफेसपासून त्याच्या साथीदारापर्यंत वापरण्यायोग्य मार्ग हवा. जिथे होस्ट VPN आहे, तो आपल्या धोरणानुसार ती बाह्य देवाणघेवाण पुढे पाठवू किंवा अडवू शकतो, आणि पाहुण्याची अंतर्गत बोगदा बाह्य यशस्वी झाल्यानंतरच सुरू होते. कोणत्याही स्तराची व्याप्ती एका जोडलेल्या चिन्हातून किंवा होस्ट ब्राउझरच्या सार्वजनिक पत्त्यातून वाचता येत नाही.

शेवटचा नाही, पहिला त्रुटी संदेश ठेवा, कारण सर्वात लवकरचा अपयश स्तराचे नाव सांगतो. एका वेळी एक समर्थित नेटवर्क रचना बदला, त्याच पाहुणा प्रोफाइल आणि त्याच क्रेडेन्शियलसह, तुलना अर्थपूर्ण व्हावी म्हणून. अपयशातून कोणता टप्पा तुटला ते ठरवा: स्थानिक एकत्रीकरण, वाहतूक, प्रमाणीकरण, किंवा बोगदा उभा राहिल्यानंतर संसाधन प्रवेश. यातील प्रत्येकाचा वेगळा मालक आहे, आणि फक्त एक हायपरव्हायझरचा प्रश्न आहे.

कोणती अट प्रत्यक्षात तुम्हाला रोखत आहे

आता निर्णय वेगळ्या उत्तरांच्या तीन प्रश्नांपर्यंत आकुंचन पावतो. बाह्य प्रोटोकॉल TCP आणि UDP च्या बाहेर असल्यास NAT मोड ही मर्यादा आहे, आणि पुढचा मार्ग ब्रिजिंग किंवा मंजूर TCP/UDP वाहतूक आहे. बाह्य देवाणघेवाण पूर्ण होते पण डेटा मार्ग नाही, तर मर्यादा दुसऱ्या पुराव्यात दिसलेली तीच आहे. बोगदा उभा राहतो पण संसाधने उत्तर देत नाहीत, तर समस्या आधीच हायपरव्हायझर ओलांडून राउटिंग किंवा धोरणात गेली आहे.

उत्तरासोबत अडॅप्टर मोडही लिहा, नाहीतर पुढची व्यक्ती तीच दुपार पुन्हा करेल. कोणत्याही दुरुस्तीनंतर पाहुण्याच्या आत प्रत्यक्ष अनुप्रयोग आणि नाव निराकरण तपासा, नंतर पुन्हा जोडून अपयश धोरण चालवा. बोगद्यातून चालणारे वेब पान फक्त वेब मार्ग चालतो हे सिद्ध करते, जे त्या क्षणी वाटते त्यापेक्षा लहान दावा आहे.