Zubia eta NAT ez dira gonbidatu bera zure VPNari lotzeko bi modu; haiek erabakitzen dute norenak diren gonbidatuaren paketeak tunela sartu aurretik. NAT moduan hiperbisoreak gonbidatuaren trafikoa berridazten du eta hostaren aldeko kodetik igortzen du, beraz gonbidatuak hostak kode horri ematen dion ibilbidea hartzen du. Modu zubidunean gonbidatuak bere identitatea lortzen du esteka-geruzan segmentu fisikoan eta bere ate lehenetsia aukeratzen du, eta horrek hostaren tunela hutsala egiten dio, LANeko bideratzailea den tunela egiten duena ez bada. VM-a VPNaren barruan zegoenik pentsatzeari utzi eta gonbidatu horren ibilbide lehenetsiak norantz egiten duen galderatzat hartzen hasi nintzen. Beheko probak minutu pare bat behar ditu modu bakoitzeko eta zalantzarik gabe argitzen du.

NAT-ek gonbidatua hiperbisorearen kodearen atzean mantentzen du, hostaren ibilbideak balio duten lekuan

VirtualBoxen NAT gonbidatu bat 10.0.2.0/24-n dago, ate birtual bat 10.0.2.2-n, DNS proxy bat 10.0.2.3-n eta ez du bere ibilbiderik sare fisikora. Irteerako paketeak NAT motorrak hartzen ditu, iturria hosta izan dadin berridazten ditu eta hostaren IP pilari pasatzen dizkio. Hortik aurrera gonbidatuaren trafikoa hostaren fluxua da, eta ibilbide bilaketa helmugaren araberakoa da: tunel osoko bezero batek 0.0.0.0/1 eta 128.0.0.0/1 hostan instalatzen baditu, harrapatu egiten du, VM bat badela inoiz jakin gabe. Oracle-ren VirtualBox sareen kapituluak zerrendatzen ditu balio lehenetsi horiek, zure eraikuntzan helbideak berretsi nahi badituzu.

libvirt-en sare lehenetsia toki berera iristen da 192.168.122.0/24-tik, non dnsmasq-k lizentziak banatzen dituen eta hostak azpisarea maskaratzen duen, beraz gonbidatuaren paketeak hostaren bideratze-erabakira iristen dira berriro. Salbuespena prozesuaren arabera eta ez ibilbidearen arabera hautatzen duen bezeroa da. Tunel zatituaren zerrendak zure nabigatzailea eta besterik ez badu, NAT motorra ez dago zerrenda horretan, eta gonbidatua makina uzten du tunelik gabe, hostaren nabigatzaileak estalita dirudi oraindik ere. Azpisare bera, kontrako emaitza.

Zubiak gonbidatuari bere lekua ematen dio LAN fisikoan

Zubidun gonbidatuari adapter erreal bati lotutako NIC birtuala ematen zaio, bere MAC helbidea lortzen du eta sare fisikotik DHCP lizentzia hartzen du. Bere ate lehenetsia LANeko bideratzailea da, ez hiperbisorea, eta bere markoak harira irteten dira adapter horren bidez. Hostaren tunel ibilbideak hostaren taulan bizi dira eta ez zaie inoiz galdetzen, gonbidatuaren markoak inoiz ez direlako hostaren IP pilara sartzen.

Horrek bi norabideetan mozten du. mDNS eta SMB arakatzea funtzionatzen hasten dira gonbidatuak LANeko difusio trafikoa ikusten duelako, eta gonbidatua segmentu bereko beste makinetatik eskura daiteke hostaren suebakirik tartean. Zubia ez da gonbidatua lehendik dagoen tunel batetik bultzatzeko modua ere: VM bat hostaren WireGuard edo OpenVPN interfazera lotzea ez da VirtualBoxek edo libvirtek zuretzat egiten duen zerbait. Zubidun gonbidatuak tunel bat behar badu, tunelak LAN horretan nonbait amaitu behar du.

Eztabaida amaitzen duen proba

Exekutatu egiaztapen berak bi moduetan eta idatzi erantzunak:

  • Hostan, curl -s https://ifconfig.me komandoak v4 helbide publikoa ematen du.
  • Gonbidatuan, komando bera, gehi ip route Linuxen edo Get-NetRoute -DestinationPrefix 0.0.0.0/0 Windowsean ate lehenetsirako.
  • Ebazlearen identitatea: resolvectl status edo cat /etc/resolv.conf gonbidatuan, 10.0.2.3-ra edo LANeko zerbitzari batera egiten duen ikusteko.
  • Helbide familia: ip -6 addr show scope global eta v6 eskaera bat, v4 tunel batek ez baitu ezer esaten gonbidatuak izan dezakeen v6 helbide global bati buruz.

