L’ospite Hyper-V perde il DNS quando si connette la VPN dell’host

L’ospite stava bene questa mattina. Poi l’host ha avviato Cisco AnyConnect e la VM ha perso il DNS, l’attendibilità del dominio e la cartella condivisa, senza che nulla cambiasse al suo interno. Un tunnel host e una rete ospite sono percorsi separati, e connetterne uno non sposta l’altro. Lavora dall’interno dell’ospite verso l’esterno e annota ciò che vedi prima di cambiare qualsiasi cosa.

Cosa può ancora vedere l’ospite

Registra l’indirizzo, il gateway predefinito e il resolver nella VM, una volta prima che l’host si connetta e una dopo. Un ospite che ha mantenuto l’indirizzo e perso solo la risoluzione dei nomi ha un problema di resolver. Un ospite che non ha mai avuto una route ha un problema di percorso, e i due richiedono lavori diversi. Dall’host non puoi distinguerli, per questo la lettura deve venire dall’interno.

Quelle tre letture, prese due volte, sono la tua linea di base. Tutto ciò che segue si misura rispetto a esse.

Quale uscita usa l’ospite

Hyper-V risponde a questo con due comandi: Get-VMSwitch elenca gli switch, e Get-VMNetworkAdapter -VMName TestVM mostra quello a cui è collegato l’ospite. Il Default Switch è una rete NAT gestita da Windows; uno switch esterno consegna il traffico a un adattatore fisico; uno switch interno non trasporta nulla finché qualcuno non aggiunge NAT o un router. VirtualBox presenta le stesse tre idee come NAT, NAT Network e bridged.

La modalità decide se il tunnel dell’host può avere importanza. Un ospite NAT viene tradotto da WinNAT e poi inoltrato dallo stack dell’host, quindi segue la tabella di routing dell’host; con un client a tunnel completo il suo traffico è il traffico che entra nell’adattatore VPN, e viene scartato quando il client blocca la subnet locale. Un ospite in bridge su uno switch esterno non raggiunge mai il routing dell’host: i suoi frame escono direttamente dalla NIC fisica, quindi aggira sia il tunnel sia la policy di LAN locale del client.

Condividere il tunnel dell’host con Hyper-V

Se l’ospite ha bisogno del tunnel e non può eseguire un proprio client, Windows può condividere la connessione VPN. Apri le proprietà dell’adattatore VPN, vai a Condivisione e consenti ad altri utenti di rete di connettersi tramite esso. Indirizza la connessione di rete domestica verso l’adattatore Hyper-V, vEthernet (Default Switch), poi prova una nuova richiesta dall’interno dell’ospite.

Tratta questa configurazione come una soluzione da laboratorio, perché si comporta così. Va riapplicata dopo una disconnessione, una riconnessione o un riavvio dell’host. In alcune build di Windows 11 l’adattatore manca del tutto nell’elenco a discesa, e allora questa strada è chiusa.

Reinstallare la funzionalità Hyper-V ha salvato alcuni ospiti ostinati. Tienilo per ultimo e annota prima lo stato dell’ospite.

Inoltro delle porte quando la subnet è filtrata

Una VPN host che filtra la subnet NAT dell’ospite rompe l’accesso diretto, non la risoluzione dei nomi. La VM è in esecuzione, eppure ssh [email protected] si blocca, mentre la traduzione dell’hypervisor funziona ancora. Inoltra le porte di cui il lavoro ha bisogno e connettiti all’indirizzo dell’host invece. Le righe Vagrantfile qui sotto coprono SSH e un servizio HTTPS; entrambe vanno inserite prima del ricaricamento.

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

La risoluzione dei nomi è una decisione separata e merita una propria correzione. Attiva la funzione di resolver dell’host per quell’adattatore NAT, oppure configura il server DNS interno dentro l’ospite a mano. Puntare l’ospite a un resolver pubblico fa funzionare la navigazione e rompe ogni nome interno, il che è peggio dell’interruzione perché sembra un successo. Prova un nome che conosce solo il resolver interno.

La verifica che ti dice che ha funzionato

Dopo uno di questi cambiamenti, esegui una nuova richiesta dall’interno dell’ospite con la VPN dell’host connessa, non prima. Ricontrolla la condivisione dopo una riconnessione e dopo un riavvio, perché una correzione che sopravvive solo a uno dei due non è una correzione. Conferma che l’elenco dei resolver dell’ospite corrisponda alla rete che il suo traffico usa davvero. Poi prova l’inoltro delle porte dall’indirizzo dell’host, perché provarlo dall’ospite non dimostra nulla. Dall’interno dell’ospite, due controlli PowerShell coprono il resolver e la porta inoltrata:

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

Annota ogni modifica di switch o driver con il suo passo di annullamento. La guida Microsoft su Hyper-V NAT spiega cos’è davvero il Default Switch, e vale la pena leggerla prima di creare una seconda rete NAT che entri in conflitto con essa.