O DNS do convidado do VirtualBox quebra quando o anfitrião entra numa VPN

Uma aplicação interna resolve-se no anfitrião Windows no momento em que a VPN liga, e o convidado Ubuntu atrás do NAT do VirtualBox continua sem a encontrar. O convidado tem o seu próprio resolvedor, e o adaptador NAT pode tratar o DNS de mais do que uma forma. Substituir o resolvedor do convidado por um servidor público faz os sites comuns funcionar e os nomes privados falhar, o que desloca o problema em vez de o resolver. Faça as quatro verificações por ordem e pare na primeira que não se verificar.

Confirme que modo de adaptador está a depurar

Só um adaptador em modo NAT simples se comporta como este artigo descreve. Um adaptador em ponte fica na rede física com identidade própria, uma rede NAT é um comutador virtual com nome e definições próprias de DHCP e DNS, e um cliente VPN dentro do convidado acrescenta um segundo resolvedor inteiro. Confirme o modo antes de continuar a ler, porque a reparação é diferente em cada um desses casos.

Uma máquina virtual pode ter dois adaptadores em modos diferentes, e o afetado não é sempre o primeiro.

Confirme também que o anfitrião resolve o nome de todo. Abra a mesma aplicação no anfitrião com o túnel ativo, usando o mesmo nome totalmente qualificado que o convidado vai usar. Se o anfitrião também falhar, o convidado não é a causa e nenhuma alteração na rede virtual o vai corrigir.

Siga um nome através do resolvedor do convidado

Escolha um nome interno e um nome público de controlo, e teste os dois nos dois locais. Um nome público que resolve enquanto o privado não resolve localiza a falha no caminho privado e não na resolução de nomes em geral. Testar só o nome privado deixa-o incapaz de distinguir um resolvedor avariado de uma rota avariada.

Dentro do convidado, veja para que está o resolvedor realmente configurado. Num convidado Ubuntu com systemd-resolved, o estado por ligação mostra os servidores que chegaram, e o ficheiro resolv.conf pode conter apenas um endereço stub, o que está correto e não é suspeito. Um ficheiro editado à mão ou um cliente DNS cifrado à parte podem enviar as consultas para outro sítio por completo. Anote o que encontrar antes de alterar.

resolvectl status
resolvectl query app.internal.example

Separe aqui a resolução da acessibilidade. Um endereço que chega enquanto o serviço continua inacessível é uma questão de encaminhamento ou de política, não de DNS.

Experimente o modo de resolvedor do anfitrião nesse adaptador

As opções de DNS do NAT do VirtualBox descrevem mecanismos diferentes, e a diferença importa quando o resolvedor próprio do anfitrião muda com o túnel. O proxy DNS reencaminha os pedidos do convidado para servidores que lhe foram entregues. O modo de resolvedor do anfitrião interceta os pedidos e chama a API de DNS do anfitrião, e é este o modo que segue um resolvedor Windows reconfigurado por um cliente VPN.

Ative o mecanismo errado e o comando continua a ter sucesso enquanto o comportamento não muda, o que é uma forma confusa de perder uma tarde.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Anote as definições atuais da máquina virtual, desligue-a e aponte ao adaptador que confirmou antes. O dígito final da opção é um número de adaptador e não uma constante, por isso aplicá-lo a uma máquina cujo adaptador afetado é o segundo é uma operação silenciosa sem efeito. Arranque o convidado e verifique a configuração de resolvedor que ele recebeu realmente, porque uma definição manual no convidado sobrepõe-se a tudo o que a camada NAT oferece. Lembre-se de que o modo de resolvedor do anfitrião também assume que o caminho DNS próprio do anfitrião é o que queria partilhar.

Repita os mesmos testes ao longo de uma reconexão da VPN

Repita as duas consultas no convidado, depois abra a aplicação real e deixe-a validar o certificado ela mesma. Um teste só de endereço é útil para isolar a resolução de nomes e não equivale a uma sessão TLS funcional, por isso não pare num ping. Depois, numa janela aprovada, desligue e volte a ligar o túnel do anfitrião e repita mais uma vez. Um comportamento que só se mantém na primeira ligação após o arranque é um problema de ciclo de vida a reportar, não um mistério de DNS a perseguir com outro resolvedor.

O facto de a resolução pública funcionar não prova que as consultas privadas ficaram no caminho que a sua política exige.

Quando o modo de resolvedor do anfitrião não muda nada, reponha a configuração anotada e guarde as quatro observações: o que o anfitrião devolveu, o que o convidado devolveu, o modo do adaptador e o estado do resolvedor. Um servidor interno inacessível, um filtro que exclui o tráfego do hipervisor e uma sobreposição do lado do convidado precisam cada um de uma correção diferente. Converter o adaptador numa ponte muda o desenho da rede e não é um reinício do DNS.