VirtualBox NAT या ब्रिज: VM का VPN कहाँ खत्म होता है

जब भी कोई वर्चुअल मशीन VPN क्लाइंट चलाती है, दो अलग सवाल एक साथ आते हैं, और उनके जवाब अलग होते हैं। पहला यह है कि मेहमान के अंदर का टनल होस्ट की रक्षा करता है या नहीं, और दूसरा यह है कि होस्ट पर बना टनल मेहमान को ढकता है या नहीं। एडाप्टर मोड दोनों तय करता है, VPN सॉफ़्टवेयर से भी ज़्यादा। NAT एडाप्टर होस्ट को दिखने वाला अंतिम बिंदु बनाता है, जबकि ब्रिज एडाप्टर मेहमान को उसके अपने पते के साथ नेटवर्क पर रखता है।

एन्क्रिप्टेड सत्र असल में कौन समाप्त करता है

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

बाहरी नेटवर्क किसका पता देखता है, यह वह सवाल है जिसका जवाब एडाप्टर मोड देता है। एक बार यह तय हो जाए, तो कवरेज नीति का सवाल रह जाता है और यांत्रिक हो जाता है। नीचे सब कुछ इन दो तथ्यों से निकलता है।

NAT मेहमान को तब तक फिर से लिखता है जब तक वह होस्ट जैसा न दिखे

NAT में, हाइपरवाइज़र मेहमान के हर पैकेट को पहले स्विच तक पहुँचने से पहले होस्ट के पते पर फिर से लिखता है। फिर वह ट्रैफ़िक होस्ट के अपने नेटवर्क स्टैक को सौंप दिया जाता है, जहाँ वह होस्ट की राउटिंग तालिका का पालन करता है, जिसमें होस्ट पर बने टनल के स्वामित्व वाला डिफ़ॉल्ट मार्ग भी शामिल है। इसलिए NAT मेहमान बिना किसी कॉन्फ़िगरेशन के होस्ट पर बने टनल से ढका रहता है, जो मेहमान-से-होस्ट वाले मामले के उलट है।

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

जो मेहमान अपना ख़ुद का क्लाइंट चलाता है, वह उस टनल को मेहमान के अंदर ही समाप्त करता है, और एन्क्रिप्टेड ट्रैफ़िक फिर उसी पुनर्लेखन से बाहर निकलता है, इसलिए होस्ट के अनुप्रयोग अपना मार्ग और अपना निकास पता बनाए रखते हैं। VirtualBox इस मोड में नाम-समाधान का भी स्वामी है और मेहमान की क्वेरी अपने इंजन से भेजता है, जब तक --natdnshostresolver1 सक्षम न हो। इसे सक्षम करने से मेहमान की खोजें होस्ट के रिज़ॉल्वर को मिल जाती हैं, जो तब समाधान ठीक करता है जब होस्ट का अपना दृश्य सही हो, और उतना ही ऐसा रिज़ॉल्वर सौंपता है जो शायद केवल टनल के अंदर ही मौजूद हो। सेटिंग बदलने से पहले VM बंद होना चाहिए, और सेटिंग मेहमान के सॉफ़्टवेयर की नहीं, एडाप्टर की है।

ब्रिज मेहमान को अपना लीज़ और अपना जोखिम देता है

ब्रिज मेहमान के फ़्रेम भौतिक खंड पर भेजता है, इसलिए DHCP उसे लीज़ देता है और नेटवर्क उसे अलग होस्ट मानता है। हर ब्रिज किया गया मेहमान अपने डिफ़ॉल्ट मार्ग के साथ स्वतंत्र टनल रख सकता है, और होस्ट की तालिका कभी नहीं बदलती। क़ीमत जोखिम है: मेहमान ब्रॉडकास्ट का जवाब देता है, पड़ोसी तालिकाओं में दिखता है, और स्विच पोर्ट सुरक्षा तथा वायरलेस क्लाइंट अलगाव के अधीन आ जाता है। होस्ट पर बना टनल भी इस व्यवस्था को नहीं ढकता, क्योंकि मेहमान के फ़्रेम कभी होस्ट स्टैक से नहीं गुज़रते।

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

मेहमान होस्ट का गेटवे क्यों नहीं हो सकता

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

काम करने वाले विकल्प फ़ॉरवर्ड और प्रॉक्सी हैं। SSH स्थानीय फ़ॉरवर्ड होस्ट को अपने लूपबैक से जुड़ने देता है जबकि मेहमान स्ट्रीम को टनल में ले जाता है, जो दूसरा क्लाइंट स्थापित किए बिना TCP सेवाएँ ढक देता है। होस्ट के अपने IP ट्रैफ़िक से इसके बजाय मेहमान का टनल इस्तेमाल कराना मेहमान के अंदर राउटर के साथ होस्ट पर स्पष्ट मार्ग और होस्ट पर अनुवाद माँगता है। यह चेकबॉक्स नहीं, एक छोटा नेटवर्क डिज़ाइन है, और इसे वापसी मार्ग की योजना चाहिए। जब मेहमान केवल क्लाइंट चलाने के लिए हो, तो क्लाइंट होस्ट पर रखें और अतिरिक्त हॉप हटा दें।

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

रिज़ॉल्वर और मार्ग सीमा पार नहीं करते

DNS उसी एडाप्टर का पालन करता है जिसने विकल्प प्राप्त किया, इसलिए मेहमान होस्ट के टनल-रिज़ॉल्वर विरासत में नहीं पाता और होस्ट कभी मेहमान को भेजा गया सर्वर नहीं जानता। भेजे गए dhcp-option DNS मान उस इंटरफ़ेस पर लागू होते हैं जिसने उन्हें स्वीकार किया, इसीलिए क्लाइंट के बिना ब्रिज किया गया मेहमान आंतरिक नाम हल नहीं कर सकता। NAT मेहमान आम तौर पर इसके बजाय हाइपरवाइज़र की DNS हैंडलिंग इस्तेमाल करता है, और अंतर हर परिवेश में एक कमांड में दिखता है।

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

मेहमान के अंदर रिज़ॉल्वर और मार्ग पढ़ें, इससे पहले कि आप मान लें कि इनमें से कोई होस्ट का पालन करता है। जब आंतरिक नाम वहीं हल करने हों, तो टनल-रिज़ॉल्वर मेहमान के अपने एडाप्टर में जोड़ें, फिर ऐसे नाम से जाँचें जो केवल टनल के पीछे मौजूद हो। हर VM के लिए एडाप्टर मोड, टनल का स्वामी और रिज़ॉल्वर का स्रोत दर्ज करें, क्योंकि ये तीन तथ्य लगभग हर बाद के सवाल का जवाब देते हैं। दूसरे हाइपरवाइज़र मोड के नाम बदल देते हैं और सिद्धांत को अक्षुण्ण रखते हैं।