Bridged మరియు NAT ఒకే అతిథిని మీ VPNకు కలిపే రెండు మార్గాలు కావు; అవి నిర్ణయించేది ఏ టన్నెల్ వచ్చే ముందే అతిథి ప్యాకెట్లు ఎవరి సొంతం అనేది. NAT మోడ్లో హైపర్వైజర్ అతిథి ట్రాఫిక్ను తిరిగి రాసి హోస్ట్ వైపు కోడ్ నుండి బయటకు పంపుతుంది, కాబట్టి అతిథి హోస్ట్ ఆ కోడ్కు ఇచ్చే మార్గంలోనే వెళ్తాడు. Bridged మోడ్లో అతిథికి భౌతిక విభాగంలో తన సొంత లింక్ లేయర్ గుర్తింపు లభిస్తుంది, తన సొంత డిఫాల్ట్ గేట్వేను ఎంచుకుంటాడు, ఇది 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 యంత్రం ఆ జాబితాలో లేదు, కాబట్టి హోస్ట్ బ్రౌజర్ ఇంకా కవర్ అయినట్టు కనిపిస్తున్నప్పుడు అతిథి టన్నెల్ లేకుండా యంత్రం నుండి బయటకు వెళ్తాడు. అదే సబ్నెట్, వ్యతిరేక ఫలితం.

Bridged భౌతిక LANలో అతిథికి తన సొంత స్థానాన్ని ఇస్తుంది

Bridged అతిథికి నిజమైన అడాప్టర్కు కలిపిన వర్చువల్ NIC ఇవ్వబడుతుంది, తన సొంత MAC చిరునామా పొందుతాడు, భౌతిక నెట్వర్క్ నుండి DHCP లీజు తీసుకుంటాడు. అతని డిఫాల్ట్ గేట్వే LAN రౌటర్, హైపర్వైజర్ కాదు, అతని ఫ్రేమ్లు ఆ అడాప్టర్ ద్వారా తీగపైకి వెళ్తాయి. హోస్ట్ టన్నెల్ మార్గాలు హోస్ట్ పట్టికలో ఉంటాయి, ఎప్పుడూ సంప్రదించబడవు, ఎందుకంటే అతిథి ఫ్రేమ్లు హోస్ట్ IP స్టాక్లోకి ఎప్పుడూ ప్రవేశించవు.

అది రెండు వైపులా కోస్తుంది. అతిథి LAN ప్రసార ట్రాఫిక్ను చూస్తుంది కాబట్టి mDNS మరియు SMB బ్రౌజింగ్ పని చేయడం మొదలవుతుంది, మధ్యలో హోస్ట్ ఫైర్వాల్ లేకుండా అదే విభాగంలోని ఇతర యంత్రాల నుండి అతిథి చేరుకోగలడు. Bridging అనేది ఇప్పటికే ఉన్న టన్నెల్ ద్వారా అతిథిని నెట్టే మార్గం కూడా కాదు: VMను హోస్ట్ WireGuard లేదా OpenVPN ఇంటర్ఫేస్కు కలపడం VirtualBox లేదా libvirt మీ కోసం చేసే పని కాదు. Bridged అతిథిని టన్నెల్ చేయాల్సి ఉంటే, టన్నెల్ ఆ LANలో ఎక్కడో ముగియాలి.

వాదనను ముగించే పరీక్ష

రెండు మోడ్లలోనూ అదే తనిఖీలు నడిపి సమాధానాలు రాసుకోండి:

  • హోస్ట్లో, curl -s https://ifconfig.me పబ్లిక్ v4 చిరునామాను ఇస్తుంది.
  • అతిథిలో, అదే ఆదేశం, అదనంగా ip route Linuxలో లేదా Get-NetRoute -DestinationPrefix 0.0.0.0/0 Windowsలో డిఫాల్ట్ గేట్వే కోసం.
  • రిజాల్వర్ గుర్తింపు: 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తో హోస్ట్లో పూర్తి టన్నెల్ క్లయింట్ అతిథిని నిజంగా కవర్ చేస్తుంది, కానీ క్లయింట్ మార్గం ద్వారా టన్నెల్ చేస్తున్నంత కాలం మరియు హోస్ట్ అప్లింక్ ఆ టన్నెల్ అయినంత కాలం మాత్రమే. క్లయింట్ను బ్రౌజర్కు మాత్రమే అనుమతించే జాబితాకు మార్చండి, ఎక్కడా ఎలాంటి లోపం లేకుండా కవరేజ్ మాయమవుతుంది. నాల్గవ వరుస వ్యతిరేక తప్పు, సౌలభ్యం కోసం bridged చేసిన అతిథి నిశ్శబ్దంగా కార్యాలయ LANలో SMB లేదా SSHకు సమాధానం చెప్పడం మొదలుపెట్టడం.

