VirtualBox NAT ali most: kje se konča VPN virtualnega stroja

Dve različni vprašanji prideta skupaj vsakič, ko virtualni stroj zažene odjemalca VPN, in odgovora sta različna. Prvo je, ali tunel znotraj gosta ščiti gostitelja, in drugo, ali tunel na gostitelju pokriva gosta. Način adapterja odloči oboje, bolj kot sama programska oprema VPN. Adapter NAT naredi gostitelja vidno končno točko, medtem ko mostni adapter postavi gosta v omrežje z njegovim lastnim naslovom.

Kdo dejansko konča šifrirano sejo

Šifrirana seja pripada stroju, ki jo konča, in to je gost, ko odjemalec teče znotraj VM. Skozi ta tunel gre samo promet, ki vstopa v gostov virtualni adapter, in hipervizor nikoli sam ne usmerja drugega stroja skozi gosta. Zato lahko gost drži delujoč tunel, medtem ko gostitelj brska po odprtem omrežju. Obratno ni simetrično, in prav ta asimetrija je del, ki ga večina vodnikov zgreši.

Čigav naslov vidi zunanje omrežje, je vprašanje, na katero odgovarja način adapterja. Ko je to rešeno, pokritost preneha biti vprašanje politike in postane mehanska. Vse spodaj izhaja iz teh dveh dejstev.

NAT prepisuje gosta, dokler ni videti kot gostitelj

Pri NAT hipervizor prepiše vsak paket gosta na naslov gostitelja, preden doseže prvo stikalo. Ta promet se nato preda lastnemu omrežnemu skladu gostitelja, kjer sledi njegovi usmerjevalni tabeli, vključno s privzeto potjo, ki jo ima v lasti tunel na gostitelju. Gost NAT je torej pokrit s tunelom na gostitelju povsem brez konfiguracije, kar je nasprotje tega, kar nakazuje primer od gosta do gostitelja.

# 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, ki zažene svojega odjemalca, konča ta tunel znotraj gosta, šifriran promet pa nato odide skozi isto prepisovanje, tako da aplikacije gostitelja obdržijo svojo pot in svoj izhodni naslov. VirtualBox v tem načinu upravlja tudi razreševanje imen in pošilja poizvedbe gosta skozi svoj lastni mehanizem, razen če je --natdnshostresolver1 omogočen. Omogočanje preda iskanja gosta razreševalniku gostitelja, kar popravi razreševanje, ko je lasten pogled gostitelja pravilen, in enako preda razreševalnik, ki lahko obstaja samo znotraj tunela. VM je treba izklopiti pred spremembo nastavitve, in nastavitev pripada adapterju, ne programski opremi gosta.

Most da gostu njegov lastni najem in njegovo lastno izpostavljenost

Most pošlje okvire gosta v fizični segment, zato mu DHCP dodeli najem in omrežje z njim ravna kot z ločenim gostiteljem. Vsak gost na mostu lahko drži neodvisen tunel z lastno privzeto potjo, tabela gostitelja pa se nikoli ne spremeni. Cena je izpostavljenost: gost odgovarja na razpošiljanje, pojavlja se v tabelah sosedov in pride pod varnost vrat stikala ter izolacijo brezžičnih odjemalcev. Tunel na gostitelju tudi te postavitve ne pokrije, ker okviri gosta nikoli ne gredo skozi sklad gostitelja.

To razliko od primera NAT je vredno povedati naravnost, namesto da bi ostala kot namig. Gost na mostu potrebuje svojega odjemalca in svoje poverilnice vsakič, ko mora njegov promet uporabiti tunel. Kjer mora gost ostati neviden za krajevno omrežje, je NAT ali omrežje samo za notranjo rabo z nadzorovanim usmerjanjem boljša zasnova.

Zakaj gost ne more biti prehod gostitelja

Izposoja gostovega tunela gostitelju nima podprtega stikala v nobenem od dveh velikih hipervizorjev. Gostitelj nima poti v gostov tunel in nobenega pravila prevajanja, ki bi kazalo tja, zato promet gosta in gostitelja ostaneta ločena tokova z ločenimi lastniki. Ta smer ne uspe ne glede na način adapterja.

Delujoče nadomestilo sta posredovanji in posredniki. Krajevno posredovanje SSH omogoči gostitelju povezavo z lastno zanko, medtem ko gost nosi tok v tunel, kar pokrije storitve TCP brez namestitve drugega odjemalca. Prisiliti lasten promet IP gostitelja, naj namesto tega uporabi gostov tunel, zahteva usmerjevalnik znotraj gosta ter izrecno pot na gostitelju in prevajanje na gostitelju. To je majhna omrežna zasnova in ne kljukica, in potrebuje načrt za povratno pot. Ko gost obstaja le za poganjanje odjemalca, postavite odjemalca na gostitelja in odstranite odvečni skok.

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

Razreševalniki in poti ne prečkajo meje

DNS sledi adapterju, ki je prejel možnost, zato gost ne podeduje razreševalnika tunela gostitelja in gostitelj nikoli ne izve za strežnik, potisnjen gostu. Potisnjene vrednosti dhcp-option DNS veljajo za vmesnik, ki jih je sprejel, in zato gost na mostu brez odjemalca ne more razrešiti notranjih imen. Gost NAT običajno uporabi obdelavo DNS hipervizorja, in razlika se vidi v enem ukazu na okolje.

# 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

Preberite razreševalnik in pot znotraj gosta, preden domnevate, da kateri od njiju sledi gostitelju. Dodajte razreševalnik tunela lastnemu adapterju gosta, ko je treba notranja imena razrešiti tam, in nato preverite z imenom, ki obstaja samo za tunelom. Zapišite način adapterja, lastnika tunela in vir razreševalnika za vsak VM, ker ta tri dejstva odgovorijo na skoraj vsako poznejše vprašanje. Drugi hipervizorji načine preimenujejo in načelo pustijo nedotaknjeno.