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 साठी ॲडॉप्टरची पद्धत, बोगद्याचा मालक आणि निराकरणकर्त्याचा स्रोत नोंदवा, कारण ही तीन तथ्ये पुढील जवळजवळ प्रत्येक प्रश्नाचे उत्तर देतात। इतर हायपरव्हायझर पद्धतींची नावे बदलतात आणि तत्त्व अभंग ठेवतात।