El DNS del invitado de VirtualBox NAT se rompe cuando el host se une a una VPN

En un host Windows el nombre interno de la aplicación se resuelve en cuanto se conecta la VPN, y dentro de un invitado Ubuntu no. El invitado conserva su propia configuración de resolutor, y el adaptador NAT que tiene delante puede responder a las consultas DNS de dos formas distintas. Apuntar al invitado a un resolutor público hace que los sitios vuelvan a cargarse mientras los nombres privados siguen rotos. Por eso se traza la ruta del resolutor antes de tocar nada.

Rastree una consulta a través del adaptador NAT

Elija un nombre interno totalmente cualificado y un nombre público como control. Con el túnel levantado, confirme en el host que el nombre interno se resuelve y que la aplicación que hay detrás se abre. Después ejecute las mismas dos consultas dentro del invitado y compare las respuestas, no las herramientas.

Confirme que el adaptador es realmente NAT simple antes de seguir. Un adaptador puente, una red NAT con nombre y un segundo cliente VPN dentro del invitado tienen cada uno su propia configuración y su propia explicación. Adivinar en este punto desperdicia el resto de la investigación.

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

El primer comando muestra el modo del adaptador y cualquier red NAT conectada a él. Dentro de un invitado Ubuntu, el segundo enumera la configuración DNS por enlace, y el tercero a menudo solo revela una dirección stub local, lo que significa que el upstream real está en otro sitio.

Mantenga la resolución y la accesibilidad por separado. Un invitado que recibe la dirección correcta pero no puede abrir una conexión tiene un problema de enrutamiento, filtrado o permisos del servicio, y los cambios adicionales de DNS nunca lo tocarán. Pruebe la dirección por separado y anote cuál de las dos falló.

El modo proxy y el modo de resolutor del host son mecanismos distintos

En modo proxy el motor NAT reenvía las consultas del invitado a servidores DNS que ya conoce. En modo de resolutor del host intercepta la consulta y pide al sistema operativo del host que resuelva el nombre con lo que el host está usando ahora mismo. Solo el segundo sigue a un cliente VPN que reescribe la resolución del host cuando se levanta el túnel. Por eso los dos ajustes producen respuestas distintas en la misma máquina.

Esa distinción es todo el problema en una frase. Dar al invitado una lista de direcciones de servidor no es lo mismo que pedir a Windows que resuelva un nombre a través de su resolutor configurado, y en una VPN con DNS dividido las dos respuestas difieren. La opción del adaptador trata del mecanismo, no del permiso.

Ninguno de los dos modos concede acceso a nada. La autorización vive en la política de VPN y en el servicio, y una consulta que funciona solo significa que un nombre se convirtió en una dirección.

Cambie el adaptador y luego verifique qué recibe el invitado

Anote primero la configuración de red y DNS de la VM, y luego apague la máquina para que lo que edite sea la configuración persistente. Para una VM llamada work-ubuntu cuyo primer adaptador lleva NAT, la opción por adaptador se define desde el host con la VM apagada. Vuelva a encenderla después e inspeccione el resultado en lugar de confiar en el código de salida.

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

El dígito final selecciona el número de adaptador, así que no es un valor universal; un ajuste para el adaptador 2 llevaría un 2 en esa posición. Use el binario VBoxManage que corresponde a la versión instalada de VirtualBox, porque uno más antiguo en la ruta puede escribir ajustes que la versión en ejecución ignora.

Activar en cambio la opción proxy elige otro mecanismo y no le da el comportamiento de resolutor del host. Una vez que arranca el invitado, compruebe la configuración DNS que realmente tiene, ya que un resolutor fijado o un ajuste de DNS cifrado dentro del invitado mantiene las aplicaciones en otra ruta independientemente de lo que ofrezca el adaptador.

Pruebe durante todo el ciclo de vida de la VPN, no solo una vez

Repita ambas consultas en el invitado, luego abra la aplicación real y deje que valide el nombre de host TLS. Una prueba de conexión solo por IP aísla bien el DNS, pero no es una comprobación de certificado y no debería presentarse como tal. Anote el nombre, la dirección y el resultado de la aplicación juntos.

Durante una ventana aprobada, desconecte y vuelva a conectar la VPN del host y repita la prueba. El resultado debería coincidir con la política de acceso, y que la resolución pública vuelva a funcionar no dice nada sobre si las consultas privadas se quedaron en la ruta prevista.

Cuando el modo de resolutor del host no cambia nada, devuelva el valor registrado y conserve las observaciones. Un cliente VPN que excluye el tráfico del hipervisor, un resolutor interno inalcanzable y un ajuste de invitado fijado necesitan cada uno una corrección distinta, y puentear el adaptador cambia el diseño de la red en lugar de reiniciar el DNS.