El DNS del invitado de VirtualBox se rompe cuando el anfitrión se une a una VPN

Una aplicación interna se resuelve en el anfitrión Windows en el momento en que la VPN se conecta, y el invitado Ubuntu tras el NAT de VirtualBox sigue sin encontrarla. El invitado tiene su propio resolutor, y el adaptador NAT puede gestionar el DNS de más de una forma. Sustituir el resolutor del invitado por un servidor público hace que los sitios web corrientes funcionen y que los nombres privados fallen, lo que desvía el problema en lugar de resolverlo. Haga las cuatro comprobaciones en orden y deténgase en la primera que no se cumpla.

Confirme qué modo de adaptador está depurando

Solo un adaptador en modo NAT simple se comporta como describe este artículo. Un adaptador puente se sitúa en la red física con identidad propia, una red NAT es un conmutador virtual con nombre y ajustes propios de DHCP y DNS, y un cliente VPN dentro del invitado añade un segundo resolutor entero. Confirme el modo antes de seguir leyendo, porque la reparación es distinta en cada uno de esos casos.

Una máquina virtual puede llevar dos adaptadores en modos diferentes, y el afectado no siempre es el primero.

Confirme también que el anfitrión resuelve el nombre. Abra la misma aplicación en el anfitrión con el túnel levantado, usando el mismo nombre totalmente cualificado que usará el invitado. Si el anfitrión también falla, el invitado no tiene la culpa y ningún cambio de red virtual lo arreglará.

Siga un nombre a través del resolutor del invitado

Elija un nombre interno y un nombre público de control, y pruebe ambos en ambos sitios. Un nombre público que se resuelve mientras el privado no lo hace localiza el fallo en la ruta privada y no en la resolución de nombres en general. Probar solo el nombre privado le deja incapaz de distinguir un resolutor roto de una ruta rota.

Dentro del invitado, mire para qué está configurado realmente el resolutor. En un invitado Ubuntu con systemd-resolved, el estado por enlace muestra los servidores que han llegado, y el archivo resolv.conf puede contener solo una dirección stub, lo cual es correcto y no sospechoso. Un archivo editado a mano o un cliente de DNS cifrado aparte pueden enviar las consultas a otro sitio por completo. Anote lo que encuentre antes de cambiarlo.

resolvectl status
resolvectl query app.internal.example

Separe aquí la resolución de la accesibilidad. Una dirección que llega mientras el servicio sigue inaccesible es una cuestión de enrutamiento o de política, no de DNS.

Pruebe el modo de resolutor del anfitrión en ese adaptador

Las opciones de DNS de NAT de VirtualBox describen mecanismos distintos, y la diferencia importa cuando el resolutor propio del anfitrión cambia con el túnel. El proxy DNS reenvía las peticiones del invitado a servidores que se le han entregado. El modo de resolutor del anfitrión intercepta las peticiones y llama a la API de DNS del anfitrión, que es el modo que sigue a un resolutor de Windows reconfigurado por un cliente VPN.

Active el mecanismo equivocado y el comando seguirá teniendo éxito mientras el comportamiento no cambia, lo que es una manera confusa de perder una tarde.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Anote los ajustes actuales de la máquina virtual, apáguela y apunte al adaptador que confirmó antes. El dígito final de la opción es un número de adaptador y no una constante, así que aplicarlo a una máquina cuyo adaptador afectado es el segundo es una operación silenciosa sin efecto. Arranque el invitado y compruebe la configuración de resolutor que recibió realmente, porque un ajuste manual en el invitado anula todo lo que ofrece la capa NAT. Recuerde que el modo de resolutor del anfitrión también supone que la ruta DNS propia del anfitrión es la que quería compartir.

Repita las mismas pruebas a través de una reconexión de la VPN

Repita ambas consultas en el invitado, luego abra la aplicación real y deje que valide el certificado ella misma. Una prueba solo de dirección es útil para aislar la resolución de nombres y no equivale a una sesión TLS funcional, así que no se detenga en un ping. Después, en una ventana aprobada, desconecte y vuelva a conectar el túnel del anfitrión y repita una vez más. Un comportamiento que solo se mantiene en la primera conexión tras el arranque es un problema de ciclo de vida que hay que informar, no un misterio de DNS que perseguir con otro resolutor.

Que la resolución pública funcione no demuestra que las consultas privadas se hayan quedado en la ruta que exige su política.

Cuando el modo de resolutor del anfitrión no cambia nada, devuelva la configuración anotada y conserve las cuatro observaciones: qué devolvió el anfitrión, qué devolvió el invitado, el modo del adaptador y el estado del resolutor. Un servidor interno inaccesible, un filtro que excluye el tráfico del hipervisor y una anulación en el lado del invitado necesitan cada uno una corrección distinta. Convertir el adaptador en un puente cambia el diseño de la red y no es un reinicio del DNS.