VirtualBox NAT eller bru: kvar VPN-en til VM-en sluttar

To ulike spørsmål kjem saman kvar gong ein virtuell maskin køyrer ein VPN-klient, og dei har ulike svar. Det første er om ein tunnel inne i gjesten vernar verten, og det andre er om ein tunnel på verten dekkjer gjesten. Adaptermodusen avgjer begge, meir enn VPN-programvara sjølv. Ein NAT-adapter gjer verten til det synlege endepunktet, medan ein bru-adapter set gjesten på nettet med si eiga adresse.

Kven som faktisk avsluttar den krypterte økta

Ei kryptert økt høyrer til maskina som avsluttar ho, og det er gjesten når klienten køyrer inne i VM-en. Berre trafikk som går inn i den virtuelle adapteren til gjesten, passerer den tunnelen, og hypervisoren ruter aldri sjølv ei anna maskin gjennom gjesten. Difor kan gjesten halda ein fungerande tunnel medan verten surfar ope. Det motsette er ikkje symmetrisk, og nettopp den asymmetrien er delen dei fleste rettleiingane tek feil av.

Kva adresse det ytre nettet ser, er spørsmålet adaptermodusen svarar på. Når det er avgjort, sluttar dekning å vera eit politisk spørsmål og vert eit mekanisk eitt. Alt nedanfor følgjer av dei to fakta.

NAT skriv om gjesten til han liknar verten

Med NAT skriv hypervisoren om kvar pakke frå gjesten til adressa til verten før ho når den første svitsjen. Den trafikken vert så overlevert til nettverksstakken til verten sjølv, der han følgjer rutetabellen hans, inkludert ei standardrute som er eigd av ein tunnel på verten. Ein NAT-gjest er difor dekt av ein tunnel på verten heilt utan konfigurasjon, som er det motsette av det tilfellet gjest til vert antydar.

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

Ein gjest som køyrer sin eigen klient, avsluttar den tunnelen inne i gjesten, og den krypterte trafikken forlèt han deretter gjennom same omskriving, slik at programma på verten held si eiga rute og si eiga utgangsadresse. VirtualBox eig òg namneoppslag i denne modusen og sender spørjingane til gjesten gjennom sin eigen motor med mindre --natdnshostresolver1 er slått på. Vert det slått på, vert oppslaga til gjesten overlevert til oppløysaren til verten, som rettar oppslaget når biletet til verten sjølv er rett og like gjerne overleverer ein oppløysar som kanskje berre finst inne i ein tunnel. VM-en må vera slått av før innstillinga vert endra, og innstillinga høyrer til adapteren og ikkje til programvara til gjesten.

Bru gjev gjesten eigen leige og eigen eksponering

Bru sender rammene til gjesten vidare til det fysiske segmentet, så DHCP gjev han ei leige og nettet handsamar han som ein eigen vert. Kvar brukopla gjest kan halda ein uavhengig tunnel med si eiga standardrute, og tabellen til verten vert aldri endra. Prisen er eksponering: gjesten svarar på kringkasting, syner seg i nabotabellar og kjem under porttryggleik på svitsjen og isolasjon av trådlause klientar. Ein tunnel på verten dekkjer heller ikkje denne ordninga, fordi rammene til gjesten aldri går gjennom stakken til verten.

Den skilnaden frå NAT-tilfellet er verdt å seia rett ut i staden for å lata han liggja som eit hint. Ein brukopla gjest treng sin eigen klient og eigne påloggingsdata kvar gong trafikken må bruka ein tunnel. Der gjesten må halda seg usynleg for det lokale nettet, er NAT eller eit reint internt nett med kontrollert ruting det betre designet.

Kvifor gjesten ikkje kan vera gatewayen til verten

Å låna tunnelen til ein gjest til verten har ingen støtta svitsj i nokon av dei to store hypervisorane. Verten har inga rute inn i tunnelen til gjesten og inga omsetjingsregel som peikar på han, så trafikken til gjesten og verten held fram som skilde straumar med skilde eigarar. Den retninga feilar uansett adaptermodus.

Dei brukbare erstatningane er vidaresendingar og proxyar. Ei lokal SSH-vidaresending lèt verten kopla til sin eigen loopback medan gjesten ber straumen inn i tunnelen, noko som dekkjer TCP-tenester utan å installera ein ekstra klient. Å få eigen IP-trafikk på verten til å bruka tunnelen til gjesten i staden krev ein ruter inne i gjesten pluss ei uttrykkeleg rute på verten og omsetjing på verten. Det er eit lite nettverksdesign og ikkje ein avkryssingsboks, og det treng ein plan for returvegen. Når gjesten berre finst for å køyra klienten, set klienten på verten og fjern det ekstra hoppet.

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

Oppløysarar og ruter kryssar ikkje grensa

DNS følgjer adapteren som fekk valet, så ein gjest arvar ikkje tunneloppløysaren til verten og ein vert lærer aldri serveren som vart dytta til gjesten. Dytte dhcp-option DNS-verdiar gjeld for grensesnittet som tok imot dei, og difor kan ein brukopla gjest utan klient ikkje slå opp interne namn. Ein NAT-gjest brukar vanlegvis DNS-handteringa til hypervisoren i staden, og skilnaden syner seg i ein 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øysaren og ruta inne i gjesten før du reknar med at ein av dei følgjer verten. Legg tunneloppløysaren til den eigen adapteren til gjesten når interne namn må slåast opp der, og stadfest deretter med eit namn som berre finst bak tunnelen. Noter adaptermodus, tunneleigar og oppløysarkjelde for kvar VM, fordi dei tre fakta svarar på nesten kvart seinare spørsmål. Andre hypervisorar gjev modusane nye namn og lèt prinsippet vera intakt.