VirtualBox NAT eller bridge: hvor VM'ens VPN slutter

To forskellige spørgsmål kommer samtidig, når en virtuel maskine kører en VPN-klient, og de har forskellige svar. Det første er, om en tunnel inde i gæsten beskytter værten, og det andet er, om en tunnel på værten dækker gæsten. Adaptertilstanden afgør begge, mere end VPN-softwaren gør. En NAT-adapter gør værten til det synlige endepunkt, mens en bridge-adapter sætter gæsten på nettet med sin egen adresse.

Hvem der faktisk afslutter den krypterede session

En krypteret session tilhører den maskine, der afslutter den, og det er gæsten, når klienten kører inde i VM'en. Kun trafik, der går ind i gæstens virtuelle adapter, passerer den tunnel, og hypervisoren sender aldrig selv en anden maskine gennem gæsten. Derfor kan gæsten holde en fungerende tunnel, mens værten browser i det åbne. Det omvendte er ikke symmetrisk, og netop den asymmetri er den del, de fleste vejledninger tager fejl af.

Hvis adresse det ydre netværk ser, er det spørgsmål, adaptertilstanden besvarer. Når det er afklaret, holder dækning op med at være et politikspørgsmål og bliver et mekanisk et. Alt nedenfor følger af de to kendsgerninger.

NAT omskriver gæsten, til den ligner værten

Med NAT omskriver hypervisoren hver pakke fra gæsten til værtens adresse, før den når den første switch. Den trafik overdrages derefter til værtens egen netværksstak, hvor den følger værtens routingtabel, inklusive en standardrute, som en tunnel på værten ejer. En NAT-gæst er derfor dækket af en tunnel på værten helt uden konfiguration, hvilket er det modsatte af, hvad tilfældet gæst til vært 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 gæst, der kører sin egen klient, afslutter den tunnel inde i gæsten, og den krypterede trafik forlader den derefter gennem samme omskrivning, så værtens programmer beholder deres egen vej og deres egen udgangsadresse. VirtualBox ejer også navneopløsningen i denne tilstand og videresender gæstens forespørgsler gennem sin egen motor, medmindre --natdnshostresolver1 er aktiveret. Aktiveres den, overdrages gæstens opslag til værtens resolver, hvilket retter opløsningen, når værtens eget billede er rigtigt, og lige så vel overdrager en resolver, der måske kun findes inde i en tunnel. VM'en skal være slukket, før indstillingen ændres, og indstillingen hører til adapteren frem for gæstens software.

Bridge giver gæsten sin egen lease og sin egen eksponering

Bridge sender gæstens frames videre til det fysiske segment, så DHCP giver den en lease, og netværket behandler den som en selvstændig vært. Hver bridget gæst kan holde en uafhængig tunnel med sin egen standardrute, og værtens tabel ændrer sig aldrig. Prisen er eksponering: gæsten svarer på broadcast, optræder i nabo-tabeller og bliver underlagt port-sikkerhed på switchen og isolering af trådløse klienter. En tunnel på værten dækker heller ikke denne opsætning, fordi gæstens frames aldrig passerer værtens stak.

Den forskel fra NAT-tilfældet er værd at sige ligeud i stedet for at lade den ligge som en antydning. En bridget gæst har brug for sin egen klient og sine egne legitimationsoplysninger, hver gang dens trafik skal bruge en tunnel. Hvor gæsten skal forblive usynlig for det lokale netværk, er NAT eller et rent internt netværk med kontrolleret routing det bedre design.

Hvorfor gæsten ikke kan være værtens gateway

At låne en gæsts tunnel til værten har ingen understøttet kontakt i nogen af de to store hypervisorer. Værten har ingen rute ind i gæstens tunnel og ingen oversættelsesregel, der peger på den, så gæstens og værtens trafik forbliver adskilte strømme med adskilte ejere. Den retning fejler uanset adaptertilstand.

De brugbare erstatninger er videresendelser og proxyer. En lokal SSH-videresendelse lader værten forbinde til sit eget loopback, mens gæsten bærer strømmen ind i tunnelen, hvilket dækker TCP-tjenester uden at installere en ekstra klient. At få værtens egen IP-trafik til at bruge gæstens tunnel i stedet kræver en router inde i gæsten plus en udtrykkelig rute på værten og oversættelse på værten. Det er et lille netværksdesign og ikke et flueben, og det kræver en plan for returvejen. Når gæsten kun findes for at køre klienten, sæt klienten på værten og fjern det ekstra hop.

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

Resolvere og ruter krydser ikke grænsen

DNS følger den adapter, der modtog indstillingen, så en gæst arver ikke værtens tunnel-resolver, og en vært lærer aldrig den server, der blev skubbet til gæsten. Skubbede dhcp-option DNS-værdier gælder for det interface, der accepterede dem, og derfor kan en bridget gæst uden klient ikke opløse interne navne. En NAT-gæst bruger normalt hypervisorens DNS-håndtering i stedet, og forskellen viser sig i én kommando pr. 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

Læs resolveren og ruten inde i gæsten, før du antager, at en af dem følger værten. Føj tunnel-resolveren til gæstens egen adapter, når interne navne skal opløses der, og verificér derefter med et navn, der kun findes bag tunnelen. Notér adaptertilstand, tunnelejer og resolverkilde for hver VM, fordi de tre kendsgerninger besvarer næsten ethvert senere spørgsmål. Andre hypervisorer omdøber tilstandene og lader princippet være intakt.