Rede de VM em NAT ou bridged: qual delas transporta o tráfego da VPN?

Bridged e NAT não são duas formas de conectar o mesmo convidado à sua VPN; eles decidem quem é dono dos pacotes do convidado antes de qualquer túnel entrar em cena. No modo NAT, o hypervisor reescreve o tráfego do convidado e o emite a partir de código do lado do host, então o convidado segue qualquer rota que o host entregue a esse código. No modo bridged, o convidado ganha sua própria identidade de camada de enlace no segmento físico e escolhe seu próprio gateway padrão, o que torna o túnel do host irrelevante para ele, a menos que o roteador da LAN seja quem faz o tunelamento. Parei de tratar a VM como estando na VPN e passei a tratá-la como uma questão sobre para onde aponta a rota padrão desse convidado. O teste abaixo leva alguns minutos por modo e resolve a questão sem adivinhação.

NAT mantém o convidado atrás do código do hypervisor, onde valem as rotas do host

No VirtualBox, um convidado NAT fica em 10.0.2.0/24 com um gateway virtual em 10.0.2.2, um proxy DNS em 10.0.2.3 e nenhuma rota própria para a rede física. Os pacotes de saída são capturados pelo mecanismo NAT, reescritos para que a origem seja o host e entregues à pilha IP do host. A partir daí, o tráfego do convidado é um fluxo do host, e a consulta de rota é por destino: um cliente de túnel completo que instala 0.0.0.0/1 e 128.0.0.0/1 no host o captura sem nunca saber que existe uma VM. O capítulo de redes do VirtualBox da Oracle lista esses padrões se você quiser confirmar os endereços na sua build.

A rede padrão do libvirt chega ao mesmo lugar a partir de 192.168.122.0/24, onde o dnsmasq distribui concessões e o host faz masquerade da sub-rede, então os pacotes do convidado voltam a chegar à decisão de roteamento do host. A exceção é um cliente que escolhe o tráfego por processo em vez de por rota. Se a lista de tunelamento dividido contém seu navegador e nada mais, o mecanismo NAT não está nessa lista, e o convidado sai da máquina sem túnel enquanto o navegador do host ainda parece coberto. Mesma sub-rede, resultado oposto.

Bridged dá ao convidado seu próprio lugar na LAN física

Um convidado bridged recebe uma NIC virtual ligada a um adaptador real, ganha seu próprio endereço MAC e pega uma concessão DHCP da rede física. Seu gateway padrão é o roteador da LAN, não o hypervisor, e seus quadros vão para o cabo através desse adaptador. As rotas do túnel do host ficam na tabela do host e nunca são consultadas, porque os quadros do convidado nunca entram na pilha IP do host.

Isso corta para os dois lados. A navegação por mDNS e SMB começa a funcionar porque o convidado vê o tráfego de broadcast da LAN, e o convidado passa a ser alcançável de outras máquinas no mesmo segmento sem firewall do host no meio. Bridging também não é forma de empurrar um convidado por um túnel existente: anexar uma VM à interface WireGuard ou OpenVPN do host não é algo que o VirtualBox ou o libvirt faça por você. Se um convidado bridged precisa ser tunelado, o túnel tem de terminar em algum ponto dessa LAN.

O teste que encerra a discussão

Rode as mesmas verificações nos dois modos e anote as respostas:

• No host, curl -s https://ifconfig.me devolve o endereço público v4.
• No convidado, o mesmo comando, mais ip route no Linux ou Get-NetRoute -DestinationPrefix 0.0.0.0/0 no Windows para o gateway padrão.
• Identidade do resolvedor: resolvectl status ou cat /etc/resolv.conf no convidado, para ver se aponta para 10.0.2.3 ou para um servidor da LAN.
• Família de endereços: ip -6 addr show scope global e uma requisição v6, porque um túnel v4 não diz nada sobre um endereço v6 global que o convidado possa ter.

Endereços públicos iguais significam que o convidado está no caminho do host. Um endereço do convidado que coincide com a saída comum da LAN significa que não está. O passo que as pessoas pulam é o controle: derrube o túnel do host e repita a requisição do convidado. Se o convidado continuar navegando, ele nunca dependeu do túnel do host, seja qual for o nome do modo. No modo NAT, o convidado deveria perder a internet com o túnel do host no chão, a menos que o cliente esteja configurado para permitir tráfego sem túnel, o que vale a pena saber por si só.

Dois sinais mentem. Um ping bem-sucedido prova alcançabilidade, não caminho de saída. E o DNS pode ser respondido pelo proxy 10.0.2.3 através do resolvedor do host enquanto o TCP segue outra rota, e é assim que você tem uma página que carrega e um login que nunca completa.

Qual modo serve ao trabalho

O modo é uma decisão de roteamento, então escolha pelo requisito em vez do hábito:

A primeira linha é onde as pessoas se dão mal: NAT mais um cliente de túnel completo no host cobre um convidado, mas só enquanto o cliente tunelar por rota e o uplink do host for esse túnel. Mova o cliente para uma lista de permissões só de navegador e a cobertura desaparece sem nenhum erro em lugar algum. A quarta linha é o erro inverso, um convidado em bridged por conveniência que começa a responder SMB ou SSH na LAN do escritório sem ninguém notar.

Falhas que levam a culpa para a VPN

No Windows, a tradução NAT roda dentro do processo da VM do VirtualBox, então um cliente por aplicativo precisa exatamente dessa imagem na lista, e não de uma regra genérica para máquinas virtuais. Quando uma atualização do cliente reconstrói sua lista de processos permitidos, os convidados NAT perdem a cobertura primeiro, e o relato soa como uma VM que alcança a LAN mas não a internet, enquanto o host está bem.

Bridging para Wi-Fi é o outro clássico. Os pontos de acesso raramente encaminham quadros com um MAC de origem estranho, então uma bridge sobre wlan0 ou falha de vez ou funciona até o isolamento de cliente no AP começar a descartá-la. O VirtualBox ainda vai oferecer o adaptador sem fio na lista. Se o host está no Wi-Fi e o convidado precisa ser bridged, planeje testar em vez de presumir.

O MTU é o terceiro. Um convidado bridged mantém o MTU de 1500 bytes da LAN, e se ele roda seu próprio cliente WireGuard em 1420, handshakes TLS grandes travam enquanto requisições pequenas passam. Sob NAT, o MTU do túnel do host é problema do host, mas o convidado ainda acredita em 1500, e UDP com o bit don't-fragment ligado vira buraco negro do mesmo jeito.

Anote o modo e verifique de novo após qualquer troca de adaptador

Registre o modo, a interface do host que a bridge usa, o gateway padrão do convidado, seu resolvedor e seus endereços de saída v4 e v6. Esse registro é o que torna a próxima falha barata: quando um notebook passa da dock para o Wi-Fi, um convidado bridged segue a bridge para outro adaptador físico e pode renovar a concessão em outra sub-rede, enquanto um convidado NAT mantém seu endereço 10.0.2.x e herda silenciosamente um uplink diferente.

Antes de fechar o chamado, confirme cada um destes pontos:

• O endereço de saída do convidado difere do endereço de saída do host, então ele não está no túnel do host.
• O resolvedor é o proxy 10.0.2.3 ou um servidor da LAN, e você sabe qual deles respondeu.
• Não existe endereço v6 global no convidado se o desenho do túnel é só v4.
• Com o túnel do host derrubado, o convidado para de navegar, ou você agora sabe que ele nunca dependeu dele.
• O convidado não vê tráfego de broadcast da LAN que não tem por que ver.