O DNS do convidado do VirtualBox NAT quebra quando o host entra numa VPN

Num host Windows o nome interno da aplicação é resolvido assim que a VPN liga, mas dentro de um convidado Ubuntu não. O convidado mantém as suas próprias definições de resolvedor, e o adaptador NAT à frente pode responder a consultas DNS de duas formas diferentes. Apontar o convidado para um resolvedor público faz os sites carregarem outra vez, mas os nomes privados continuam quebrados. Por isso o caminho do resolvedor é seguido antes de algo ser editado.

Siga uma consulta através do adaptador NAT

Escolha um nome interno totalmente qualificado e um nome público como controlo. Com o túnel ativo, confirme no host que o nome interno é resolvido e que a aplicação por trás abre. Depois execute as mesmas duas consultas dentro do convidado e compare as respostas, não as ferramentas.

Confirme que o adaptador é realmente NAT simples antes de avançar. Um adaptador em ponte, uma rede NAT com nome e um segundo cliente VPN dentro do convidado têm cada um a sua configuração e a sua explicação. Adivinhar neste ponto desperdiça o resto da investigação.

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

O primeiro comando mostra o modo do adaptador e qualquer rede NAT associada. Dentro de um convidado Ubuntu o segundo lista as definições de DNS por ligação, e o terceiro revela muitas vezes apenas um endereço stub local, o que significa que o upstream real está noutro lugar.

Mantenha resolução e acessibilidade separadas. Um convidado que recebe o endereço correto mas não consegue abrir uma ligação tem um problema de encaminhamento, filtragem ou permissões do serviço, e alterações adicionais de DNS nunca o tocarão. Teste o endereço em separado e anote qual dos dois falhou.

O modo proxy e o modo de resolvedor do host são mecanismos diferentes

No modo proxy o motor NAT reencaminha as consultas do convidado para servidores DNS que já conhece. No modo de resolvedor do host interceta a consulta e pede ao sistema operativo do host que resolva o nome com aquilo que o host está a usar neste momento. Só o segundo segue um cliente VPN que reescreve a resolução do host quando o túnel sobe. Por isso as duas definições produzem respostas diferentes na mesma máquina.

Essa distinção é todo o problema numa frase. Dar ao convidado uma lista de endereços de servidor não é o mesmo que pedir ao Windows que resolva um nome através do seu resolvedor configurado, e numa VPN com DNS dividido as duas respostas diferem. A opção do adaptador diz respeito ao mecanismo, não à permissão.

Nenhum dos modos concede acesso a nada. A autorização vive na política de VPN e no serviço, e uma consulta que funciona significa apenas que um nome se tornou num endereço.

Mude o adaptador e depois verifique o que o convidado recebe

Anote primeiro as definições de rede e DNS da VM e depois desligue a máquina, para que edite a configuração persistente. Para uma VM chamada work-ubuntu cujo primeiro adaptador tem NAT, a opção por adaptador é definida a partir do host com a VM desligada. Volte a ligá-la depois e inspecione o resultado em vez de confiar no código de saída.

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

O dígito final seleciona o número do adaptador, por isso não é um valor universal; uma definição para o adaptador 2 levaria um 2 nessa posição. Use o binário VBoxManage que pertence à versão instalada do VirtualBox, porque um mais antigo no caminho pode escrever definições que a versão em execução ignora.

Ativar antes a opção proxy escolhe outro mecanismo e não lhe dá o comportamento de resolvedor do host. Depois de o convidado arrancar, verifique a configuração de DNS que ele realmente tem, pois um resolvedor fixado ou uma definição de DNS encriptado dentro do convidado mantém as aplicações noutro caminho, independentemente do que o adaptador oferece.

Teste ao longo de todo o ciclo de vida da VPN, não apenas uma vez

Repita as duas consultas no convidado, depois abra a aplicação real e deixe-a validar o nome de anfitrião TLS. Um teste de ligação apenas por IP isola bem o DNS, mas não é uma verificação de certificado e não deve ser apresentado como tal. Anote o nome, o endereço e o resultado da aplicação em conjunto.

Durante uma janela aprovada, desligue e volte a ligar a VPN do host e repita o teste. O resultado deve corresponder à política de acesso, e o facto de a resolução pública voltar a funcionar não diz nada sobre se as consultas privadas ficaram no caminho previsto.

Quando o modo de resolvedor do host não muda nada, reponha o valor registado e guarde as observações. Um cliente VPN que exclui o tráfego do hipervisor, um resolvedor interno inalcançável e uma definição de convidado fixada exigem cada um uma correção diferente, e pôr o adaptador em ponte altera o desenho da rede em vez de reiniciar o DNS.