NAT eller broet VM-nettverk: hvilken bærer VPN-trafikken?

NAT-gjester låner vertens tunnel bare når klienten tunnelerer etter rute; broede gjester ruter selv. Test gjesten, og velg deretter modusen som passer.

Bro og NAT er ikke to måter å koble den samme gjesten til VPN-et ditt på; de avgjør hvem som eier gjestens pakker før en tunnel i det hele tatt er involvert. I NAT-modus skriver hypervisoren om gjestens trafikk og sender den ut fra kode på vertssiden, slik at gjesten følger hvilken som helst rute verten gir den koden. I broet modus får gjesten sin egen identitet på lenkelaget i det fysiske segmentet og velger sin egen standard gateway, noe som gjør vertens tunnel irrelevant for den, med mindre det er LAN-ruteren som tunnelerer. Jeg sluttet å behandle VM-en som noe som er på VPN-et og begynte å behandle det som et spørsmål om hvor standardruten til den gjesten peker. Testen nedenfor tar noen minutter per modus og avgjør det uten gjetting.

NAT holder gjesten bak hypervisorens kode, der vertens ruter gjelder

I VirtualBox sitter en NAT-gjest på 10.0.2.0/24 med en virtuell gateway på 10.0.2.2, en DNS-proxy på 10.0.2.3 og ingen egen rute til det fysiske nettverket. Utgående pakker tas av NAT-motoren, skrives om slik at kilden er verten, og sendes videre til IP-stakken til verten. Derfra er gjestens trafikk en vertsstrøm, og ruteoppslaget skjer etter destinasjon: en klient med full tunnel som installerer 0.0.0.0/1 og 128.0.0.0/1 på verten, fanger den uten å noensinne vite at en VM finnes. Oracles kapittel om VirtualBox-nettverk lister disse standardverdiene hvis du vil bekrefte adressene i din installasjon.

libvirts standardnettverk når samme sted fra 192.168.122.0/24, der dnsmasq deler ut leier og verten maskerer subnettet, slik at gjestens pakker igjen kommer til vertens rutevalg. Unntaket er en klient som velger trafikk etter prosess i stedet for etter rute. Hvis listen for delt tunnel bare inneholder nettleseren din og ingenting annet, er ikke NAT-motoren på den listen, og gjesten forlater maskinen uten tunnel mens nettleseren på verten fortsatt ser dekket ut. Samme subnett, motsatt resultat.

Bro gir gjesten sin egen plass på det fysiske LAN-et

En broet gjest får et virtuelt nettverkskort festet til en ekte adapter, får sin egen MAC-adresse og tar en DHCP-leie fra det fysiske nettverket. Standard gateway er LAN-ruteren, ikke hypervisoren, og rammene går ut på kabelen via den adapteren. Tunnelrutene til verten lever i tabellen til verten og blir aldri spurt, fordi rammene til gjesten aldri kommer inn i IP-stakken til verten.

Det skjærer begge veier. mDNS og SMB-blaing begynner å virke fordi gjesten ser kringkastetrafikken i LAN-et, og gjesten blir tilgjengelig fra andre maskiner i samme segment uten en brannmur på verten imellom. Bro er heller ikke en måte å dytte en gjest gjennom en eksisterende tunnel: å feste en VM til vertens WireGuard- eller OpenVPN-grensesnitt er ikke noe VirtualBox eller libvirt gjør for deg. Hvis en broet gjest må gjennom en tunnel, må tunnelen ende et sted på det LAN-et.

Testen som avgjør saken

Kjør de samme kontrollene i begge modus og skriv ned svarene:

  • På verten gir curl -s https://ifconfig.me den offentlige v4-adressen.
  • I gjesten den samme kommandoen, pluss ip route på Linux eller Get-NetRoute -DestinationPrefix 0.0.0.0/0 på Windows for standard gateway.
  • Identiteten til oppløseren: resolvectl status eller cat /etc/resolv.conf i gjesten, for å se om den peker på 10.0.2.3 eller på en LAN-server.
  • Adressefamilie: ip -6 addr show scope global og én v6-forespørsel, fordi en v4-tunnel ikke sier noe om en global v6-adresse som gjesten kan ha.

