VirtualBox NAT ili bridge: gdje završava VPN virtuelne mašine

Dva različita pitanja stižu zajedno kad god virtuelna mašina pokrene VPN klijent, a odgovori na njih su različiti. Prvo je da li tunel unutar gosta štiti host, a drugo je da li tunel na hostu pokriva gosta. Režim adaptera odlučuje o oba, više nego VPN softver. NAT adapter čini host vidljivom krajnjom tačkom, dok bridge adapter stavlja gosta na mrežu s vlastitom adresom.

Ko zapravo prekida šifrovanu sesiju

Šifrovana sesija pripada mašini koja je prekida, a to je gost kad klijent radi unutar VM-a. Kroz taj tunel prolazi samo saobraćaj koji ulazi u gostin virtuelni adapter, a hipervizor nikada sam ne usmjerava drugu mašinu kroz gosta. Zato gost može držati ispravan tunel dok host pregleda otvorenu mrežu. Obrnuto nije simetrično, i ta asimetrija je dio koji većina vodiča pogrešno shvati.

Čiju adresu vanjska mreža vidi je pitanje na koje odgovara režim adaptera. Kad se to riješi, pokrivenost prestaje biti pitanje politike i postaje mehaničko. Sve ispod proizlazi iz te dvije činjenice.

NAT prepisuje gosta dok ne počne ličiti na host

Uz NAT, hipervizor prepisuje svaki gostin paket na hostovu adresu prije nego što stigne do prvog preklopnika. Taj saobraćaj se zatim predaje hostovom vlastitom mrežnom steku, gdje slijedi hostovu tabelu rutiranja, uključujući zadanu rutu koju posjeduje tunel na hostu. NAT gost je stoga pokriven tunelom na hostu bez ikakve konfiguracije, što je suprotno od onoga što sugerira smjer od gosta prema hostu.

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

Gost koji pokreće vlastiti klijent prekida taj tunel unutar gosta, a šifrovani saobraćaj zatim izlazi kroz isto prepisivanje, pa hostove aplikacije zadržavaju vlastitu putanju i vlastitu izlaznu adresu. VirtualBox u ovom režimu upravlja i razrješavanjem imena, prosljeđujući gostine upite kroz vlastiti mehanizam osim ako nije uključen --natdnshostresolver1. Uključivanje predaje gostine pretrage hostovom razrješivaču, što ispravlja razrješavanje kad je hostov vlastiti pogled tačan i jednako tako predaje razrješivač koji može postojati samo unutar tunela. VM se mora isključiti prije promjene postavke, a postavka pripada adapteru, a ne gostinom softveru.

Bridge daje gostu vlastiti zakup i vlastitu izloženost

Bridge prosljeđuje gostine okvire na fizički segment, pa mu DHCP dodjeljuje zakup i mreža ga tretira kao odvojen host. Svaki gost na bridgeu može držati nezavisan tunel s vlastitom zadanom rutom, a hostova tabela se nikada ne mijenja. Cijena je izloženost: gost odgovara na emitovanje, pojavljuje se u tabelama susjeda i dolazi pod sigurnost portova preklopnika i izolaciju bežičnih klijenata. Tunel na hostu također ne pokriva ovaj raspored, jer gostini okviri nikada ne prolaze kroz hostov stek.

Tu razliku u odnosu na NAT slučaj vrijedi reći otvoreno, a ne ostaviti kao implikaciju. Gost na bridgeu treba vlastiti klijent i vlastite pristupne podatke kad god njegov saobraćaj mora ići kroz tunel. Gdje gost mora ostati nevidljiv lokalnoj mreži, NAT ili mreža samo za unutrašnju upotrebu s kontrolisanim rutiranjem je bolji dizajn.

Zašto gost ne može biti hostov gateway

Posuđivanje gostinog tunela hostu nema podržan prekidač ni u jednom od dva velika hipervizora. Host nema rutu u gostin tunel ni pravilo prevođenja koje pokazuje na njega, pa gostin i hostov saobraćaj ostaju odvojeni tokovi s odvojenim vlasnicima. Taj smjer ne radi bez obzira na režim adaptera.

Upotrebljive zamjene su prosljeđivanja i proksiji. SSH lokalno prosljeđivanje omogućava hostu da se poveže na vlastiti loopback dok gost nosi tok u tunel, što pokriva TCP servise bez instaliranja drugog klijenta. Natjerati hostov vlastiti IP saobraćaj da umjesto toga koristi gostin tunel zahtijeva ruter unutar gosta plus izričitu rutu na hostu i prevođenje na hostu. To je mali mrežni dizajn, a ne kućica za označavanje, i traži plan za povratnu putanju. Kad gost postoji isključivo da bi pokretao klijent, stavite klijent na host i uklonite dodatni skok.

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

Razrješivači i rute ne prelaze granicu

DNS slijedi adapter koji je primio opciju, pa gost ne nasljeđuje razrješivač hostovog tunela i host nikada ne sazna server koji je gostu gurnut. Gurnute vrijednosti dhcp-option DNS važe za interfejs koji ih je prihvatio, i zato gost na bridgeu bez klijenta ne može razriješiti unutrašnja imena. NAT gost obično koristi hipervizorovo rukovanje DNS-om, a razlika se vidi u jednoj komandi po okruženju.

# 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

Pročitajte razrješivač i rutu unutar gosta prije nego što pretpostavite da bilo koje od toga slijedi host. Dodajte razrješivač tunela gostinom vlastitom adapteru kad se unutrašnja imena moraju razriješiti tamo, pa provjerite imenom koje postoji samo iza tunela. Zabilježite režim adaptera, vlasnika tunela i izvor razrješivača za svaki VM, jer te tri činjenice odgovaraju na gotovo svako kasnije pitanje. Drugi hipervizori preimenuju režime i ostavljaju princip netaknutim.