VirtualBox NAT nebo bridge: kde končí VPN virtuálního stroje

Dvě různé otázky přicházejí společně pokaždé, když virtuální stroj spustí VPN klienta, a mají různé odpovědi. První je, zda tunel uvnitř hosta chrání hostitele, a druhá, zda tunel na hostiteli pokrývá hosta. Režim adaptéru rozhoduje obojí, víc než samotný VPN software. Adaptér NAT dělá z hostitele viditelný koncový bod, zatímco bridge adaptér staví hosta na síť s jeho vlastní adresou.

Kdo šifrovanou relaci skutečně ukončuje

Šifrovaná relace patří stroji, který ji ukončuje, a to je host, když klient běží uvnitř VM. Tímto tunelem prochází jen provoz, který vstupuje do hostova virtuálního adaptéru, a hypervizor nikdy sám neposílá jiný stroj skrz hosta. Proto může host držet funkční tunel, zatímco hostitel prohlíží otevřenou síť. Opak není symetrický a právě tato asymetrie je část, kterou většina návodů plete.

Čí adresu vidí vnější síť, je otázka, na kterou odpovídá režim adaptéru. Jakmile je to vyřešené, pokrytí přestává být otázkou politiky a stává se mechanickým. Vše níže plyne z těchto dvou faktů.

NAT přepisuje hosta, dokud nevypadá jako hostitel

U NAT hypervizor přepisuje každý hostův packet na adresu hostitele ještě předtím, než dorazí k prvnímu přepínači. Tento provoz se pak předá vlastnímu síťovému zásobníku hostitele, kde se řídí jeho směrovací tabulkou, včetně výchozí trasy, kterou vlastní tunel na hostiteli. Host pod NAT je tedy pokryt tunelem na hostiteli zcela bez konfigurace, což je opak toho, co naznačuje směr od hosta k hostiteli.

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

Host, který spouští vlastního klienta, ukončuje tento tunel uvnitř hosta a šifrovaný provoz pak vychází stejnou přepisovací cestou, takže aplikace hostitele si zachovávají vlastní cestu i vlastní výstupní adresu. VirtualBox v tomto režimu vlastní i překlad jmen a předává dotazy hosta vlastním mechanismem, dokud není zapnutý --natdnshostresolver1. Zapnutí předá hledání hosta resolveru hostitele, což opraví překlad, když je vlastní pohled hostitele správný, a stejně tak předá resolver, který může existovat jen uvnitř tunelu. VM se musí před změnou nastavení vypnout a nastavení patří adaptéru, ne softwaru hosta.

Bridge dává hostovi vlastní pronájem i vlastní vystavení

Bridge předává hostovy rámce na fyzický segment, takže mu DHCP přidělí pronájem a síť s ním zachází jako se samostatným hostitelem. Každý host na bridge může držet nezávislý tunel s vlastní výchozí trasou a tabulka hostitele se nikdy nemění. Cenou je vystavení: host odpovídá na broadcasty, objevuje se v tabulkách sousedů a dostává se pod zabezpečení portů přepínače a izolaci bezdrátových klientů. Tunel na hostiteli tuto sestavu také nepokrývá, protože rámce hosta nikdy neprocházejí zásobníkem hostitele.

Tento rozdíl oproti případu NAT stojí za to říct přímo, místo aby zůstal jen jako důsledek. Host na bridge potřebuje vlastního klienta a vlastní přihlašovací údaje, kdykoli jeho provoz musí jít tunelem. Tam, kde má host zůstat pro místní síť neviditelný, je lepším návrhem NAT nebo síť jen pro vnitřní použití s řízeným směrováním.

Proč host nemůže být branou hostitele

Půjčit tunel hosta hostiteli nemá podporovaný přepínač ani v jednom ze dvou velkých hypervizorů. Hostitel nemá trasu do tunelu hosta ani překladové pravidlo, které by na něj ukazovalo, takže provoz hosta a hostitele zůstává oddělenými toky s oddělenými vlastníky. Tento směr nefunguje bez ohledu na režim adaptéru.

Funkčními náhradami jsou přesměrování a proxy. Lokální SSH přesměrování umožní hostiteli připojit se k vlastnímu loopbacku, zatímco host nese proud do tunelu, což pokrývá TCP služby bez instalace druhého klienta. Přimět vlastní IP provoz hostitele, aby místo toho použil tunel hosta, vyžaduje router uvnitř hosta plus výslovnou trasu na hostiteli a překlad na hostiteli. To je malý síťový návrh, ne zaškrtávací políčko, a potřebuje plán pro zpáteční cestu. Když host existuje jen kvůli klientovi, dejte klienta na hostitele a odstraňte nadbytečný skok.

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

Resolvery a trasy nepřekračují hranici

DNS následuje adaptér, který volbu přijal, takže host nedědí resolver tunelu hostitele a hostitel se nikdy nedozví server vtlačený hostovi. Vtlačené hodnoty dhcp-option DNS platí pro rozhraní, které je přijalo, a proto host na bridge bez klienta nemůže přeložit vnitřní jména. Host pod NAT obvykle používá zpracování DNS hypervizoru a rozdíl je vidět jedním příkazem v každém prostředí.

# 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

Přečtěte si resolver a trasu uvnitř hosta, než předpokládáte, že některý z nich následuje hostitele. Přidejte resolver tunelu k vlastnímu adaptéru hosta, když se tam mají vnitřní jména překládat, a pak to ověřte jménem, které existuje jen za tunelem. Zapište režim adaptéru, vlastníka tunelu a zdroj resolveru pro každou VM, protože tyto tři skutečnosti odpovídají téměř na každou další otázku. Jiné hypervizory režimy přejmenovávají a princip nechávají nedotčený.