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

Una aplicació interna es resol a l'amfitrió Windows en el moment que la VPN es connecta, i el convidat Ubuntu darrere de la NAT de VirtualBox encara no la troba. El convidat té el seu propi resolutor, i l'adaptador NAT pot gestionar el DNS de més d'una manera. Substituir el resolutor del convidat per un servidor públic fa funcionar els llocs web corrents i fallar els noms privats, cosa que desvia el problema en lloc de resoldre'l. Feu les quatre comprovacions en ordre i atureu-vos a la primera que no es compleixi.

Confirmeu quin mode d'adaptador esteu depurant

Només un adaptador en mode NAT simple es comporta com descriu aquest article. Un adaptador pont es troba a la xarxa física amb identitat pròpia, una xarxa NAT és un commutador virtual amb nom i configuració DHCP i DNS pròpies, i un client VPN dins del convidat afegeix un segon resolutor sencer. Confirmeu el mode abans de continuar llegint, perquè la reparació és diferent en cadascun d'aquests casos.

Una màquina virtual pot portar dos adaptadors en modes diferents, i l'afectat no sempre és el primer.

Comproveu també que l'amfitrió resolgui el nom. Obriu la mateixa aplicació a l'amfitrió amb el túnel aixecat, fent servir el mateix nom completament qualificat que farà servir el convidat. Si l'amfitrió també falla, el convidat no en té la culpa i cap canvi de xarxa virtual ho arreglarà.

Seguiu un nom a través del resolutor del convidat

Trieu un nom intern i un nom públic de control, i proveu tots dos als dos llocs. Un nom públic que es resol mentre el privat no ho fa localitza la fallada al camí privat i no a la resolució de noms en general. Provar només el nom privat us deixa sense manera de distingir un resolutor trencat d'una ruta trencada.

Dins del convidat, mireu què té configurat realment el resolutor. En un convidat Ubuntu amb systemd-resolved, l'estat per enllaç mostra els servidors que han arribat, i el fitxer resolv.conf pot contenir només una adreça stub, cosa que és correcta i no sospitosa. Un fitxer editat a mà o un client DNS xifrat a part poden enviar les consultes a un altre lloc completament. Anoteu què trobeu abans de canviar-ho.

resolvectl status
resolvectl query app.internal.example

Separeu aquí la resolució de l'abastabilitat. Una adreça que arriba mentre el servei continua inaccessible és una qüestió d'encaminament o de política, no de DNS.

Proveu el mode de resolutor de l'amfitrió en aquest adaptador

Les opcions de DNS de la NAT de VirtualBox descriuen mecanismes diferents, i la diferència importa quan el resolutor propi de l'amfitrió canvia amb el túnel. El proxy DNS reenvia les peticions del convidat als servidors que li han donat. El mode de resolutor de l'amfitrió intercepta les peticions i crida l'API DNS de l'amfitrió, que és el mode que segueix un resolutor Windows reconfigurat per un client VPN.

Activeu el mecanisme equivocat i l'ordre tindrà èxit igualment mentre el comportament no canvia, que és una manera confusa de perdre una tarda.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Anoteu la configuració actual de la màquina virtual, atureu-la i apunteu a l'adaptador que heu confirmat abans. El dígit final de l'opció és un número d'adaptador i no una constant, així que aplicar-lo a una màquina l'adaptador afectat de la qual és el segon és una operació silenciosa sense efecte. Engegueu el convidat i comproveu la configuració de resolutor que ha rebut realment, perquè un paràmetre manual al convidat passa per sobre de tot el que ofereix la capa NAT. Recordeu que el mode de resolutor de l'amfitrió també assumeix que el camí DNS propi de l'amfitrió és el que volíeu compartir.

Torneu a fer les mateixes proves amb una reconnexió de la VPN

Repetiu les dues consultes al convidat, després obriu l'aplicació real i deixeu que validi el certificat ella mateixa. Una prova només d'adreça és útil per aïllar la resolució de noms i no equival a una sessió TLS funcional, així que no us atureu en un ping. Després, en una finestra aprovada, desconnecteu i torneu a connectar el túnel de l'amfitrió i repetiu un cop més. Un comportament que només es manté a la primera connexió després de l'arrencada és un problema de cicle de vida que cal informar, no un misteri de DNS a perseguir amb un altre resolutor.

Que la resolució pública funcioni no demostra que les consultes privades s'hagin quedat al camí que exigeix la vostra política.

Quan el mode de resolutor de l'amfitrió no canvia res, torneu a posar la configuració anotada i conserveu les quatre observacions: què ha retornat l'amfitrió, què ha retornat el convidat, el mode de l'adaptador i l'estat del resolutor. Un servidor intern inaccessible, un filtre que exclou el trànsit de l'hipervisor i una sobreescriptura al costat del convidat necessiten cadascun una correcció diferent. Convertir l'adaptador en un pont canvia el disseny de la xarxa i no és un reinici del DNS.