VirtualBox NAT vagy híd: hol végződik a VM VPN-je

Két különböző kérdés érkezik egyszerre, valahányszor egy virtuális gép VPN-klienst futtat, és a válaszuk eltér. Az első az, hogy a vendég belsejében futó alagút védi-e a gazdagépet, a második pedig az, hogy a gazdagépen futó alagút lefedi-e a vendéget. Az adapter módja dönti el mindkettőt, jobban, mint maga a VPN-szoftver. A NAT-adapter teszi a gazdagépet látható végponttá, míg a híd-adapter saját címével helyezi a vendéget a hálózatra.

Ki véglegesíti valójában a titkosított munkamenetet

A titkosított munkamenet ahhoz a géphez tartozik, amelyik lezárja, és ez a vendég, amikor a kliens a VM-en belül fut. Csak a vendég virtuális adapterébe belépő forgalom halad át ezen az alagúton, és a hipervizor soha nem irányít magától más gépet a vendégen keresztül. Ezért tud a vendég működő alagutat tartani, miközben a gazdagép nyílt hálózaton böngészik. A fordított irány nem szimmetrikus, és éppen ez az aszimmetria az a rész, amit a legtöbb útmutató elront.

Hogy melyik címet látja a külső hálózat, arra az adapter módja ad választ. Ha ez eldőlt, a lefedettség megszűnik szakpolitikai kérdés lenni, és mechanikussá válik. Az alábbiak mindebből a két tényből következnek.

A NAT addig írja át a vendéget, amíg az a gazdagépre nem hasonlít

NAT esetén a hipervizor minden vendégcsomagot a gazdagép címére ír át, mielőtt az elérné az első kapcsolót. Ez a forgalom ezután a gazdagép saját hálózati vereméhez kerül, ahol annak útválasztási tábláját követi, beleértve a gazdagépen futó alagút által birtokolt alapértelmezett útvonalat. A NAT-vendéget tehát mindenféle konfiguráció nélkül lefedi egy gazdagépen futó alagút, ami éppen ellentétes azzal, amit a vendégtől a gazdagép felé eset sugall.

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

A saját klienst futtató vendég a vendégen belül zárja le azt az alagutat, a titkosított forgalom pedig ugyanazon az átíráson keresztül lép ki, így a gazdagép alkalmazásai megtartják a saját útvonalukat és a saját kilépési címüket. A VirtualBox ebben a módban a névfeloldást is birtokolja, és a vendég lekérdezéseit a saját motorján keresztül továbbítja, hacsak a --natdnshostresolver1 nincs engedélyezve. Ennek engedélyezése a vendég kereséseit a gazdagép feloldójának adja át, ami akkor javítja a feloldást, ha a gazdagép saját nézete helyes, és ugyanúgy átad egy feloldót, amely talán csak egy alagúton belül létezik. A VM-et ki kell kapcsolni a beállítás megváltoztatása előtt, és a beállítás az adapterhez tartozik, nem a vendég szoftveréhez.

A híd saját bérletet és saját kitettséget ad a vendégnek

A híd a vendég kereteit a fizikai szegmensre továbbítja, így a DHCP bérletet ad neki, és a hálózat külön gazdagépként kezeli. Minden hídra kötött vendég független alagutat tarthat a saját alapértelmezett útvonalával, és a gazdagép táblája soha nem változik. Az ár a kitettség: a vendég válaszol a szórásokra, megjelenik a szomszédtáblákban, és a kapcsoló portbiztonsága valamint a vezeték nélküli kliensek elkülönítése alá kerül. A gazdagépen futó alagút sem fedi le ezt az elrendezést, mert a vendég keretei soha nem haladnak át a gazdagép vermén.

Ezt a NAT-esettől való eltérést érdemes nyíltan kimondani ahelyett, hogy utalásként hagynánk. A hídra kötött vendégnek saját kliensre és saját hitelesítő adatokra van szüksége, valahányszor a forgalmának alagutat kell használnia. Ahol a vendégnek láthatatlannak kell maradnia a helyi hálózat számára, ott a NAT vagy egy csak belső, ellenőrzött útválasztású hálózat a jobb terv.

Miért nem lehet a vendég a gazdagép átjárója

A vendég alagútjának kölcsönadása a gazdagépnek egyik nagy hipervizorban sem támogatott kapcsolóval rendelkezik. A gazdagépnek nincs útvonala a vendég alagútjába, és nincs rá mutató fordítási szabálya, így a vendég és a gazdagép forgalma külön tulajdonosú, külön folyam marad. Ez az irány az adapter módjától függetlenül meghiúsul.

A működő helyettesítők a továbbítások és a proxyk. Az SSH helyi továbbítás engedi, hogy a gazdagép a saját loopbackjéhez csatlakozzon, miközben a vendég viszi az adatfolyamot az alagútba, ami lefedi a TCP-szolgáltatásokat második kliens telepítése nélkül. A gazdagép saját IP-forgalmával inkább a vendég alagútját használtatni útválasztót kíván a vendégen belül, valamint kifejezett útvonalat a gazdagépen és fordítást a gazdagépen. Ez kis hálózattervezés, nem egy jelölőnégyzet, és tervet kíván a visszaútra. Ha a vendég csak a kliens futtatásáért létezik, tedd a klienst a gazdagépre, és töröld a fölösleges ugrást.

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

A feloldók és az útvonalak nem lépik át a határt

A DNS követi azt az adaptert, amely az opciót kapta, így a vendég nem örökli a gazdagép alagút-feloldóját, és a gazdagép soha nem tudja meg a vendégnek küldött kiszolgálót. A küldött dhcp-option DNS értékek arra az interfészre érvényesek, amely elfogadta őket, ezért a kliens nélküli hídra kötött vendég nem tudja feloldani a belső neveket. A NAT-vendég általában inkább a hipervizor DNS-kezelését használja, és a különbség környezetenként egyetlen parancsban látszik.

# 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

Olvasd ki a feloldót és az útvonalat a vendégen belül, mielőtt feltételezed, hogy valamelyik követi a gazdagépet. Add az alagút feloldóját a vendég saját adapteréhez, amikor a belső neveket ott kell feloldani, majd ellenőrizd egy olyan névvel, amely csak az alagút mögött létezik. Jegyezd fel minden VM-nél az adapter módját, az alagút tulajdonosát és a feloldó forrását, mert ez a három tény szinte minden későbbi kérdésre válaszol. Más hipervizorok átnevezik a módokat, és érintetlenül hagyják az elvet.