NAT वा ब्रिज VM नेटवर्क: VPN ट्राफिक कुनले बोक्छ?
NAT पाहुनाले होस्टको सुरुङ तब मात्र ऋण लिन्छन् जब क्लाइन्टले मार्ग अनुसार सुरुङ गर्छ; ब्रिज पाहुनाले आफैं मार्ग निर्धारण गर्छन्। पाहुनाको परीक्षण गर्नुहोस्, त्यसपछि उपयुक्त मोड छान्नुहोस्।
ब्रिज र NAT एउटै पाहुनालाई तपाईंको VPN मा जोड्ने दुई तरिका होइनन्; तिनीहरूले सुरुङ आउनु अघि नै पाहुनाका प्याकेट कसका हुन् भन्ने कुरा तय गर्छन्। NAT मोडमा हाइपरभाइजरले पाहुनाको ट्राफिक पुनः लेख्छ र होस्ट पक्षको कोडबाट बाहिर पठाउँछ, त्यसैले पाहुना होस्टले त्यो कोडलाई दिने मार्गमा जान्छ। ब्रिज मोडमा पाहुनाले भौतिक खण्डमा आफ्नै लिङ्क-तह पहिचान पाउँछ र आफ्नै पूर्वनिर्धारित गेटवे छान्छ, जसले होस्टको सुरुङलाई उसका लागि अप्रासंगिक बनाउँछ, जबसम्म LAN राउटरले नै सुरुङ गर्दैन। मैले VM लाई VPN मा छ भनी मान्न छोडें र त्यसलाई त्यो पाहुनाको पूर्वनिर्धारित मार्ग कता संकेत गर्छ भन्ने प्रश्नका रूपमा हेर्न थालें। तलको परीक्षण प्रत्येक मोडका लागि केही मिनेट लिन्छ र अनुमान बिना नै टुंगो लगाउँछ।
NAT ले पाहुनालाई हाइपरभाइजर कोडको पछाडि राख्छ, जहाँ होस्टका मार्गहरू लागू हुन्छन्
VirtualBox मा NAT पाहुना 10.0.2.0/24 मा बस्छ, 10.0.2.2 मा भर्चुअल गेटवे, 10.0.2.3 मा DNS प्रोक्सी, र भौतिक नेटवर्कसम्म आफ्नो मार्ग छैन। बाहिर जाने प्याकेट NAT इन्जिनले लिन्छ, स्रोत होस्ट हुने गरी पुनः लेख्छ र होस्टको IP स्ट्याकमा दिन्छ। त्यहाँबाट पाहुनाको ट्राफिक होस्ट प्रवाह हो, र मार्ग खोज गन्तव्य अनुसार हुन्छ: होस्टमा 0.0.0.0/1 र 128.0.0.0/1 स्थापना गर्ने पूर्ण-सुरुङ क्लाइन्टले VM छ भन्ने कहिल्यै नजानी त्यसलाई समात्छ। Oracle को VirtualBox नेटवर्किङ अध्याय ले यी पूर्वनिर्धारित मानहरू सूचीबद्ध गर्छ, यदि तपाईं आफ्नो बिल्डमा ठेगानाहरू प्रमाणित गर्न चाहनुहुन्छ।
libvirt को पूर्वनिर्धारित नेटवर्क 192.168.122.0/24 बाट त्यही ठाउँमा पुग्छ, जहाँ dnsmasq लीज बाँडछ र होस्टले उपजाल मास्करेड गर्छ, त्यसैले पाहुनाका प्याकेट फेरि होस्टको मार्ग निर्णयमा आउँछन्। अपवाद त्यस्तो क्लाइन्ट हो जसले ट्राफिक मार्ग अनुसार नभई प्रक्रिया अनुसार छान्छ। यदि स्प्लिट-सुरुङ सूचीमा तपाईंको ब्राउजर मात्र छ र अरू केही छैन भने NAT इन्जिन त्यो सूचीमा छैन, र पाहुना सुरुङ बिना मेसिन छोड्छ, जबकि होस्टको ब्राउजर अझै ढाकिएको देखिन्छ। एउटै उपजाल, उल्टो नतिजा।
ब्रिजले पाहुनालाई भौतिक LAN मा आफ्नै स्थान दिन्छ
ब्रिज पाहुनालाई वास्तविक एडाप्टरमा जोडिएको भर्चुअल NIC दिइन्छ, उसले आफ्नै MAC ठेगाना पाउँछ र भौतिक नेटवर्कबाट DHCP लीज लिन्छ। उसको पूर्वनिर्धारित गेटवे LAN राउटर हो, हाइपरभाइजर होइन, र उसका फ्रेम ती एडाप्टरबाट तारमा जान्छन्। होस्टका सुरुङ मार्ग होस्टको तालिकामा रहन्छन् र कहिल्यै सोधिँदैनन्, किनकि पाहुनाका फ्रेम कहिल्यै होस्टको IP स्ट्याकमा प्रवेश गर्दैनन्।
यसले दुवै दिशामा काट्छ। mDNS र SMB ब्राउजिङ काम गर्न थाल्छन् किनकि पाहुनाले LAN को प्रसारण ट्राफिक देख्छ, र पाहुना बीचमा होस्ट फायरवाल नराखी उही खण्डका अन्य मेसिनबाट पहुँचयोग्य हुन्छ। ब्रिज विद्यमान सुरुङबाट पाहुनालाई धकेल्ने तरिका पनि होइन: VM लाई होस्टको WireGuard वा OpenVPN इन्टरफेसमा जोड्नु VirtualBox वा libvirt ले तपाईंका लागि गर्ने काम होइन। यदि ब्रिज पाहुनाले सुरुङबाट जानुपर्छ भने सुरुङ त्यो LAN मा कतै टुंगिनुपर्छ।
बहस टुंग्याउने परीक्षण
दुवै मोडमा उही जाँच गर्नुहोस् र उत्तरहरू लेख्नुहोस्:
- होस्टमा
curl -s https://ifconfig.meले सार्वजनिक v4 ठेगाना दिन्छ। - पाहुनामा उही आदेश, साथै पूर्वनिर्धारित गेटवेका लागि Linux मा
ip routeवा Windows माGet-NetRoute -DestinationPrefix 0.0.0.0/0। - रिजोल्भरको पहिचान: पाहुनामा
resolvectl statusवाcat /etc/resolv.conf, त्यो 10.0.2.3 तर्फ संकेत गर्छ कि LAN सर्भरतर्फ भनी हेर्न। - ठेगाना परिवार:
ip -6 addr show scope globalर एउटा v6 अनुरोध, किनकि v4 सुरुङले पाहुनासँग हुन सक्ने विश्वव्यापी v6 ठेगानाबारे केही भन्दैन।
मिल्ने सार्वजनिक ठेगाना भनेको पाहुना होस्टको मार्गमा छ। LAN को सामान्य निर्गमसँग मिल्ने पाहुनाको ठेगाना भनेको त्यो छैन। मानिसहरूले छोड्ने चरण नियन्त्रण हो: होस्टको सुरुङ तल झार्नुहोस् र पाहुनाको अनुरोध दोहोर्याउनुहोस्। यदि पाहुनाले ब्राउज गरिरहन्छ भने, मोडको नामले जे सुझाव दिए पनि, त्यो कहिल्यै होस्टको सुरुङमा निर्भर थिएन। NAT मोडमा होस्टको सुरुङ तल हुँदा पाहुनाले इन्टरनेट गुमाउनुपर्छ, जबसम्म क्लाइन्ट सुरुङ बिनाको ट्राफिक अनुमति दिनका लागि कन्फिगर गरिएको छैन, जुन आफैंमा जान्न योग्य कुरा हो।
दुई संकेत झुटो बोल्छन्। सफल ping ले पहुँच प्रमाणित गर्छ, निर्गम मार्ग होइन। र DNS को उत्तर 10.0.2.3 प्रोक्सीले होस्टको रिजोल्भरमार्फत दिन सक्छ, त्यतिखेर TCP अर्को मार्ग लिन्छ, र यसरी लोड हुने पृष्ठ र कहिल्यै नटुंगिने लगइन पाइन्छ।
कामका लागि कुन मोड उपयुक्त छ
मोड मार्ग निर्धारणको निर्णय हो, त्यसैले बानीको सट्टा आवश्यकताबाट छान्नुहोस्:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
पहिलो पङ्क्ति मानिसहरू अल्झिने ठाउँ हो: NAT र होस्टमा पूर्ण-सुरुङ क्लाइन्टले पाहुनालाई ढाक्छ, तर क्लाइन्टले मार्ग अनुसार सुरुङ गरिरहेको र होस्टको माथिल्लो लिङ्क त्यही सुरुङ भएसम्म मात्र। क्लाइन्टलाई ब्राउजरका लागि मात्र अनुमति सूचीमा सार्नुहोस् र कतै पनि कुनै त्रुटि बिना ढाक्ने कुरा हराउँछ। चौथो पङ्क्ति उल्टो गल्ती हो: सुविधाका लागि ब्रिज गरिएको पाहुना जसले कार्यालयको LAN मा चुपचाप SMB वा SSH लाई उत्तर दिन थाल्छ।
VPN मा थोपारिने विफलताहरू
Windows मा NAT अनुवाद VirtualBox VM प्रक्रियाभित्र चल्छ, त्यसैले प्रति-एप क्लाइन्टले भर्चुअल मेसिनका लागि सामान्य नियमको सट्टा ठ्याक्कै त्यही इमेज आफ्नो सूचीमा चाहन्छ। क्लाइन्ट अद्यावधिकले आफ्नो प्रक्रिया सूची पुनः बनाउँदा NAT पाहुनाले पहिले ढाक्ने कुरा गुमाउँछन्, र प्रतिवेदन होस्ट ठीक हुँदा LAN पुग्ने तर इन्टरनेट नपुग्ने VM जस्तो पढिन्छ।
Wi-Fi मा ब्रिज गर्नु अर्को क्लासिक हो। पहुँच बिन्दुहरूले बाह्य स्रोत MAC भएका फ्रेम विरलै अगाडि पठाउँछन्, त्यसैले wlan0 मा ब्रिज या त पूर्ण रूपमा असफल हुन्छ या AP मा क्लाइन्ट अलगावले खसाल्न थालेसम्म चल्छ। VirtualBox ले तैपनि आफ्नो सूचीमा वायरलेस एडाप्टर दिन्छ। यदि होस्ट Wi-Fi मा छ र पाहुनालाई ब्रिज गर्नुपर्छ भने अनुमान गर्नुको सट्टा परीक्षण गर्ने योजना बनाउनुहोस्।
MTU तेस्रो हो। ब्रिज पाहुनाले LAN को 1500 बाइट MTU राख्छ, र यदि उसले आफ्नै WireGuard क्लाइन्ट 1420 मा चलाउँछ भने ठूला TLS ह्यान्डसेक अल्झिन्छन् तर साना अनुरोध सफल हुन्छन्। NAT अन्तर्गत होस्ट सुरुङको MTU होस्टकै समस्या हो, तर पाहुना अझै 1500 मा विश्वास गर्छ, र don't-fragment बिट सेट भएको UDP पनि त्यसै गरी अदृश्य हुन्छ।
मोड लेख्नुहोस् र प्रत्येक एडाप्टर परिवर्तनपछि फेरि जाँच्नुहोस्
मोड, ब्रिजले प्रयोग गर्ने होस्ट इन्टरफेस, पाहुनाको पूर्वनिर्धारित गेटवे, उसको रिजोल्भर र उसका v4 र v6 निर्गम ठेगानाहरू लेख्नुहोस्। त्यही अभिलेखले अर्को विफलता सस्तो बनाउँछ: जब ल्यापटप डकबाट Wi-Fi मा जान्छ, ब्रिज पाहुना ब्रिजसँगै अर्को भौतिक एडाप्टरतर्फ जान्छ र अर्को उपजालमा फेरि लीज लिन सक्छ, जबकि NAT पाहुना आफ्नो 10.0.2.x ठेगाना राख्छ र चुपचाप अर्को माथिल्लो लिङ्क हात पार्छ।
टिकट बन्द गर्नु अघि यीमध्ये प्रत्येकको पुष्टि गर्नुहोस्:
- पाहुनाको निर्गम ठेगाना होस्टको निर्गम ठेगानाभन्दा फरक छ, त्यसैले त्यो होस्टको सुरुङमा छैन।
- रिजोल्भर 10.0.2.3 प्रोक्सी हो वा LAN सर्भर, र कसले उत्तर दियो भन्ने तपाईंलाई थाहा छ।
- सुरुङको डिजाइन केवल v4 भए पाहुनामा कुनै विश्वव्यापी v6 ठेगाना छैन।
- होस्टको सुरुङ तल हुँदा पाहुना ब्राउज गर्न छोड्छ, वा त्यो कहिल्यै त्यसमा निर्भर नरहेको अब तपाईंलाई थाहा छ।
- पाहुनाले आफूसँग सम्बन्ध नभएको LAN प्रसारण ट्राफिक देख्दैन।