NAT eller brokobling af VM-netværk: hvad bærer VPN-trafikken?

NAT-gæster låner kun værtens tunnel, når klienten tunnelerer efter rute; brokoblede gæster ruter selv. Test gæsten og vælg derefter den tilstand, der passer.

Brokobling og NAT er ikke to måder at koble den samme gæst til din VPN på; de afgør hvem der ejer gæstens pakker, før nogen tunnel er involveret. I NAT-tilstand omskriver hypervisoren gæstens trafik og sender den ud fra kode på værtssiden, så gæsten kører på den rute, værten giver den kode. I brokoblet tilstand får gæsten sin egen identitet på linklaget i det fysiske segment og vælger sin egen standardgateway, hvilket gør værtens tunnel irrelevant for den, medmindre det er LAN-routeren, der tunnelerer. Jeg holdt op med at betragte VM'en som værende på VPN'en og begyndte at betragte det som et spørgsmål om, hvor gæstens standardrute peger hen. Testen nedenfor tager et par minutter per tilstand og afgør det uden gætværk.

NAT holder gæsten bag hypervisorkode, hvor værtens ruter gælder

I VirtualBox sidder en NAT-gæst på 10.0.2.0/24 med en virtuel gateway på 10.0.2.2, en DNS-proxy på 10.0.2.3 og ingen egen rute til det fysiske netværk. Udgående pakker bliver taget af NAT-motoren, omskrevet så kilden er værten, og sendt videre til værtens IP-stak. Derfra er gæstens trafik et værtsflow, og ruteopslag sker efter destination: en fuldtunnel-klient, der installerer 0.0.0.0/1 og 128.0.0.0/1 på værten, fanger den uden nogensinde at vide, at der findes en VM. Oracles kapitel om VirtualBox-netværk lister disse standardværdier, hvis du vil bekræfte adresserne på din opsætning.

libvirts standardnetværk når samme sted fra 192.168.122.0/24, hvor dnsmasq uddeler leases, og værten maskerer undernettet, så gæstens pakker igen ender ved værtens rutevalg. Undtagelsen er en klient, der vælger trafik efter proces i stedet for efter rute. Hvis split-tunnel-listen indeholder din browser og intet andet, er NAT-motoren ikke på den liste, og gæsten forlader maskinen utunelleret, mens værtens browser stadig ser dækket ud. Samme undernet, modsat resultat.

Brokobling giver gæsten sin egen plads på det fysiske LAN

En brokoblet gæst får et virtuelt netkort knyttet til et rigtigt netkort, får sin egen MAC-adresse og henter en DHCP-lease fra det fysiske netværk. Dens standardgateway er LAN-routeren, ikke hypervisoren, og dens rammer går ud på ledningen gennem det netkort. Værtens tunnelruter ligger i værtens tabel og bliver aldrig konsulteret, fordi gæstens rammer aldrig kommer ind i værtens IP-stak.

Det skærer begge veje. mDNS og SMB-browsing begynder at virke, fordi gæsten ser LAN-broadcasttrafik, og gæsten bliver tilgængelig fra andre maskiner i samme segment uden nogen vært-firewall imellem. Brokobling er heller ikke en måde at skubbe en gæst gennem en eksisterende tunnel: at knytte en VM til værtens WireGuard- eller OpenVPN-grænseflade er ikke noget, VirtualBox eller libvirt gør for dig. Hvis en brokoblet gæst skal tunneleres, skal tunnelen afsluttes et sted på det LAN.

Testen, der afgør sagen

Kør de samme kontroller i begge tilstande, og skriv svarene ned:

  • På værten giver curl -s https://ifconfig.me den offentlige v4-adresse.
  • I gæsten den samme kommando plus ip route på Linux eller Get-NetRoute -DestinationPrefix 0.0.0.0/0 på Windows for standardgatewayen.
  • Resolverens identitet: resolvectl status eller cat /etc/resolv.conf i gæsten for at se, om den peger på 10.0.2.3 eller på en LAN-server.
  • Adressefamilie: ip -6 addr show scope global og én v6-forespørgsel, fordi en v4-tunnel intet siger om en global v6-adresse, som gæsten måtte have.

