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 दुसरा मार्ग घेतो, आणि अशा प्रकारे लोड होणारे पान आणि कधीही पूर्ण न होणारे लॉगिन मिळते।

कामासाठी कोणता मोड योग्य आहे

मोड हा मार्गनिर्देशनाचा निर्णय आहे, म्हणून तो सवयीऐवजी गरजेनुसार निवडा:

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 पाहुणे पहिल्यांदा झाकणे गमावतात, आणि अहवाल होस्ट ठीक असताना 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 प्रसारण रहदारी दिसत नाही।

संबंधित लेख