NAT teenoor gebrugde VM-netwerking: watter een dra VPN-verkeer?

NAT-gaste leen die gasheer se tonnel net as die kliënt per roete tonnel; gebrugde gaste roeteer hulself. Toets die gas, kies dan die modus wat pas.

Gebrugde en NAT is nie twee maniere om dieselfde gas by jou VPN aan te sluit nie; hulle bepaal wie die gas se pakkette besit voordat enige tonnel betrokke is . In NAT-modus herskryf die hipervisor die gas se verkeer en stuur dit uit vanaf gasheerkant-kode, so die gas ry op watter roete die gasheer ook al aan daardie kode gee. In gebrugde modus kry die gas sy eie skakellaag-identiteit op die fisiese segment en kies sy eie verstek-gateway, wat die gasheer se tonnel irrelevant maak vir hom, tensy dit die LAN-roeteerder is wat die tonnel maak. Ek het opgehou om die VM as op die VPN te beskou en dit begin behandel as 'n vraag oor waar daardie gas se verstekroete wys. Die toets hieronder neem 'n paar minute per modus en beslis dit sonder giswerk.

NAT hou die gas agter hipervisor-kode, waar gasheerroetes geld

In VirtualBox sit 'n NAT-gas op 10.0.2.0/24 met 'n virtuele gateway by 10.0.2.2, 'n DNS-proxy by 10.0.2.3, en geen eie roete na die fisiese netwerk nie. Uitgaande pakkette word deur die NAT-enjin geneem, herskryf sodat die bron die gasheer is, en na die gasheer se IP-stapel gestuur. Van daar af is die gas se verkeer 'n gasheervloei, en roetesoektog is per bestemming: 'n voltonnel-kliënt wat 0.0.0.0/1 en 128.0.0.0/1 op die gasheer installeer, vang dit sonder om ooit te weet 'n VM bestaan. Oracle se VirtualBox-netwerkhoofstuk lys hierdie verstekwaardes as jy die adresse op jou bou wil bevestig.

libvirt se versteknetwerk bereik dieselfde plek vanaf 192.168.122.0/24, waar dnsmasq huurkontrakte uitdeel en die gasheer die subnet maskeer, so die gas se pakkette kom weer by die gasheer se roetebesluit uit. Die uitsondering is 'n kliënt wat verkeer per proses kies eerder as per roete. As die split-tonnel-lys net jou blaaier bevat en niks anders nie, is die NAT-enjin nie op daardie lys nie, en die gas verlaat die masjien ongetonnel terwyl die gasheer se blaaier nog gedek lyk. Dieselfde subnet, teenoorgestelde resultaat.

Brugmodus gee die gas sy eie plek op die fisiese LAN

'n Gebrugde gas kry 'n virtuele NIC wat aan 'n werklike adapter gekoppel is, kry sy eie MAC-adres, en neem 'n DHCP-huurkontrak van die fisiese netwerk. Sy verstek-gateway is die LAN-roeteerder, nie die hipervisor nie, en sy rame gaan deur daardie adapter op die draad. Die gasheer se tonnelroetes woon in die gasheer se tabel en word nooit geraadpleeg nie, want die gas se rame betree nooit die gasheer se IP-stapel nie.

Dit sny na beide kante. mDNS- en SMB-blaaiery begin werk omdat die gas LAN-uitsendingverkeer sien, en die gas word bereikbaar vanaf ander masjiene op dieselfde segment sonder 'n gasheer-vuurmuur tussenin. Brugmodus is ook nie 'n manier om 'n gas deur 'n bestaande tonnel te stoot nie: om 'n VM aan die gasheer se WireGuard- of OpenVPN-koppelvlak te koppel, is nie iets wat VirtualBox of libvirt vir jou doen nie. As 'n gebrugde gas getonnel moet word, moet die tonnel êrens op daardie LAN eindig.

Die toets wat die argument besleg

Voer dieselfde kontroles in beide modusse uit en skryf die antwoorde neer:

  • Op die gasheer gee curl -s https://ifconfig.me die publieke v4-adres.
  • In die gas, dieselfde opdrag, plus ip route op Linux of Get-NetRoute -DestinationPrefix 0.0.0.0/0 op Windows vir die verstek-gateway.
  • Oplosser-identiteit: resolvectl status of cat /etc/resolv.conf in die gas, om te sien of dit na 10.0.2.3 of na 'n LAN-bediener wys.
  • Adresfamilie: ip -6 addr show scope global en een v6-versoek, want 'n v4-tonnel sê niks oor 'n globale v6-adres wat die gas mag hê nie.

