O DNS do convidado de VirtualBox rompe cando o anfitrión se une a unha VPN

Unha aplicación interna resólvese no anfitrión Windows no momento en que a VPN se conecta, e o convidado Ubuntu detrás do NAT de VirtualBox segue sen atopala. O convidado ten o seu propio resolvedor, e o adaptador NAT pode xestionar o DNS de máis dunha forma. Substituír o resolvedor do convidado por un servidor público fai que os sitios web correntes funcionen e que os nomes privados fallen, o que desvía o problema en lugar de resolvelo. Faga as catro comprobacións en orde e detéñase na primeira que non se cumpra.

Confirme que modo de adaptador está depurando

Só un adaptador en modo NAT simple se comporta como describe este artigo. Un adaptador ponte sitúase na rede física con identidade propia, unha rede NAT é un conmutador virtual con nome e axustes propios de DHCP e DNS, e un cliente VPN dentro do convidado engade un segundo resolvedor enteiro. Confirme o modo antes de seguir lendo, porque a reparación é distinta en cada un deses casos.

Unha máquina virtual pode levar dous adaptadores en modos diferentes, e o afectado non sempre é o primeiro.

Confirme tamén que o anfitrión resolve o nome. Abra a mesma aplicación no anfitrión co túnel levantado, usando o mesmo nome totalmente cualificado que usará o convidado. Se o anfitrión tamén falla, o convidado non ten a culpa e ningún cambio de rede virtual o arranxará.

Siga un nome a través do resolvedor do convidado

Escolla un nome interno e un nome público de control, e probe ambos nos dous sitios. Un nome público que se resolve mentres o privado non o fai localiza o fallo na ruta privada e non na resolución de nomes en xeral. Probar só o nome privado déixalle incapaz de distinguir un resolvedor roto dunha ruta rota.

Dentro do convidado, mire para que está configurado realmente o resolvedor. Nun convidado Ubuntu con systemd-resolved, o estado por ligazón mostra os servidores que chegaron, e o ficheiro resolv.conf pode conter só un enderezo stub, o cal é correcto e non sospeitoso. Un ficheiro editado a man ou un cliente de DNS cifrado aparte poden enviar as consultas a outro sitio por completo. Anote o que atope antes de cambialo.

resolvectl status
resolvectl query app.internal.example

Separe aquí a resolución da accesibilidade. Un enderezo que chega mentres o servizo segue inaccesible é unha cuestión de encamiñamento ou de política, non de DNS.

Probe o modo resolvedor do anfitrión nese adaptador

As opcións de DNS de NAT de VirtualBox describen mecanismos distintos, e a diferenza importa cando o resolvedor propio do anfitrión cambia co túnel. O proxy DNS reenvía as peticións do convidado a servidores que se lle deron. O modo resolvedor do anfitrión intercepta as peticións e chama a API de DNS do anfitrión, que é o modo que segue un resolvedor de Windows reconfigurado por un cliente VPN.

Active o mecanismo equivocado e o comando seguirá tendo éxito mentres o comportamento non cambia, o que é unha maneira confusa de perder unha tarde.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Anote os axustes actuais da máquina virtual, apáguea e apunte ao adaptador que confirmou antes. O díxito final da opción é un número de adaptador e non unha constante, así que aplicalo a unha máquina cuxo adaptador afectado é o segundo é unha operación silenciosa sen efecto. Arranque o convidado e comprobe a configuración de resolvedor que recibiu realmente, porque un axuste manual no convidado anula todo o que ofrece a capa NAT. Lembre que o modo resolvedor do anfitrión tamén supón que a ruta DNS propia do anfitrión é a que quería compartir.

Repita as mesmas probas a través dunha reconexión da VPN

Repita ambas consultas no convidado, logo abra a aplicación real e deixe que valide o certificado ela mesma. Unha proba só de enderezo é útil para illar a resolución de nomes e non equivale a unha sesión TLS funcional, así que non se deteña nun ping. Despois, nunha xanela aprobada, desconecte e volva conectar o túnel do anfitrión e repita unha vez máis. Un comportamento que só se mantén na primeira conexión tras o arranque é un problema de ciclo de vida que hai que informar, non un misterio de DNS que perseguir con outro resolvedor.

Que a resolución pública funcione non demostra que as consultas privadas quedasen na ruta que esixe a súa política.

Cando o modo resolvedor do anfitrión non cambia nada, devolva a configuración anotada e conserve as catro observacións: que devolveu o anfitrión, que devolveu o convidado, o modo do adaptador e o estado do resolvedor. Un servidor interno inaccesible, un filtro que exclúe o tráfico do hipervisor e unha anulación no lado do convidado necesitan cada un unha corrección distinta. Converter o adaptador nunha ponte cambia o deseño da rede e non é un reinicio do DNS.