VirtualBox NAT eller bro: hvor VM-ens VPN slutter

To ulike spørsmål kommer samtidig hver gang en virtuell maskin kjører en VPN-klient, og de har ulike svar. Det første er om en tunnel inne i gjesten beskytter verten, og det andre er om en tunnel på verten dekker gjesten. Adaptermodusen avgjør begge, mer enn VPN-programvaren selv. En NAT-adapter gjør verten til det synlige endepunktet, mens en bro-adapter setter gjesten på nettet med sin egen adresse.

Hvem som faktisk avslutter den krypterte økten

En kryptert økt tilhører maskinen som avslutter den, og det er gjesten når klienten kjører inne i VM-en. Bare trafikk som går inn i gjestens virtuelle adapter passerer den tunnelen, og hypervisoren ruter aldri selv en annen maskin gjennom gjesten. Derfor kan gjesten holde en fungerende tunnel mens verten surfer åpent. Det motsatte er ikke symmetrisk, og nettopp den asymmetrien er delen de fleste veiledningene tar feil av.

Hvilken adresse det ytre nettet ser, er spørsmålet adaptermodusen besvarer. Når det er avgjort, slutter dekning å være et politisk spørsmål og blir et mekanisk et. Alt nedenfor følger av de to fakta.

NAT skriver om gjesten til den ligner verten

Med NAT skriver hypervisoren om hver pakke fra gjesten til vertens adresse før den når den første svitsjen. Den trafikken overleveres deretter til vertens egen nettverksstakk, hvor den følger vertens rutetabell, inkludert en standardrute som eies av en tunnel på verten. En NAT-gjest er derfor dekket av en tunnel på verten helt uten konfigurasjon, som er det motsatte av det tilfellet gjest til vert antyder.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

En gjest som kjører sin egen klient, avslutter den tunnelen inne i gjesten, og den krypterte trafikken forlater den deretter gjennom samme omskriving, slik at vertens programmer beholder sin egen vei og sin egen utgangsadresse. VirtualBox eier også navneoppslag i denne modusen og videresender gjestens spørringer gjennom sin egen motor med mindre --natdnshostresolver1 er aktivert. Aktiveres det, overleveres gjestens oppslag til vertens oppløser, som retter oppslaget når vertens eget bilde er riktig og like gjerne overleverer en oppløser som kanskje bare finnes inne i en tunnel. VM-en må være slått av før innstillingen endres, og innstillingen tilhører adapteren og ikke gjestens programvare.

Bro gir gjesten sin egen lease og sin egen eksponering

Bro sender gjestens rammer videre til det fysiske segmentet, så DHCP gir den en lease og nettet behandler den som en egen vert. Hver brokoblet gjest kan holde en uavhengig tunnel med sin egen standardrute, og vertens tabell endres aldri. Prisen er eksponering: gjesten svarer på kringkasting, vises i nabotabeller og kommer under portsikkerhet på svitsjen og isolasjon av trådløse klienter. En tunnel på verten dekker heller ikke denne ordningen, fordi gjestens rammer aldri går gjennom vertens stakk.

Den forskjellen fra NAT-tilfellet er verdt å si rett ut i stedet for å la den ligge som en antydning. En brokoblet gjest trenger sin egen klient og egne påloggingsdata hver gang trafikken må bruke en tunnel. Der gjesten må forbli usynlig for det lokale nettet, er NAT eller et rent internt nett med kontrollert ruting det bedre designet.

Hvorfor gjesten ikke kan være vertens gateway

Å låne en gjests tunnel til verten har ingen støttet svitsj i noen av de to store hypervisorene. Verten har ingen rute inn i gjestens tunnel og ingen oversettingsregel som peker på den, så gjestens og vertens trafikk forblir atskilte strømmer med atskilte eiere. Den retningen feiler uansett adaptermodus.

De brukbare erstatningene er videresendinger og proxyer. En lokal SSH-videresending lar verten koble til sin egen loopback mens gjesten bærer strømmen inn i tunnelen, noe som dekker TCP-tjenester uten å installere en ekstra klient. Å få vertens egen IP-trafikk til å bruke gjestens tunnel i stedet krever en ruter inne i gjesten pluss en uttrykkelig rute på verten og oversetting på verten. Det er et lite nettverksdesign og ikke en avkrysningsboks, og det trenger en plan for returveien. Når gjesten bare finnes for å kjøre klienten, sett klienten på verten og fjern det ekstra hoppet.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Oppløsere og ruter krysser ikke grensen

DNS følger adapteren som mottok valget, så en gjest arver ikke vertens tunneloppløser og en vert lærer aldri serveren som ble dyttet til gjesten. Dyttede dhcp-option DNS-verdier gjelder for grensesnittet som godtok dem, og derfor kan en brokoblet gjest uten klient ikke slå opp interne navn. En NAT-gjest bruker vanligvis hypervisorens DNS-håndtering i stedet, og forskjellen vises i én kommando per miljø.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Les oppløseren og ruten inne i gjesten før du antar at en av dem følger verten. Legg tunneloppløseren til gjestens egen adapter når interne navn må slås opp der, og bekreft deretter med et navn som bare finnes bak tunnelen. Noter adaptermodus, tunneleier og oppløserkilde for hver VM, fordi de tre fakta besvarer nesten ethvert senere spørsmål. Andre hypervisorer gir modusene nye navn og lar prinsippet være intakt.