Il DNS dell'ospite VirtualBox si rompe quando l'host si unisce a una VPN

Un'applicazione interna si risolve sull'host Windows nel momento in cui la VPN si connette, e l'ospite Ubuntu dietro il NAT di VirtualBox continua a non trovarla. L'ospite ha il proprio resolver, e l'adattatore NAT può gestire il DNS in più di un modo. Sostituire il resolver dell'ospite con un server pubblico fa funzionare i siti ordinari e fallire i nomi privati, il che sposta il problema invece di risolverlo. Eseguite le quattro verifiche in ordine e fermatevi alla prima che non regge.

Confermate quale modalità dell'adattatore state depurando

Solo un adattatore in modalità NAT semplice si comporta come descrive questo articolo. Un adattatore bridge si trova sulla rete fisica con la propria identità, una rete NAT è uno switch virtuale con nome e impostazioni DHCP e DNS proprie, e un client VPN dentro l'ospite aggiunge un secondo resolver del tutto. Confermate la modalità prima di continuare a leggere, perché la riparazione è diversa in ciascuno di quei casi.

Una macchina virtuale può portare due adattatori in modalità diverse, e quello interessato non è sempre il primo.

Confermate anche che l'host risolva il nome. Aprite la stessa applicazione sull'host con il tunnel attivo, usando lo stesso nome completamente qualificato che userà l'ospite. Se fallisce anche l'host, l'ospite non è la causa e nessuna modifica alla rete virtuale lo risolverà.

Seguite un nome attraverso il resolver dell'ospite

Scegliete un nome interno e un nome pubblico di controllo, poi provate entrambi in entrambi i posti. Un nome pubblico che si risolve mentre quello privato no localizza il guasto sul percorso privato e non sulla risoluzione dei nomi in generale. Provare solo il nome privato vi lascia incapaci di distinguere un resolver rotto da una rotta rotta.

Dentro l'ospite, guardate per cosa è realmente configurato il resolver. Su un ospite Ubuntu con systemd-resolved, lo stato per collegamento mostra i server arrivati, e il file resolv.conf può contenere solo un indirizzo stub, il che è corretto e non sospetto. Un file modificato a mano o un client DNS cifrato separato può inviare le query altrove del tutto. Annotate ciò che trovate prima di cambiarlo.

resolvectl status
resolvectl query app.internal.example

Separa qui la risoluzione dalla raggiungibilità. Un indirizzo che arriva mentre il servizio resta irraggiungibile è una questione di routing o di policy, non di DNS.

Provate la modalità resolver dell'host su quell'adattatore

Le opzioni DNS di NAT di VirtualBox descrivono meccanismi diversi, e la differenza conta quando il resolver proprio dell'host cambia con il tunnel. Il proxy DNS inoltra le richieste dell'ospite ai server che gli sono stati forniti. La modalità resolver dell'host intercetta le richieste e chiama l'API DNS dell'host, ed è la modalità che segue un resolver Windows riconfigurato da un client VPN.

Attivate il meccanismo sbagliato e il comando riesce comunque mentre il comportamento non cambia, che è un modo confuso di perdere un pomeriggio.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

Annotate le impostazioni attuali della macchina virtuale, spegnetela e puntate all'adattatore che avete confermato prima. L'ultima cifra nell'opzione è un numero di adattatore e non una costante, quindi applicarla a una macchina il cui adattatore interessato è il secondo è un'operazione silenziosa senza effetto. Avviate l'ospite e controllate la configurazione del resolver che ha realmente ricevuto, perché un'impostazione manuale nell'ospite prevale su tutto ciò che offre il livello NAT. Ricordate che la modalità resolver dell'host presuppone anche che il percorso DNS proprio dell'host sia quello che volevate condividere.

Ripetete le stesse prove attraverso una riconnessione VPN

Ripetete entrambe le query nell'ospite, poi aprite l'applicazione reale e lasciate che convalidi il certificato da sé. Una prova solo sull'indirizzo è utile per isolare la risoluzione dei nomi e non equivale a una sessione TLS funzionante, quindi non fermatevi a un ping. Poi, in una finestra approvata, disconnettete e riconnettete il tunnel dell'host e ripetete ancora una volta. Un comportamento che regge solo alla prima connessione dopo l'avvio è un problema di ciclo di vita da segnalare, non un mistero DNS da inseguire con un altro resolver.

Che la risoluzione pubblica funzioni non dimostra che le query private siano rimaste sul percorso che la vostra policy richiede.

Quando la modalità resolver dell'host non cambia nulla, rimettete la configurazione annotata e conservate le quattro osservazioni: cosa ha restituito l'host, cosa ha restituito l'ospite, la modalità dell'adattatore e lo stato del resolver. Un server interno irraggiungibile, un filtro che esclude il traffico dell'hypervisor e una forzatura sul lato ospite richiedono ciascuno una correzione diversa. Convertire l'adattatore in un bridge cambia il progetto della rete e non è un reset del DNS.