VirtualBox NAT o bridge: on acaba la VPN de la màquina virtual

Dues preguntes diferents arriben juntes sempre que una màquina virtual executa un client VPN, i tenen respostes diferents. La primera és si un túnel dins de l'invitat protegeix l'amfitrió, i la segona és si un túnel a l'amfitrió cobreix l'invitat. El mode d'adaptador decideix les dues coses, més que el programari VPN. Un adaptador NAT fa de l'amfitrió el punt final visible, mentre que un adaptador bridge posa l'invitat a la xarxa amb la seva pròpia adreça.

Qui acaba realment la sessió xifrada

Una sessió xifrada pertany a la màquina que la tanca, que és l'invitat quan el client s'executa dins de la VM. Només el trànsit que entra a l'adaptador virtual de l'invitat passa per aquest túnel, i l'hipervisor no encamina mai una altra màquina a través de l'invitat pel seu compte. Per això l'invitat pot mantenir un túnel funcionant mentre l'amfitrió navega en clar. El contrari no és simètric, i aquesta asimetria és la part que la majoria de guies encerten malament.

Quina adreça veu la xarxa exterior és la pregunta que respon el mode d'adaptador. Un cop això està resolt, la cobertura deixa de ser una qüestió de política i es torna mecànica. Tot el que segueix es deriva d'aquests dos fets.

El NAT reescriu l'invitat fins que sembla l'amfitrió

Amb NAT, l'hipervisor reescriu cada paquet de l'invitat a l'adreça de l'amfitrió abans que arribi al primer commutador. Aquest trànsit es lliura després a la pila de xarxa de l'amfitrió, on segueix la seva taula d'encaminament, inclosa una ruta per defecte propietat d'un túnel a l'amfitrió. Un invitat amb NAT queda, per tant, cobert per un túnel de l'amfitrió sense cap configuració, que és el contrari del que suggereix el cas d'invitat a amfitrió.

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

Un invitat que executa el seu propi client tanca aquest túnel dins de l'invitat, i el trànsit xifrat surt després per la mateixa reescriptura, així que les aplicacions de l'amfitrió conserven el seu camí i la seva adreça de sortida. VirtualBox també controla la resolució de noms en aquest mode i retransmet les consultes de l'invitat pel seu propi motor tret que --natdnshostresolver1 estigui activat. Activar-lo lliura les cerques de l'invitat al resolutor de l'amfitrió, cosa que corregeix la resolució quan la visió pròpia de l'amfitrió és correcta i igualment lliura un resolutor que pot existir només dins d'un túnel. La VM s'ha d'apagar abans de canviar el paràmetre, i el paràmetre és de l'adaptador, no del programari de l'invitat.

El bridge dona a l'invitat el seu propi arrendament i la seva pròpia exposició

El bridge passa les trames de l'invitat al segment físic, així que DHCP li dona un arrendament i la xarxa el tracta com un amfitrió separat. Cada invitat amb bridge pot mantenir un túnel independent amb la seva pròpia ruta per defecte, i la taula de l'amfitrió no canvia mai. El preu és l'exposició: l'invitat respon a les difusions, apareix a les taules de veïns i queda subjecte a la seguretat de ports del commutador i a l'aïllament de clients sense fil. Un túnel a l'amfitrió tampoc no cobreix aquesta disposició, perquè les trames de l'invitat no passen mai per la pila de l'amfitrió.

Aquesta diferència respecte del cas NAT val la pena dir-la clarament en lloc de deixar-la com a implicació. Un invitat amb bridge necessita el seu propi client i les seves pròpies credencials sempre que el seu trànsit hagi de fer servir un túnel. On l'invitat ha de quedar invisible a la xarxa local, el NAT o una xarxa només interna amb encaminament controlat és el disseny millor.

Per què l'invitat no pot ser la porta d'enllaç de l'amfitrió

Prestar el túnel d'un invitat a l'amfitrió no té cap commutador suportat en cap dels dos hipervisors principals. L'amfitrió no té cap ruta cap al túnel de l'invitat ni cap regla de traducció que hi apunti, així que el trànsit de l'invitat i el de l'amfitrió segueixen sent fluxos separats amb propietaris separats. Aquesta direcció falla sigui quin sigui el mode d'adaptador.

Els substituts viables són les redireccions i els proxys. Una redirecció local SSH permet a l'amfitrió connectar-se al seu propi loopback mentre l'invitat porta el flux al túnel, cosa que cobreix serveis TCP sense instal·lar un segon client. Fer que el trànsit IP propi de l'amfitrió utilitzi el túnel de l'invitat en lloc d'això requereix un encaminador dins de l'invitat més una ruta explícita a l'amfitrió i traducció a l'amfitrió. Això és un disseny de xarxa petit i no una casella de verificació, i necessita un pla per al camí de tornada. Quan l'invitat existeix només per executar el client, poseu el client a l'amfitrió i elimineu el salt extra.

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

Els resolutors i les rutes no travessen la frontera

El DNS segueix l'adaptador que ha rebut l'opció, així que un invitat no hereta el resolutor del túnel de l'amfitrió i un amfitrió no coneix mai el servidor empès a l'invitat. Els valors dhcp-option DNS empesos s'apliquen a la interfície que els ha acceptat, i per això un invitat amb bridge sense client no pot resoldre noms interns. Un invitat amb NAT normalment fa servir la gestió de DNS de l'hipervisor, i la diferència es veu en una comanda per entorn.

# 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

Llegiu el resolutor i la ruta dins de l'invitat abans de suposar que algun dels dos segueix l'amfitrió. Afegiu el resolutor del túnel a l'adaptador propi de l'invitat quan els noms interns s'hi hagin de resoldre, i després verifiqueu-ho amb un nom que només existeixi darrere del túnel. Anoteu el mode d'adaptador, el propietari del túnel i la font del resolutor per a cada VM, perquè aquests tres fets responen gairebé a tota pregunta posterior. Els altres hipervisors canvien el nom dels modes i deixen el principi intacte.