VirtualBox NAT ou bridge: onde termina a VPN da VM

Duas perguntas diferentes chegam juntas sempre que uma máquina virtual executa um cliente VPN, e têm respostas diferentes. A primeira é se um túnel dentro do hóspede protege o anfitrião, e a segunda é se um túnel no anfitrião cobre o hóspede. O modo do adaptador decide ambas, mais do que o próprio software VPN. Um adaptador NAT torna o anfitrião o ponto final visível, enquanto um adaptador bridge coloca o hóspede na rede com o seu próprio endereço.

Quem termina realmente a sessão cifrada

Uma sessão cifrada pertence à máquina que a termina, e é o hóspede quando o cliente corre dentro da VM. Só o tráfego que entra no adaptador virtual do hóspede passa por esse túnel, e o hipervisor nunca encaminha outra máquina através do hóspede por sua iniciativa. É por isso que o hóspede pode manter um túnel a funcionar enquanto o anfitrião navega em claro. O inverso não é simétrico, e essa assimetria é a parte que a maioria dos guias erra.

Que endereço a rede exterior vê é a pergunta a que o modo do adaptador responde. Uma vez resolvido isso, a cobertura deixa de ser uma questão de política e torna-se mecânica. Tudo o que segue decorre desses dois factos.

O NAT reescreve o hóspede até ele parecer o anfitrião

Com NAT, o hipervisor reescreve cada pacote do hóspede para o endereço do anfitrião antes de chegar ao primeiro comutador. Esse tráfego é depois entregue à pilha de rede do próprio anfitrião, onde segue a sua tabela de rotas, incluindo uma rota predefinida pertencente a um túnel no anfitrião. Um hóspede NAT fica, portanto, coberto por um túnel do anfitrião sem qualquer configuração, o que é o contrário do que sugere o caso de hóspede para anfitrião.

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

Um hóspede que executa o seu próprio cliente termina esse túnel dentro do hóspede, e o tráfego cifrado sai depois pela mesma reescrita, pelo que as aplicações do anfitrião mantêm o seu caminho e o seu endereço de saída. O VirtualBox também controla a resolução de nomes neste modo e reencaminha as consultas do hóspede pelo seu próprio motor, a menos que --natdnshostresolver1 esteja ativado. Ativá-lo entrega as pesquisas do hóspede ao resolver do anfitrião, o que corrige a resolução quando a visão do anfitrião está certa e igualmente entrega um resolver que pode existir apenas dentro de um túnel. A VM tem de estar desligada antes de mudar a definição, e a definição pertence ao adaptador e não ao software do hóspede.

A bridge dá ao hóspede a sua própria concessão e a sua própria exposição

A bridge passa as tramas do hóspede para o segmento físico, por isso o DHCP dá-lhe uma concessão e a rede trata-o como um anfitrião separado. Cada hóspede ligado em bridge pode manter um túnel independente com a sua própria rota predefinida, e a tabela do anfitrião nunca muda. O preço é a exposição: o hóspede responde a difusões, aparece nas tabelas de vizinhos e fica sujeito à segurança de portas do comutador e ao isolamento de clientes sem fios. Um túnel no anfitrião também não cobre esta disposição, porque as tramas do hóspede nunca passam pela pilha do anfitrião.

Essa diferença em relação ao caso NAT merece ser dita claramente em vez de ficar como implicação. Um hóspede ligado em bridge precisa do seu próprio cliente e das suas próprias credenciais sempre que o seu tráfego tiver de usar um túnel. Onde o hóspede tem de permanecer invisível para a rede local, o NAT ou uma rede apenas interna com encaminhamento controlado é o melhor desenho.

Porque o hóspede não pode ser a gateway do anfitrião

Emprestar o túnel de um hóspede ao anfitrião não tem qualquer comutador suportado em nenhum dos dois grandes hipervisores. O anfitrião não tem rota para dentro do túnel do hóspede nem regra de tradução que aponte para lá, pelo que o tráfego do hóspede e do anfitrião continuam fluxos separados com donos separados. Essa direção falha independentemente do modo do adaptador.

Os substitutos viáveis são os reencaminhamentos e os proxies. Um reencaminhamento local SSH permite ao anfitrião ligar-se ao seu próprio loopback enquanto o hóspede leva o fluxo para o túnel, o que cobre serviços TCP sem instalar um segundo cliente. Fazer com que o próprio tráfego IP do anfitrião use o túnel do hóspede em vez disso exige um encaminhador dentro do hóspede, mais uma rota explícita no anfitrião e tradução no anfitrião. Isso é um pequeno desenho de rede e não uma caixa de seleção, e precisa de um plano para o caminho de volta. Quando o hóspede existe apenas para executar o cliente, coloque o cliente no anfitrião e elimine o salto extra.

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

Os resolvers e as rotas não atravessam a fronteira

O DNS segue o adaptador que recebeu a opção, por isso um hóspede não herda o resolver do túnel do anfitrião e um anfitrião nunca fica a conhecer o servidor empurrado para o hóspede. Os valores dhcp-option DNS empurrados aplicam-se à interface que os aceitou, e é por isso que um hóspede em bridge sem cliente não consegue resolver nomes internos. Um hóspede NAT usa normalmente o tratamento de DNS do hipervisor, e a diferença vê-se num único comando por ambiente.

# 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

Leia o resolver e a rota dentro do hóspede antes de assumir que algum deles segue o anfitrião. Acrescente o resolver do túnel ao adaptador próprio do hóspede quando os nomes internos têm de ser resolvidos ali, e depois verifique com um nome que só existe atrás do túnel. Registe o modo do adaptador, o dono do túnel e a origem do resolver para cada VM, porque esses três factos respondem a quase todas as perguntas posteriores. Outros hipervisores mudam o nome dos modos e deixam o princípio intacto.