El convidat de Hyper-V perd el DNS quan es connecta la VPN de l’amfitrió

El convidat anava bé aquest matí. Llavors l’amfitrió va aixecar Cisco AnyConnect i la VM va perdre el DNS, la confiança del domini i la carpeta compartida, sense que res canviés a dins seu. Un túnel d’amfitrió i una xarxa de convidat són camins separats, i connectar-ne un no mou l’altre. Treballeu de dins del convidat cap enfora i anoteu què veieu abans de canviar res.

Què pot veure encara el convidat

Registreu l’adreça, la passarel·la predeterminada i el resolutor a la VM, una vegada abans que l’amfitrió es connecti i una altra després. Un convidat que va conservar l’adreça i només va perdre la resolució de noms té un problema de resolutor. Un convidat que mai no va tenir ruta té un problema de camí, i tots dos requereixen feines diferents. Des de l’amfitrió no els podeu distingir, per això la lectura ha de venir de dins.

Aquestes tres lectures, preses dues vegades, són la vostra línia de base. Tot el que ve després es mesura contra elles.

Quina sortida fa servir el convidat

Hyper-V ho respon amb dues ordres: Get-VMSwitch llista els commutadors, i Get-VMNetworkAdapter -VMName TestVM mostra aquell al qual està connectat el convidat. El Default Switch és una xarxa NAT que Windows gestiona; un commutador extern lliura el trànsit a un adaptador físic; un commutador intern no porta res fins que algú afegeix NAT o un encaminador. VirtualBox presenta les mateixes tres idees com a NAT, NAT Network i bridged.

El mode decideix si el túnel de l’amfitrió pot tenir cap importància. Un convidat NAT el tradueix WinNAT i després el reenvia la pila de l’amfitrió, així que segueix la taula de rutes de l’amfitrió; amb un client de túnel complet, el seu trànsit és el trànsit que entra a l’adaptador VPN, i es descarta quan el client bloqueja la subxarxa local. Un convidat pont sobre un commutador extern no arriba mai a l’encaminament de l’amfitrió: les seves trames surten directament de la NIC física, així que evita tant el túnel com la política de LAN local del client.

Compartir el túnel de l’amfitrió amb Hyper-V

Si el convidat necessita el túnel i no pot executar el seu propi client, Windows pot compartir la connexió VPN. Obriu les propietats de l’adaptador VPN, aneu a Compartició i permeteu que altres usuaris de xarxa s’hi connectin. Apunteu la connexió de xarxa domèstica a l’adaptador de Hyper-V, vEthernet (Default Switch), i després proveu una petició nova des de dins del convidat.

Tracteu aquesta disposició com una solució de laboratori, perquè es comporta com a tal. S’ha de tornar a aplicar després d’una desconnexió, una reconnexió o un reinici de l’amfitrió. En algunes compilacions de Windows 11 l’adaptador falta del tot al desplegable, i llavors aquesta ruta queda tancada.

Reinstal·lar la característica Hyper-V ha rescatat uns quants convidats tossuts. Deixeu-ho per al final i anoteu primer l’estat del convidat.

Reenviament de ports quan la subxarxa està filtrada

Una VPN d’amfitrió que filtra la subxarxa NAT del convidat trenca l’accés directe, no la resolució de noms. La VM s’executa, però ssh [email protected] es penja, mentre la traducció de l’hipervisor encara funciona. Reenvieu els ports que la feina necessita i connecteu-vos a l’adreça de l’amfitrió en lloc d’això. Les línies de Vagrantfile de sota cobreixen SSH i un servei HTTPS; totes dues s’hi posen abans de la recàrrega.

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

La resolució de noms és una decisió a part i mereix la seva pròpia solució. Activeu la característica de resolutor de l’amfitrió per a aquest adaptador NAT, o configureu el servidor DNS intern dins del convidat a mà. Apuntar el convidat a un resolutor públic fa que la navegació funcioni i trenca tots els noms interns, cosa pitjor que la caiguda perquè sembla un èxit. Proveu un nom que només conegui el resolutor intern.

La comprovació que us diu que ha funcionat

Després de qualsevol d’aquests canvis, executeu una petició nova des de dins del convidat amb la VPN de l’amfitrió connectada, no abans. Torneu a comprovar la compartició després d’una reconnexió i d’un reinici, perquè una correcció que només sobreviu a un dels dos no és una correcció. Confirmeu que la llista de resolutors del convidat coincideix amb la xarxa que el seu trànsit fa servir de debò. Després proveu el reenviament de ports des de l’adreça de l’amfitrió, perquè provar-lo des del convidat no demostra res. Des de dins del convidat, dues comprovacions de PowerShell cobreixen el resolutor i el port reenviat:

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

Registreu cada canvi de commutador o controlador amb el seu pas de desfer. La guia Hyper-V NAT de Microsoft explica què és realment el Default Switch, i val la pena llegir-la abans de crear una segona xarxa NAT que hi entri en conflicte.