VirtualBox NAT alebo most: kde sa končí VPN virtuálneho stroja

Dve rôzne otázky prichádzajú spolu vždy, keď virtuálny stroj spustí VPN klienta, a majú rôzne odpovede. Prvá je, či tunel vnútri hosťa chráni hostiteľa, a druhá, či tunel na hostiteľovi pokrýva hosťa. Režim adaptéra rozhoduje o oboch, viac než samotný VPN softvér. Adaptér NAT robí z hostiteľa viditeľný koncový bod, kým mostový adaptér stavia hosťa na sieť s jeho vlastnou adresou.

Kto šifrovanú reláciu skutočne ukončuje

Šifrovaná relácia patrí stroju, ktorý ju ukončuje, a to je hosť, keď klient beží vo vnútri VM. Týmto tunelom prechádza len prevádzka, ktorá vstupuje do hosťovho virtuálneho adaptéra, a hypervízor nikdy sám neposiela iný stroj cez hosťa. Preto môže hosť držať funkčný tunel, kým hostiteľ prehliada otvorenú sieť. Opak nie je symetrický, a práve táto asymetria je časť, ktorú väčšina návodov mýli.

Čiu adresu vidí vonkajšia sieť, je otázka, na ktorú odpovedá režim adaptéra. Keď je to vyriešené, pokrytie prestáva byť otázkou politiky a stáva sa mechanickým. Všetko nižšie vyplýva z týchto dvoch faktov.

NAT prepisuje hosťa, kým nevyzerá ako hostiteľ

Pri NAT hypervízor prepisuje každý hosťov paket na adresu hostiteľa skôr, než sa dostane k prvému prepínaču. Táto prevádzka sa potom odovzdá vlastnému sieťovému zásobníku hostiteľa, kde sa riadi jeho smerovacou tabuľkou vrátane predvolenej trasy, ktorú vlastní tunel na hostiteľovi. Hosť pod NAT je teda pokrytý tunelom na hostiteľovi úplne bez konfigurácie, čo je opak toho, čo naznačuje smer od hosťa k hostiteľovi.

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

Hosť, ktorý spúšťa vlastného klienta, ukončuje ten tunel vnútri hosťa, a šifrovaná prevádzka potom vychádza tou istou prepisovacou cestou, takže aplikácie hostiteľa si zachovávajú vlastnú cestu aj vlastnú výstupnú adresu. VirtualBox v tomto režime vlastní aj preklad mien a posiela dopyty hosťa cez vlastný mechanizmus, pokiaľ nie je zapnutý --natdnshostresolver1. Zapnutie odovzdá hľadanie hosťa resolveru hostiteľa, čo opraví preklad, keď je vlastný pohľad hostiteľa správny, a rovnako odovzdá resolver, ktorý môže existovať len vnútri tunela. VM sa musí pred zmenou nastavenia vypnúť a nastavenie patrí adaptéru, nie softvéru hosťa.

Most dáva hosťovi vlastný nájom aj vlastné vystavenie

Most posiela rámce hosťa na fyzický segment, takže mu DHCP pridelí nájom a sieť s ním zaobchádza ako so samostatným hostiteľom. Každý hosť na moste môže držať nezávislý tunel s vlastnou predvolenou trasou a tabuľka hostiteľa sa nikdy nemení. Cenou je vystavenie: hosť odpovedá na vysielanie, objavuje sa v tabuľkách susedov a dostáva sa pod zabezpečenie portov prepínača a izoláciu bezdrôtových klientov. Tunel na hostiteľovi toto usporiadanie tiež nepokrýva, pretože rámce hosťa nikdy neprechádzajú zásobníkom hostiteľa.

Tento rozdiel oproti prípadu NAT stojí za to povedať priamo, namiesto toho, aby zostal len ako dôsledok. Hosť na moste potrebuje vlastného klienta a vlastné prihlasovacie údaje vždy, keď jeho prevádzka musí ísť tunelom. Tam, kde má hosť zostať pre miestnu sieť neviditeľný, je lepším návrhom NAT alebo sieť len pre vnútorné použitie s riadeným smerovaním.

Prečo hosť nemôže byť bránou hostiteľa

Požičať tunel hosťa hostiteľovi nemá podporovaný prepínač ani v jednom z dvoch veľkých hypervízorov. Hostiteľ nemá trasu do tunela hosťa ani prekladové pravidlo, ktoré by naň ukazovalo, takže prevádzka hosťa a hostiteľa zostáva oddelenými tokmi s oddelenými vlastníkmi. Tento smer nefunguje bez ohľadu na režim adaptéra.

Funkčnými náhradami sú presmerovania a proxy. Lokálne SSH presmerovanie umožní hostiteľovi pripojiť sa k vlastnému loopbacku, kým hosť nesie tok do tunela, čo pokrýva TCP služby bez inštalácie druhého klienta. Prinútiť vlastnú IP prevádzku hostiteľa, aby namiesto toho použila tunel hosťa, vyžaduje router vnútri hosťa plus výslovnú trasu na hostiteľovi a preklad na hostiteľovi. To je malý sieťový návrh, nie zaškrtávacie políčko, a potrebuje plán pre spiatočnú cestu. Keď hosť existuje len kvôli klientovi, dajte klienta na hostiteľa a odstráňte nadbytočný skok.

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

Resolvery a trasy neprekračujú hranicu

DNS nasleduje adaptér, ktorý voľbu prijal, takže hosť nededia resolver tunela hostiteľa a hostiteľ sa nikdy nedozvie server vtláčaný hosťovi. Vtlačené hodnoty dhcp-option DNS platia pre rozhranie, ktoré ich prijalo, a preto hosť na moste bez klienta nedokáže preložiť vnútorné mená. Hosť pod NAT zvyčajne používa spracovanie DNS hypervízora a rozdiel je vidieť jediným príkazom v každom prostredí.

# 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

Prečítajte si resolver a trasu vnútri hosťa skôr, než predpokladáte, že niektorý z nich nasleduje hostiteľa. Pridajte resolver tunela k vlastnému adaptéru hosťa, keď sa tam majú vnútorné mená prekladať, a potom to overte menom, ktoré existuje len za tunelom. Zapíšte režim adaptéra, vlastníka tunela a zdroj resolvera pre každú VM, pretože tieto tri skutočnosti odpovedajú na takmer každú ďalšiu otázku. Iné hypervízory režimy premenúvajú a princíp nechávajú nedotknutý.