Sammenfallende offentlige adresser betyr at gjesten er på vertens vei. En gjesteadresse som samsvarer med LAN-ets vanlige utgang betyr at den ikke er det. Trinnet folk hopper over, er kontrollen: ta ned tunnelen til verten og gjenta forespørselen fra gjesten. Hvis gjesten fortsetter å bla, har den aldri vært avhengig av vertens tunnel, uansett hva modusnavnet antyder. I NAT-modus skal gjesten miste internett når tunnelen til verten er nede, med mindre klienten er konfigurert til å tillate trafikk uten tunnel, noe som er verdt å vite i seg selv.

To signaler lyver. En vellykket ping beviser nåbarhet, ikke utgangsvei. Og DNS kan besvares av 10.0.2.3-proxyen gjennom oppløseren til verten mens TCP tar en annen rute, og slik får du en side som lastes og en innlogging som aldri fullføres.

Hvilken modus passer til jobben

Modusen er et rutevalg, så velg den ut fra kravet og ikke ut 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

Første rad er der folk går i baret: NAT pluss en vertsklient med full tunnel dekker faktisk en gjest, men bare så lenge klienten tunnelerer etter rute og opplenken til verten er den tunnelen. Flytt klienten til en tillatelsesliste bare for nettleseren, og dekningen forsvinner uten noen feil noe sted. Fjerde rad er den motsatte feilen: en gjest som er broet for bekvemmelighet og som stille begynner å svare på SMB eller SSH på kontorets LAN.

Feil som blir lagt på VPN-et

På Windows kjører NAT-oversettelsen inne i VM-prosessen til VirtualBox, så en klient per applikasjon trenger nøyaktig det bildet på listen sin i stedet for en generell regel for virtuelle maskiner. Når en klientoppdatering bygger prosesslisten på nytt, mister NAT-gjester dekningen først, og rapporten leses som en VM som når LAN-et men ikke internett mens verten er i orden.

Bro til Wi-Fi er den andre klassikeren. Aksesspunkter videresender sjelden rammer med fremmed kilde-MAC, så en bro til wlan0 enten feiler helt eller virker til klientisolering på aksesspunktet begynner å slippe den. VirtualBox vil fortsatt tilby den trådløse adapteren på listen sin. Hvis verten er på Wi-Fi og gjesten må broes, planlegg å teste det i stedet for å anta det.

MTU er den tredje. En broet gjest beholder LAN-ets MTU på 1500 byte, og hvis den kjører sin egen WireGuard-klient på 1420, stopper store TLS-håndtrykk mens små forespørsler lykkes. Under NAT er MTU-en til vertens tunnel vertens problem, men gjesten tror fortsatt på 1500, og UDP med don't-fragment-biten satt forsvinner på samme måte.

Skriv ned modusen og sjekk på nytt etter hver adapterendring

Skriv ned modusen, vertsgrensesnittet broen bruker, standard gateway for gjesten, oppløseren dens og utgangsadressene dens for v4 og v6. Det er den registreringen som gjør den neste feilen billig: når en bærbar PC flytter seg fra docken til Wi-Fi, følger en broet gjest broen til en annen fysisk adapter og kan ta ny leie i et annet subnett, mens en NAT-gjest beholder 10.0.2.x-adressen sin og stille arver en annen opplenke.

Før du lukker saken, bekreft hvert av disse punktene:

  • Utgangsadressen til gjesten er forskjellig fra utgangsadressen til verten, så den er ikke på vertens tunnel.
  • Oppløseren er 10.0.2.3-proxyen eller en LAN-server, og du vet hvilken som svarte.
  • Det finnes ingen global v6-adresse i gjesten hvis tunneldesignet bare er v4.
  • Med tunnelen til verten nede slutter gjesten å bla, eller du vet nå at den aldri var avhengig av den.
  • Gjesten ser ikke kringkastetrafikk i LAN-et som den ikke har noe med.

Relaterte artikler