Helbide publiko berdinak gonbidatua hostaren bidean dagoela esan nahi dute. LANaren ohiko irteerarekin bat datorren gonbidatu helbidea ez dagoela esan nahi du. Jendeak saltatzen duen urratsa kontrola da: jaitsi hostaren tunela eta errepikatu gonbidatuaren eskaera. Gonbidatuak nabigatzen jarraitzen badu, ez zen inoiz hostaren tunelaren mende egon, moduaren izenak zer iradokitzen duen ere. NAT moduan gonbidatuak internet galdu beharko luke hostaren tunela jaitsita, bezeroa tunelik gabeko trafikoa onartzeko konfiguratuta ez badago behintzat, eta hori bere horretan jakitea merezi du.

Bi seinale gezurretan ari dira. Ping arrakastatsu batek irisgarritasuna frogatzen du, ez irteera bidea. Eta DNS 10.0.2.3 proxyak erantzun dezake hostaren ebazlearen bidez, TCP beste ibilbide bat hartzen duen bitartean, horrela lortzen da kargatzen den orri bat eta inoiz amaitzen ez den saio-hasiera.

Zein modu egokitzen da lanerako

Modua bideratze erabakia da, beraz aukeratu baldintzaren arabera, ohituaren arabera beharrean:

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

Lehenengo ilara da jendea harrapatzen den lekua: NAT gehi tunel osoko host bezeroak gonbidatua estaltzen du, baina soilik bezeroak ibilbidearen arabera tunelatzen duen bitartean eta hostaren konexioa tunel hori den bitartean. Eraman bezeroa nabigatzaileari soilik onartutako zerrendara eta estaldura desagertzen da inolako errorarik gabe nonbait. Laugarren ilara kontrako akatsa da: erosotasunagatik zubidun jarritako gonbidatua, isil-isilik bulegoko LANean SMB edo SSHri erantzuten hasten dena.

VPNari egotzi ohi zaizkion hutsegiteak

Windowsean NAT itzulpena VirtualBox VM prozesuaren barruan exekutatzen da, beraz aplikazio bakoitzeko bezeroak irudi zehatz hori behar du bere zerrendan, makina birtualetarako arau orokor bat beharrean. Bezero baten eguneraketak bere prozesu zerrenda berreraikitzen duenean, NAT gonbidatuek galtzen dute estaldura lehenengo, eta txostenak LANera iristen den baina internetera iristen ez den VM baten itxura du, hosta ondo dagoen bitartean.

Wi-Fi-ra zubia egitea beste klasiko bat da. Sarbide-puntuek gutxitan bidaltzen dituzte iturri MAC arrotza duten markoak, beraz wlan0-rako zubiak huts egiten du erabat edo funtzionatzen du APko bezero isolamenduak botatzen duen arte. VirtualBoxek adapter haririk gabea eskainiko du oraindik bere zerrendan. Hostea Wi-Fi-n badago eta gonbidatua zubitu behar bada, probatzea planifikatu, suposatu beharrean.

MTU da hirugarrena. Zubidun gonbidatuak LANaren 1500 byteko MTUa mantentzen du, eta 1420-n bere WireGuard bezeroa exekutatzen badu, TLS eskuko heltzar handiak trabatu egiten dira eskaera txikiak lortzen diren bitartean. NATen pean hostaren tunelaren MTUa hostaren arazoa da, baina gonbidatuak 1500ean sinesten jarraitzen du, eta UDP don't-fragment bita ezarrita modu berean desagertzen da.

Idatzi modua eta berrikusi adapter aldaketa bakoitzaren ondoren

Idatzi modua, zubiak erabiltzen duen host interfazea, gonbidatuaren ate lehenetsia, bere ebazlea eta bere v4 eta v6 irteera helbideak. Erregistro horrek egiten du hurrengo hutsegitea merkea: ordenagailu eramangarria docketik Wi-Fi-ra aldatzen denean, zubidun gonbidatuak zubia jarraitzen du beste adapter fisiko batera eta agian beste azpisare batean lizentzia berritzen du, NAT gonbidatuak bere 10.0.2.x helbidea mantentzen duen bitartean eta isilka beste konexio bat heredatzen du.

Tiketa itxi aurretik, berretsi hauetako bakoitza:

  • Gonbidatuaren irteera helbidea hostaren irteera helbidetik desberdina da, beraz ez dago hostaren tunelean.
  • Ebazlea 10.0.2.3 proxyak edo LANeko zerbitzariak dira, eta badakizu zeinek erantzun duen.
  • Ez dago v6 helbide globalik gonbidatuan, tunelaren diseinua v4 soilik bada.
  • Hostaren tunela jaitsita, gonbidatuak nabigatzeari uzten dio, edo orain badakizu inoiz ez zela haren mende egon.
  • Gonbidatuak ez du ikusten berari dagokionik ez duen LANeko difusio trafikorik.

Erlazionatutako artikuluak