NAT eller bryggat VM-nätverk: vilket bär VPN-trafiken?

NAT-gäster lånar värdens tunnel bara om klienten tunnlar efter rutt; bryggade gäster routar sig själva. Testa gästen och välj sedan läge efter behov.

Bryggat och NAT är inte två sätt att koppla samma gäst till din VPN; de avgör vem som äger gästens paket innan någon tunnel alls är inblandad. I NAT-läge skriver hypervisorn om gästens trafik och skickar ut den från kod på värdsidan, så gästen åker på vilken rutt värden än ger den koden. I bryggat läge får gästen en egen identitet på länklagret på det fysiska segmentet och väljer egen standardgateway, vilket gör värdens tunnel irrelevant för den om inte LAN-routern är den som tunnlar. Jag slutade behandla den virtuella maskinen som något som ligger på VPN:en och började behandla det som en fråga om vart den gästens standardrutt pekar. Testet nedan tar några minuter per läge och avgör saken utan gissningar.

NAT håller gästen bakom hypervisor-kod, där värdens rutter gäller

I VirtualBox ligger en NAT-gäst på 10.0.2.0/24 med en virtuell gateway på 10.0.2.2, en DNS-proxy på 10.0.2.3 och ingen egen rutt till det fysiska nätet. Utgående paket tas av NAT-mekanismen, skrivs om så att källan blir värden och lämnas till värdens IP-stack. Därifrån är gästens trafik ett värdflöde, och ruttuppslagningen sker efter destination: en klient med full tunnel som installerar 0.0.0.0/1 och 128.0.0.0/1 på värden fångar den utan att någonsin veta att en VM finns. Oracles kapitel om nätverk i VirtualBox listar dessa standardvärden om du vill bekräfta adresserna i din build.

libvirts standardnät når samma plats från 192.168.122.0/24, där dnsmasq delar ut leasingar och värden maskerar subnätet, så gästens paket kommer åter till värdens ruttbeslut. Undantaget är en klient som väljer trafik per process i stället för per rutt. Om listan för delad tunnel bara innehåller din webbläsare finns NAT-mekanismen inte på den listan, och gästen lämnar maskinen utan tunnel medan webbläsaren på värden fortfarande ser täckt ut. Samma subnät, motsatt resultat.

Bryggat ger gästen en egen plats på det fysiska LAN:et

En bryggad gäst får ett virtuellt nätverkskort kopplat till en riktig adapter, får en egen MAC-adress och tar en DHCP-lease från det fysiska nätet. Dess standardgateway är LAN-routern, inte hypervisorn, och dess ramar går ut på kabeln via den adaptern. Värdens tunnelrutter ligger i värdens tabell och används aldrig, eftersom gästens ramar aldrig når värdens IP-stack.

Det skär åt båda hållen. mDNS- och SMB-bläddring börjar fungera eftersom gästen ser LAN:ets broadcasttrafik, och gästen blir nåbar från andra maskiner på samma segment utan någon brandvägg på värden emellan. Bryggning är inte heller ett sätt att pressa en gäst genom en befintlig tunnel: att koppla en VM till värdens WireGuard- eller OpenVPN-gränssnitt är inget som VirtualBox eller libvirt gör åt dig. Om en bryggad gäst måste tunnlas, måste tunneln sluta någonstans på det LAN:et.

Testet som avgör saken

Kör samma kontroller i båda lägena och skriv ner svaren:

  • På värden, curl -s https://ifconfig.me ger den publika v4-adressen.
  • I gästen samma kommando plus ip route på Linux eller Get-NetRoute -DestinationPrefix 0.0.0.0/0 på Windows för standardgatewayen.
  • Resolveridentitet: resolvectl status eller cat /etc/resolv.conf i gästen, för att se om den pekar på 10.0.2.3 eller på en LAN-server.
  • Adressfamilj: ip -6 addr show scope global och en v6-förfrågan, eftersom en v4-tunnel inte säger något om en global v6-adress som gästen kan ha.

Matchande publika adresser betyder att gästen är på värdens väg. En gästadress som matchar LAN:ets vanliga utgång betyder att den inte är det. Steget folk hoppar över är kontrollen: ta ner värdens tunnel och upprepa gästens begäran. Om gästen fortsätter bläddra har den aldrig varit beroende av värdens tunnel, vad lägets namn än antyder. I NAT-läge bör gästen tappa internet när värdens tunnel är nere, om inte klienten är konfigurerad att tillåta trafik utanför tunneln, vilket är värt att veta i sig.

Två signaler ljuger. En lyckad ping bevisar nåbarhet, inte utgångsväg. Och DNS kan besvaras av 10.0.2.3-proxyn genom värdens resolver medan TCP tar en annan rutt, och det är så man får en sida som laddas och en inloggning som aldrig slutförs.

Vilket läge som passar jobbet

Läget är ett ruttbeslut, så välj det efter kravet i stället för efter vanan:

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

Första raden är där folk åker dit: NAT plus en klient med full tunnel på värden täcker verkligen en gäst, men bara så länge klienten tunnlar efter rutt och värdens upplänk är den tunneln. Flytta klienten till en allowlist bara för webbläsaren och täckningen försvinner utan något fel någonstans. Fjärde raden är det omvända misstaget, en gäst som bryggats för enkelhetens skull och tyst börjar svara på SMB eller SSH i kontorets LAN.

Fel som skylls på VPN:en

På Windows körs NAT-översättningen inne i VirtualBox VM-processen, så en klient per app behöver just den imagen på sin lista i stället för en generell regel för virtuella maskiner. När en klientuppdatering bygger om sin processlista förlorar NAT-gäster täckningen först, och rapporten låter som en VM som når LAN:et men inte internet medan värden är okej.

Bryggning till Wi-Fi är den andra klassikern. Åtkomstpunkter vidarebefordrar sällan ramar med en främmande käll-MAC, så en brygga mot wlan0 antingen misslyckas direkt eller fungerar tills klientisoleringen på AP:n börjar släppa den. VirtualBox erbjuder fortfarande den trådlösa adaptern i sin lista. Om värden är på Wi-Fi och gästen måste bryggas, planera att testa i stället för att anta.

MTU är den tredje. En bryggad gäst behåller LAN:ets MTU på 1500 byte, och om den kör sin egen WireGuard-klient på 1420 stannar stora TLS-handskakningar medan små förfrågningar lyckas. Under NAT är värdens tunnel-MTU värdens problem, men gästen tror fortfarande på 1500, och UDP med don't-fragment-biten satt hamnar i svart hål på samma sätt.

Skriv ner läget och kontrollera igen efter varje adapterbyte

Anteckna läget, värdsgränssnittet som bryggan använder, gästens standardgateway, dess resolver och dess utgångsadresser för v4 och v6. Den anteckningen är det som gör nästa fel billigt: när en laptop flyttar från docka till Wi-Fi följer en bryggad gäst bryggan till en annan fysisk adapter och kan få ny lease i ett annat subnät, medan en NAT-gäst behåller sin 10.0.2.x-adress och tyst ärver en annan upplänk.

Innan ärendet stängs, bekräfta vart och ett av dessa:

  • Gästens utgångsadress skiljer sig från värdens utgångsadress, så den är inte på värdens tunnel.
  • Resolvern är 10.0.2.3-proxyn eller en LAN-server, och du vet vilken som svarade.
  • Ingen global v6-adress finns i gästen om tunneln är designad enbart för v4.
  • Med värdens tunnel nere slutar gästen bläddra, eller så vet du nu att den aldrig var beroende av den.
  • Gästen ser inte LAN:ets broadcasttrafik som den inte har något där att göra.

Relaterade artiklar