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 यातायात हो. यदि बाहिरी आदानप्रदान पूरा हुन्छ तर डाटा मार्ग हुँदैन भने सीमा दोस्रो प्रमाणमा देखिएकै हो. यदि सुरुङ उठ्छ तर स्रोतहरू जवाफ दिँदैनन् भने समस्या पहिले नै हाइपरभाइजर पार गरेर राउटिङ वा नीतिमा पुगेको छ.

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