VPNపై మోపబడే వైఫల్యాలు

Windowsలో NAT అనువాదం VirtualBox VM ప్రాసెస్ లోపల నడుస్తుంది, కాబట్టి యాప్ వారీగా పనిచేసే క్లయింట్కు ఆ ఇమేజే జాబితాలో అవసరం, వర్చువల్ యంత్రాలకు సాధారణ నియమం కాదు. క్లయింట్ నవీకరణ దాని ప్రాసెస్ జాబితాను తిరిగి నిర్మించినప్పుడు, NAT అతిథులు మొదట కవరేజ్ కోల్పోతారు, నివేదిక హోస్ట్ బాగానే ఉండగా LANకు చేరి ఇంటర్నెట్కు చేరని VMలా వినిపిస్తుంది.

Wi-Fiకి bridging మరో క్లాసిక్. యాక్సెస్ పాయింట్లు విదేశీ మూల MAC ఉన్న ఫ్రేమ్లను అరుదుగా ఫార్వర్డ్ చేస్తాయి, కాబట్టి wlan0పై బ్రిడ్జ్ గానీ పూర్తిగా విఫలమవుతుంది, గానీ APలో క్లయింట్ ఐసోలేషన్ దాన్ని వదిలించుకోవడం మొదలుపెట్టే వరకు పని చేస్తుంది. VirtualBox ఇంకా వైర్లెస్ అడాప్టర్ను జాబితాలో ఇస్తుంది. హోస్ట్ Wi-Fiలో ఉండి అతిథి bridged కావాలంటే, ఊహించకుండా పరీక్షను ప్లాన్ చేయండి.

MTU మూడవది. Bridged అతిథి LAN యొక్క 1500 బైట్ల MTUను నిలుపుకుంటాడు, తన సొంత WireGuard క్లయింట్ను 1420లో నడిపిస్తే, పెద్ద TLS హ్యాండ్షేక్లు నిలిచిపోతాయి, చిన్న అభ్యర్థనలు విజయవంతమవుతాయి. NATలో హోస్ట్ టన్నెల్ MTU హోస్ట్ సమస్య, కానీ అతిథి ఇంకా 1500నే నమ్ముతాడు, don't-fragment బిట్ పెట్టిన UDP అలాగే నల్ల గొయ్యలో పడుతుంది.

మోడ్ను రాసుకోండి, ఏదైనా అడాప్టర్ మార్పు తర్వాత మళ్లీ తనిఖీ చేయండి

మోడ్, బ్రిడ్జ్ ఉపయోగించే హోస్ట్ ఇంటర్ఫేస్, అతిథి డిఫాల్ట్ గేట్వే, అతని రిజాల్వర్, అతని v4 మరియు v6 నిష్క్రమణ చిరునామాలను నమోదు చేయండి. ఆ నమోదే తదుపరి వైఫల్యాన్ని చవకగా చేస్తుంది: ల్యాప్టాప్ dock నుండి Wi-Fiకి మారినప్పుడు, bridged అతిథి బ్రిడ్జ్ను వేరే భౌతిక అడాప్టర్కు అనుసరించి మరో సబ్నెట్లో తిరిగి లీజు తీసుకోవచ్చు, అదే సమయంలో NAT అతిథి తన 10.0.2.x చిరునామాను నిలుపుకుని వేరే అప్లింక్ను నిశ్శబ్దంగా వారసత్వంగా పొందుతాడు.

టికెట్ మూసే ముందు వీటిలో ప్రతిదాన్ని నిర్ధారించండి:

  • అతిథి నిష్క్రమణ చిరునామా హోస్ట్ నిష్క్రమణ చిరునామా నుండి భిన్నంగా ఉంటుంది, కాబట్టి అతను హోస్ట్ టన్నెల్లో లేడు.
  • రిజాల్వర్ 10.0.2.3 ప్రాక్సీ లేదా LAN సర్వర్, ఏది సమాధానం ఇచ్చిందో మీకు తెలుసు.
  • టన్నెల్ డిజైన్ v4 మాత్రమే అయితే అతిథిలో గ్లోబల్ v6 చిరునామా ఉండదు.
  • హోస్ట్ టన్నెల్ దిగినప్పుడు అతిథి బ్రౌజింగ్ ఆపేస్తాడు, లేదా అతను ఎప్పుడూ దానిపై ఆధారపడలేదని ఇప్పుడు మీకు తెలుసు.
  • తనకు చూడాల్సిన అవసరం లేని LAN ప్రసార ట్రాఫిక్ను అతిథి చూడడు.

సంబంధిత వ్యాసాలు