Passende publieke adresse beteken die gas is op die gasheer se pad. 'n Gasadres wat by die LAN se gewone uitgang pas, beteken dit is nie. Die stap wat mense oorslaan, is die kontrole: bring die gasheer se tonnel af en herhaal die gas se versoek. As die gas aanhou blaai, het dit nooit van die gasheer se tonnel afgehang nie, wat die modusnaam ook al voorstel. In NAT-modus behoort die gas internet te verloor met die gasheer se tonnel af, tensy die kliënt gekonfigureer is om ongetonnelde verkeer toe te laat, wat op sigself die moeite werd is om te weet.

Twee seine lieg. 'n Suksesvolle ping bewys bereikbaarheid, nie uitgangspad nie. En DNS kan deur die 10.0.2.3-proxy via die gasheer se oplosser beantwoord word terwyl TCP 'n ander roete neem, en dit is hoe jy 'n bladsy kry wat laai en 'n aanmelding wat nooit voltooi nie.

Watter modus pas by die taak

Die modus is 'n roetebesluit, so kies dit uit die vereiste eerder as uit gewoonte:

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

Ry een is waar mense vasgekeer word: NAT plus 'n voltonnel-gasheerkliënt dek wel 'n gas, maar net terwyl die kliënt per roete tonnel en die gasheer se opverbinding daardie tonnel is. Skuif die kliënt na 'n slegs-blaaier-toelaatlys en die dekking verdwyn sonder enige fout. Ry vier is die omgekeerde fout, 'n gas wat vir gerief gebrug is en stilweg SMB of SSH op die kantoor-LAN begin beantwoord.

Foute wat die VPN kry die skuld

Op Windows loop die NAT-omsetting binne die VirtualBox VM-proses, so 'n per-app-kliënt het daardie presiese beeld op sy lys nodig eerder as 'n algemene reël vir virtuele masjiene. Wanneer 'n kliëntopdatering sy proses-toelaatlys herbou, verloor NAT-gaste eerste dekking, en die verslag lees soos 'n VM wat die LAN kan bereik maar nie die internet nie, terwyl die gasheer reg is.

Brugging na Wi-Fi is die ander klassieke geval. Toegangspunte stuur selde rame met 'n vreemde bron-MAC aan, so 'n brug na wlan0 misluk heeltemal of werk totdat kliënt-isolasie op die AP dit begin laat val. VirtualBox sal steeds die draadlose adapter in sy lys bied. As die gasheer op Wi-Fi is en die gas moet gebrug word, beplan om dit te toets eerder as om dit te aanvaar.

MTU is die derde. 'n Gebrugde gas behou die LAN se 1500-greep-MTU, en as dit sy eie WireGuard-kliënt op 1420 laat loop, stop groot TLS-handdrukke terwyl klein versoeke slaag. Onder NAT is die gasheer se tonnel-MTU die gasheer se probleem, maar die gas glo steeds in 1500, en UDP met die don't-fragment-bis ingeskakel maak dieselfde swartgat.

Skryf die modus neer en herkontroleer ná enige adapterverandering

Teken die modus aan, die gasheer-koppelvlak wat die brug gebruik, die gas se verstek-gateway, sy oplosser, en sy v4- en v6-uitgangsadresse. Daardie rekord is wat die volgende fout goedkoop maak: wanneer 'n skootrekenaar van dock na Wi-Fi beweeg, volg 'n gebrugde gas die brug na 'n ander fisiese adapter en kan dit in 'n ander subnet herhuur, terwyl 'n NAT-gas sy 10.0.2.x-adres behou en stilweg 'n ander opverbinding erf.

Voordat jy die kaartjie sluit, bevestig elkeen hiervan:

  • Die gas se uitgangsadres verskil van die gasheer se uitgangsadres, so dit is nie op die gasheer se tonnel nie.
  • Die oplosser is die 10.0.2.3-proxy of 'n LAN-bediener, en jy weet watter een geantwoord het.
  • Geen globale v6-adres bestaan in die gas as die tonnelontwerp slegs v4 is nie.
  • Met die gasheer se tonnel af, stop die gas met blaai, of jy weet nou dat dit nooit daarvan afgehang het nie.
  • Die gas sien nie LAN-uitsendingverkeer wat dit nie hoort te sien nie.

Verwante artikels