Il DNS dell’ospite VirtualBox NAT si rompe quando l’host entra in una VPN

Su un host Windows il nome interno dell’applicazione si risolve appena la VPN si connette, mentre dentro un ospite Ubuntu no. L’ospite conserva le proprie impostazioni del resolver, e l’adattatore NAT davanti può rispondere alle query DNS in due modi diversi. Puntare l’ospite a un resolver pubblico fa ricaricare i siti mentre i nomi privati restano rotti. Per questo il percorso del resolver viene tracciato prima di modificare qualsiasi cosa.

Tracciate una risoluzione attraverso l’adattatore NAT

Scegliete un nome interno completamente qualificato e un nome pubblico come controllo. Con il tunnel attivo, confermate sull’host che il nome interno si risolve e che l’applicazione dietro si apre. Poi eseguite le stesse due risoluzioni dentro l’ospite e confrontate le risposte, non gli strumenti.

Confermate che l’adattatore sia davvero NAT semplice prima di procedere. Un adattatore bridge, una rete NAT con nome e un secondo client VPN dentro l’ospite hanno ciascuno la propria configurazione e la propria spiegazione. Indovinare a questo punto spreca il resto dell’indagine.

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

Il primo comando mostra la modalità dell’adattatore e qualsiasi rete NAT collegata. Dentro un ospite Ubuntu il secondo elenca le impostazioni DNS per collegamento, e il terzo spesso rivela solo un indirizzo stub locale, il che significa che l’upstream reale si trova altrove.

Tenete separate risoluzione e raggiungibilità. Un ospite che riceve l’indirizzo corretto ma non riesce ad aprire una connessione ha un problema di routing, filtraggio o permessi del servizio, e ulteriori modifiche DNS non lo toccheranno mai. Testate l’indirizzo separatamente e annotate quale dei due ha fallito.

La modalità proxy e la modalità resolver dell’host sono meccanismi diversi

In modalità proxy il motore NAT inoltra le query dell’ospite a server DNS che conosce già. In modalità resolver dell’host intercetta la query e chiede al sistema operativo dell’host di risolvere il nome con ciò che l’host sta usando in quel momento. Solo il secondo segue un client VPN che riscrive la risoluzione dell’host quando il tunnel sale. Per questo le due impostazioni producono risposte diverse sulla stessa macchina.

Questa distinzione è tutto il problema in una frase. Dare all’ospite un elenco di indirizzi server non è lo stesso che chiedere a Windows di risolvere un nome tramite il suo resolver configurato, e su una VPN con DNS diviso le due risposte differiscono. L’opzione dell’adattatore riguarda il meccanismo, non il permesso.

Nessuna delle due modalità concede accesso a nulla. L’autorizzazione vive nella politica VPN e nel servizio, e una risoluzione che funziona significa solo che un nome è diventato un indirizzo.

Cambiate l’adattatore, poi verificate cosa riceve l’ospite

Annotate prima le impostazioni di rete e DNS della VM, poi spegnete la macchina così da modificare la configurazione persistente. Per una VM chiamata work-ubuntu il cui primo adattatore porta NAT, l’opzione per adattatore si imposta dall’host con la VM spenta. Riavviatela dopo e ispezionate il risultato invece di fidarvi del codice di uscita.

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

L’ultima cifra seleziona il numero dell’adattatore, quindi non è un valore universale; un’impostazione per l’adattatore 2 porterebbe un 2 in quella posizione. Usate il binario VBoxManage che appartiene alla versione installata di VirtualBox, perché uno più vecchio nel PATH può scrivere impostazioni che la versione in esecuzione ignora.

Attivare invece l’opzione proxy sceglie un altro meccanismo e non vi dà il comportamento del resolver dell’host. Dopo l’avvio dell’ospite, controllate la configurazione DNS che detiene realmente, perché un resolver fissato o un’impostazione DNS cifrata dentro l’ospite tiene le applicazioni su un altro percorso indipendentemente da ciò che offre l’adattatore.

Testate su tutto il ciclo di vita della VPN, non una sola volta

Ripetete entrambe le risoluzioni nell’ospite, poi aprite l’applicazione reale e lasciate che convalidi il nome host TLS. Un test di connessione solo IP isola bene il DNS, ma non è una verifica di certificato e non va presentato come tale. Annotate insieme il nome, l’indirizzo e il risultato dell’applicazione.

Durante una finestra approvata, disconnettete e riconnettete la VPN dell’host e ripetete il test. Il risultato dovrebbe corrispondere alla politica di accesso, e il fatto che la risoluzione pubblica torni a funzionare non dice nulla sul fatto che le query private siano rimaste sul percorso previsto.

Quando la modalità resolver dell’host non cambia nulla, rimettete il valore registrato e conservate le osservazioni. Un client VPN che esclude il traffico dell’hypervisor, un resolver interno irraggiungibile e un’impostazione dell’ospite fissata richiedono ciascuno una correzione diversa, e mettere in bridge l’adattatore cambia il progetto della rete invece di resettare il DNS.