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 का लागि एडाप्टरको मोड, सुरुङको मालिक र समाधानकर्ताको स्रोत लेख्नुहोस्, किनकि ती तीन तथ्यले पछिका लगभग हरेक प्रश्नको उत्तर दिन्छन्। अन्य हाइपरभाइजरले मोडका नाम बदल्छन् र सिद्धान्त अक्षुण्ण राख्छन्।