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

Nun anfitrión Windows o nome interno da aplicación resólvese en canto se conecta a VPN, e dentro dun convidado Ubuntu non. O convidado conserva a súa propia configuración de resolvedor, e o adaptador NAT que ten diante pode responder ás consultas DNS de dúas maneiras diferentes. Apuntar o convidado a un resolvedor público fai que os sitios volvan cargarse mentres os nomes privados seguen rotos. Por iso se traza a ruta do resolvedor antes de tocar nada.

Traza unha consulta a través do adaptador NAT

Escollede un nome interno totalmente cualificado e un nome público como control. Co túnel levantado, confirmade no anfitrión que o nome interno se resolve e que a aplicación que hai detrás se abre. Despois executade as mesmas dúas consultas dentro do convidado e comparade as respostas, non as ferramentas.

Confirmade que o adaptador é realmente NAT simple antes de seguir. Un adaptador ponte, unha rede NAT con nome e un segundo cliente VPN dentro do convidado teñen cada un a súa propia configuración e a súa propia explicación. Adiviñar neste punto malgasta o resto da investigación.

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 calquera rede NAT conectada a el. Dentro dun convidado Ubuntu, o segundo enumera a configuración DNS por ligazón, e o terceiro a miúdo só revela un enderezo stub local, o que significa que o upstream real está noutro sitio.

Mantede a resolución e a accesibilidade por separado. Un convidado que recibe o enderezo correcto pero non pode abrir unha conexión ten un problema de enrutamento, filtrado ou permisos do servizo, e os cambios adicionais de DNS nunca o tocarán. Probade o enderezo por separado e anotade cal das dúas fallou.

O modo proxy e o modo de resolvedor do anfitrión son mecanismos distintos

En modo proxy o motor NAT reenvía as consultas do convidado a servidores DNS que xa coñece. En modo de resolvedor do anfitrión intercepta a consulta e pide ao sistema operativo do anfitrión que resolva o nome co que o anfitrión está a usar agora mesmo. Só o segundo segue un cliente VPN que reescribe a resolución do anfitrión cando se levanta o túnel. Por iso os dous axustes producen respostas distintas na mesma máquina.

Esa distinción é todo o problema nunha frase. Dar ao convidado unha lista de enderezos de servidor non é o mesmo que pedirlle a Windows que resolva un nome a través do seu resolvedor configurado, e nunha VPN con DNS dividido as dúas respostas difiren. A opción do adaptador trata do mecanismo, non do permiso.

Ningún dos dous modos concede acceso a nada. A autorización vive na política de VPN e no servizo, e unha consulta que funciona só significa que un nome se converteu nun enderezo.

Cambiade o adaptador e despois verificade que recibe o convidado

Anotade primeiro a configuración de rede e DNS da VM, e despois apagade a máquina para que o que editedes sexa a configuración persistente. Para unha VM chamada work-ubuntu cuxo primeiro adaptador leva NAT, a opción por adaptador defínese desde o anfitrión coa VM apagada. Encendea de novo despois e inspeccionade o resultado en lugar de confiar no código de saída.

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

O díxito final selecciona o número de adaptador, así que non é un valor universal; un axuste para o adaptador 2 levaría un 2 nesa posición. Usade o binario VBoxManage que corresponde á versión instalada de VirtualBox, porque un máis antigo na ruta pode escribir axustes que a versión en execución ignora.

Activar no seu lugar a opción proxy escolle outro mecanismo e non vos dá o comportamento de resolvedor do anfitrión. Unha vez que arrinca o convidado, comprobade a configuración DNS que realmente ten, xa que un resolvedor fixado ou un axuste de DNS cifrado dentro do convidado mantén as aplicacións noutra ruta independentemente do que ofreza o adaptador.

Probade durante todo o ciclo de vida da VPN, non só unha vez

Repetide as dúas consultas no convidado, despois abride a aplicación real e deixade que valide o nome de anfitrión TLS. Unha proba de conexión só por IP illa ben o DNS, pero non é unha comprobación de certificado e non debería presentarse como tal. Anotade o nome, o enderezo e o resultado da aplicación xuntos.

Durante unha xanela aprobada, desconectade e volvede conectar a VPN do anfitrión e repetide a proba. O resultado debería coincidir coa política de acceso, e que a resolución pública volva funcionar non di nada sobre se as consultas privadas quedaron na ruta prevista.

Cando o modo de resolvedor do anfitrión non cambia nada, devolvédelle o valor rexistrado e conservade as observacións. Un cliente VPN que exclúe o tráfico do hipervisor, un resolvedor interno inalcanzable e un axuste de convidado fixado necesitan cada un unha corrección distinta, e pór o adaptador en ponte cambia o deseño da rede en lugar de reiniciar o DNS.