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

दो संकेत झूठ बोलते हैं। सफल पिंग पहुँच सिद्ध करता है, निर्गम पथ नहीं। और DNS का उत्तर 10.0.2.3 प्रॉक्सी द्वारा होस्ट के रिज़ॉल्वर से मिल सकता है जबकि TCP दूसरा रूट लेता है, और इस तरह आपको एक ऐसा पृष्ठ मिलता है जो लोड होता है और ऐसा लॉगिन जो कभी पूरा नहीं होता।

कौन सा मोड काम के लिए उपयुक्त है

मोड एक रूटिंग निर्णय है, इसलिए इसे आदत के बजाय आवश्यकता से चुनें:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

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

वे विफलताएँ जिनका दोष VPN पर डाला जाता है

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

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 प्रसारण ट्रैफ़िक नहीं दिखता जिससे उसका कोई लेना-देना नहीं।

संबंधित लेख