El DNS del convidat de VirtualBox NAT es trenca quan l’amfitrió s’uneix a una VPN

En un amfitrió Windows el nom intern de l’aplicació es resol quan la VPN es connecta, i dins d’un convidat Ubuntu no. El convidat conserva la seva pròpia configuració de resolutor, i l’adaptador NAT que té al davant pot respondre les consultes DNS de dues maneres diferents. Apuntar el convidat a un resolutor públic fa que els llocs web tornin a carregar-se mentre els noms privats continuen trencats. Per això es traça el camí del resolutor abans de tocar res.

Traceu una consulta a través de l’adaptador NAT

Trieu un nom intern totalment qualificat i un nom públic com a control. Amb el túnel aixecat, confirmeu a l’amfitrió que el nom intern es resol i que l’aplicació que hi ha darrere s’obre. Després executeu les mateixes dues consultes dins del convidat i compareu les respostes, no les eines.

Confirmeu que l’adaptador és realment NAT simple abans d’anar més enllà. Un adaptador pont, una xarxa NAT amb nom i un segon client VPN dins del convidat tenen cadascun la seva configuració i la seva explicació. Endevinar en aquest punt malbarata la resta de la investigació.

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

La primera ordre mostra el mode de l’adaptador i qualsevol xarxa NAT que hi estigui connectada. Dins d’un convidat Ubuntu, la segona llista la configuració DNS per enllaç, i la tercera sovint només revela una adreça stub local, cosa que vol dir que el vertader upstream és en un altre lloc.

Mantingueu la resolució i l’abastabilitat per separat. Un convidat que rep l’adreça correcta però no pot obrir una connexió té un problema d’encaminament, filtratge o permisos del servei, i els canvis addicionals de DNS no hi tocaran mai. Proveu l’adreça per separat i anoteu quina de les dues ha fallat.

El mode proxy i el mode de resolutor de l’amfitrió són mecanismes diferents

En mode proxy el motor NAT reenvia les consultes del convidat a servidors DNS que ja coneix. En mode de resolutor de l’amfitrió intercepta la consulta i demana al sistema operatiu de l’amfitrió que resolgui el nom amb el que l’amfitrió fa servir ara mateix. Només el segon segueix un client VPN que reescriu la resolució de l’amfitrió quan s’aixeca el túnel. Per això els dos ajustos produeixen respostes diferents a la mateixa màquina.

Aquesta distinció és tot el problema en una frase. Donar al convidat una llista d’adreces de servidor no és el mateix que demanar a Windows que resolgui un nom a través del seu resolutor configurat, i en una VPN amb DNS dividit les dues respostes difereixen. L’opció de l’adaptador tracta del mecanisme, no del permís.

Cap dels dos modes no concedeix accés a res. L’autorització viu a la política de VPN i al servei, i una consulta que funciona només vol dir que un nom s’ha convertit en una adreça.

Canvieu l’adaptador i després verifiqueu què rep el convidat

Anoteu primer la configuració de xarxa i DNS de la VM, i després atureu la màquina perquè el que editeu sigui la configuració persistent. Per a una VM anomenada work-ubuntu el primer adaptador de la qual porta NAT, l’opció per adaptador es defineix des de l’amfitrió amb la VM aturada. Engegueu-la de nou després i inspecteu el resultat en lloc de confiar en el codi de sortida.

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

El dígit final selecciona el número d’adaptador, així que no és un valor universal; un ajust per a l’adaptador 2 portaria un 2 en aquesta posició. Feu servir el binari VBoxManage que correspon a la versió instal·lada de VirtualBox, perquè un de més antic al PATH pot escriure ajustos que la versió en execució ignora.

Activar l’opció proxy en lloc d’això tria un mecanisme diferent i no us dona el comportament de resolutor de l’amfitrió. Un cop el convidat arrenca, comproveu la configuració DNS que realment té, ja que un resolutor fixat o un ajust de DNS xifrat dins del convidat manté les aplicacions en un altre camí independentment del que ofereixi l’adaptador.

Proveu durant tot el cicle de vida de la VPN, no només una vegada

Repetiu les dues consultes al convidat, després obriu l’aplicació real i deixeu que validi el nom d’amfitrió TLS. Una prova de connexió només per IP aïlla bé el DNS, però no és una comprovació de certificat i no s’ha de presentar com a tal. Anoteu el nom, l’adreça i el resultat de l’aplicació junts.

Durant una finestra aprovada, desconnecteu i torneu a connectar la VPN de l’amfitrió i repetiu la prova. El resultat hauria de coincidir amb la política d’accés, i que la resolució pública torni a funcionar no diu res sobre si les consultes privades s’han quedat al camí previst.

Quan el mode de resolutor de l’amfitrió no canvia res, torneu el valor enregistrat i conserveu les observacions. Un client VPN que exclou el trànsit de l’hipervisor, un resolutor intern inabastable i un ajust de convidat fixat necessiten cadascun una correcció diferent, i pontar l’adaptador canvia el disseny de la xarxa en lloc de reiniciar el DNS.