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 परिवहन है। यदि बाहरी विनिमय पूरा होता है और डेटा पथ नहीं, तो सीमा वही है जो दूसरे सबूत में दिखी। यदि सुरंग उठती है और संसाधन उत्तर नहीं देते, तो समस्या पहले ही हाइपरवाइज़र से आगे रूटिंग या नीति में पहुँच चुकी है।

उत्तर के साथ एडाप्टर मोड भी लिखें, वरना अगला व्यक्ति वही दोपहर दोहराएगा। किसी भी सुधार के बाद अतिथि के अंदर वास्तविक एप्लिकेशन और नाम हल जाँचें, फिर दोबारा जुड़ें और विफलता नीति आज़माएँ। सुरंग से चलने वाला वेब पेज केवल यह साबित करता है कि वेब पथ काम करता है, जो उस क्षण लगने से छोटा दावा है।