VirtualBox NAT ou bridge: onde remata a VPN da máquina virtual

Dúas preguntas distintas chegan xuntas sempre que unha máquina virtual executa un cliente VPN, e teñen respostas diferentes. A primeira é se un túnel dentro do convidado protexe o anfitrión, e a segunda é se un túnel no anfitrión cobre o convidado. O modo de adaptador decide ambas, máis que o propio software VPN. Un adaptador NAT converte o anfitrión no extremo visible, mentres que un adaptador ponte sitúa o convidado na rede co seu propio enderezo.

Quen remata realmente a sesión cifrada

Unha sesión cifrada pertence á máquina que a remata, e esa é o convidado cando o cliente se executa dentro da VM. Só o tráfico que entra no adaptador virtual do convidado pasa por ese túnel, e o hipervisor nunca encamiña outra máquina a través do convidado pola súa conta. Por iso o convidado pode manter un túnel funcionando mentres o anfitrión navega en claro. O contrario non é simétrico, e esa asimetría é a parte que a maioría das guías erra.

Que enderezo ve a rede exterior é a pregunta que responde o modo de adaptador. Unha vez resolta, a cobertura deixa de ser unha cuestión de política e vólvese mecánica. Todo o que segue derívase deses dous feitos.

NAT reescribe o convidado ata que parece o anfitrión

Con NAT, o hipervisor reescribe cada paquete do convidado ao enderezo do anfitrión antes de que chegue ao primeiro conmutador. Ese tráfico entrégase despois á pila de rede do propio anfitrión, onde segue a súa táboa de rutas, incluída unha ruta por defecto propiedade dun túnel no anfitrión. Un convidado NAT queda polo tanto cuberto por un túnel do anfitrión sen ningunha configuración, que é o contrario do que suxire o caso de convidado a anfitrión.

# 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 convidado que executa o seu propio cliente remata ese túnel dentro do convidado, e o tráfico cifrado sae despois pola mesma reescritura, de modo que as aplicacións do anfitrión conservan o seu propio camiño e o seu propio enderezo de saída. VirtualBox tamén controla a resolución de nomes neste modo e retransmite as consultas do convidado polo seu propio motor agás que --natdnshostresolver1 estea activado. Activalo entrega as buscas do convidado ao resolutor do anfitrión, o que corrixe a resolución cando a visión propia do anfitrión é correcta e igualmente entrega un resolutor que pode existir só dentro dun túnel. A VM debe estar apagada antes de cambiar o axuste, e o axuste pertence ao adaptador e non ao software do convidado.

A ponte dálle ao convidado o seu propio arrendamento e a súa propia exposición

A ponte pasa as tramas do convidado ao segmento físico, así que DHCP lle dá un arrendamento e a rede trátao como un anfitrión separado. Cada convidado con ponte pode manter un túnel independente coa súa propia ruta por defecto, e a táboa do anfitrión nunca cambia. O prezo é a exposición: o convidado responde ás difusións, aparece nas táboas de veciños e queda suxeito á seguridade de portos do conmutador e ao illamento de clientes sen fíos. Un túnel no anfitrión tampouco cobre esta disposición, porque as tramas do convidado nunca pasan pola pila do anfitrión.

Esa diferenza respecto do caso NAT merece dicirse claramente en lugar de deixala como implicación. Un convidado con ponte necesita o seu propio cliente e as súas propias credenciais sempre que o seu tráfico teña que usar un túnel. Onde o convidado debe permanecer invisible para a rede local, NAT ou unha rede só interna con encamiñamento controlado é o mellor deseño.

Por que o convidado non pode ser a porta de enlace do anfitrión

Prestar o túnel dun convidado ao anfitrión non ten ningún conmutador soportado en ningún dos dous hipervisores principais. O anfitrión non ten ruta cara ao túnel do convidado nin regra de tradución que apunte a el, así que o tráfico do convidado e do anfitrión seguen sendo fluxos separados con donos separados. Esa dirección falla independentemente do modo de adaptador.

Os substitutos viables son as redireccións e os proxies. Unha redirección local SSH permite ao anfitrión conectarse ao seu propio loopback mentres o convidado leva o fluxo ao túnel, o que cobre servizos TCP sen instalar un segundo cliente. Facer que o propio tráfico IP do anfitrión use o túnel do convidado no seu lugar require un encamiñador dentro do convidado máis unha ruta explícita no anfitrión e tradución no anfitrión. Iso é un deseño de rede pequeno e non unha caixa de verificación, e necesita un plan para o camiño de volta. Cando o convidado existe só para executar o cliente, pon o cliente no anfitrión e elimina o salto extra.

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

Os resolutores e as rutas non cruzan a fronteira

O DNS segue o adaptador que recibiu a opción, así que un convidado non herda o resolutor do túnel do anfitrión e un anfitrión nunca coñece o servidor empurrado ao convidado. Os valores dhcp-option DNS empurrados aplícanse á interface que os aceptou, e por iso un convidado con ponte sen cliente non pode resolver nomes internos. Un convidado NAT usa normalmente o tratamento de DNS do hipervisor, e a diferenza vese nun comando por contorno.

# 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

Le o resolutor e a ruta dentro do convidado antes de supoñer que algún dos dous segue o anfitrión. Engade o resolutor do túnel ao adaptador propio do convidado cando os nomes internos se deban resolver alí, e despois verifica cun nome que só exista detrás do túnel. Anota o modo de adaptador, o dono do túnel e a fonte do resolutor para cada VM, porque eses tres feitos responden case calquera pregunta posterior. Outros hipervisores renomean os modos e deixan o principio intacto.