Matchende offentlige adresser betyder, at gæsten er på værtens vej. En gæsteadresse, der matcher LAN'ets sædvanlige udgang, betyder, at den ikke er. Det trin, folk springer over, er kontrollen: tag værtens tunnel ned, og gentag gæstens forespørgsel. Hvis gæsten bliver ved med at browse, afhang den aldrig af værtens tunnel, uanset hvad tilstandens navn antyder. I NAT-tilstand bør gæsten miste internetadgangen, når værtens tunnel er nede, medmindre klienten er konfigureret til at tillade utunelleret trafik, hvilket er værd at vide i sig selv.

To signaler lyver. Et vellykket ping beviser, at der er forbindelse, ikke hvilken udgangsvej der bruges. Og DNS kan besvares af 10.0.2.3-proxyen gennem værtens resolver, mens TCP tager en anden rute, og det er sådan, man får en side, der indlæses, og et login, der aldrig fuldføres.

Hvilken tilstand passer til opgaven

Tilstanden er et rutevalg, så vælg den ud fra kravet i stedet for ud fra vane:

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

Række et er der, hvor folk bliver fanget: NAT plus en fuldtunnel-værtsklient dækker faktisk en gæst, men kun så længe klienten tunnelerer efter rute, og værtens uplink er den tunnel. Flytter du klienten til en allowlist kun for browseren, forsvinder dækningen uden nogen fejl nogen steder. Række fire er den omvendte fejl: en gæst, der bliver brokoblet for nemheds skyld, og som stille begynder at svare på SMB eller SSH på kontorets LAN.

Fejl, der bliver skudt på VPN'en

På Windows kører NAT-oversættelsen inde i VirtualBox' VM-proces, så en per-app-klient har brug for netop den proces på sin liste i stedet for en blanket regel for virtuelle maskiner. Når en klientopdatering genopbygger sin procesliste, mister NAT-gæster dækningen først, og rapporten lyder som en VM, der kan nå LAN'et men ikke internettet, mens værten er fin.

Brokobling til Wi-Fi er den anden klassiker. Accesspunkter videresender sjældent rammer med en fremmed kilde-MAC, så en bro til wlan0 enten fejler helt eller virker, indtil klientisolering på accesspunktet begynder at droppe den. VirtualBox vil stadig tilbyde det trådløse netkort på sin liste. Hvis værten er på Wi-Fi, og gæsten skal brokobles, så planlæg at teste det i stedet for at antage det.

MTU er den tredje. En brokoblet gæst beholder LAN'ets MTU på 1500 byte, og hvis den kører sin egen WireGuard-klient på 1420, går store TLS-handshakes i stå, mens små forespørgsler lykkes. Under NAT er værtens tunnels MTU værtens problem, men gæsten tror stadig på 1500, og UDP med don't-fragment-bittet sat sort-huller på samme måde.

Skriv tilstanden ned, og tjek igen efter enhver adapterændring

Noter tilstanden, det værtsnetkort broen bruger, gæstens standardgateway, dens resolver og dens v4- og v6-udgangsadresser. Det er den registrering, der gør den næste fejl billig: når en bærbar flytter fra dock til Wi-Fi, følger en brokoblet gæst broen til et andet fysisk netkort og kan få lease i et andet undernet, mens en NAT-gæst beholder sin 10.0.2.x-adresse og stille arver en anden uplink.

Før du lukker sagen, skal du bekræfte hver af disse:

  • Gæstens udgangsadresse er forskellig fra værtens udgangsadresse, så den er ikke på værtens tunnel.
  • Resolveren er 10.0.2.3-proxyen eller en LAN-server, og du ved, hvilken der svarede.
  • Ingen global v6-adresse findes i gæsten, hvis tunneldesignet kun er v4.
  • Med værtens tunnel nede stopper gæsten med at browse, eller også ved du nu, at den aldrig afhang af den.
  • Gæsten ser ikke LAN-broadcasttrafik, den ikke har noget at gøre med.

Relaterede artikler