O convidado de Hyper-V perde o DNS cando se conecta a VPN do host

O convidado estaba ben esta mañá. Logo o host levantou Cisco AnyConnect e a VM perdeu o DNS, a confianza do dominio e o cartafol compartido, sen que nada cambiase dentro dela. Un túnel de host e unha rede de convidado son camiños separados, e conectar un non move o outro. Traballa desde dentro do convidado cara a fóra e anota o que ves antes de cambiar nada.

Que pode ver aínda o convidado

Rexistra o enderezo, a porta de enlace predeterminada e o resolvedor na VM, unha vez antes de que o host se conecte e outra despois. Un convidado que conservou o enderezo e só perdeu a resolución de nomes ten un problema de resolvedor. Un convidado que nunca tivo ruta ten un problema de camiño, e os dous requiren traballo distinto. Desde o host non os podes distinguir, por iso a lectura ten que vir de dentro.

Eses tres rexistros, tomados dúas veces, son a túa liña base. Todo o posterior mídese contra eles.

Que saída usa o convidado

Hyper-V responde a isto con dous comandos: Get-VMSwitch enumera os conmutadores, e Get-VMNetworkAdapter -VMName TestVM mostra aquel ao que está conectado o convidado. O Default Switch é unha rede NAT que Windows administra; un conmutador externo entrega o tráfico a un adaptador físico; un conmutador interno non transporta nada ata que alguén engade NAT ou un encamiñador. VirtualBox presenta as mesmas tres ideas como NAT, NAT Network e bridged.

O modo decide se o túnel do host pode importar sequera. Un convidado NAT tradúceo WinNAT e despois reenvíao a pila do host, así que segue a táboa de rutas do host; cun cliente de túnel completo o seu tráfico é o tráfico que entra no adaptador VPN, e descártase cando o cliente bloquea a subrede local. Un convidado en ponte sobre un conmutador externo nunca chega ao encamiñamento do host: as súas tramas saen directamente da NIC física, así que evita tanto o túnel como a política de LAN local do cliente.

Compartir o túnel do host con Hyper-V

Se o convidado necesita o túnel e non pode executar o seu propio cliente, Windows pode compartir a conexión VPN. Abre as propiedades do adaptador VPN, vai a Compartir e permite que outros usuarios de rede se conecten a través del. Apunta a conexión de rede doméstica ao adaptador de Hyper-V, vEthernet (Default Switch), e despois proba unha petición nova desde dentro do convidado.

Trata esta disposición como unha solución de laboratorio, porque se comporta como tal. Debe volverse aplicar tras unha desconexión, unha reconexión ou un reinicio do host. Nalgunhas compilacións de Windows 11 o adaptador falta por completo no despregable, e entón esta ruta queda pechada.

Reinstalar a característica Hyper-V rescatou uns cantos convidados teimosos. Deixa iso para o final e anota primeiro o estado do convidado.

Reenvío de portas cando a subrede está filtrada

Unha VPN de host que filtra a subrede NAT do convidado rompe o acceso directo, non a resolución de nomes. A VM está en execución, pero ssh [email protected] colga, mentres a tradución do hipervisor segue funcionando. Reenvía as portas que o traballo necesita e conéctate ao enderezo do host no seu lugar. As liñas de Vagrantfile de abaixo cobren SSH e un servizo HTTPS; ambas se engaden antes da recarga.

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

A resolución de nomes é unha decisión aparte e merece a súa propia corrección. Activa a característica de resolvedor do host para ese adaptador NAT, ou configura o servidor DNS interno dentro do convidado a man. Apuntar o convidado a un resolvedor público fai que a navegación funcione e rompe todos os nomes internos, o que é peor que a caída porque parece un éxito. Proba un nome que só coñeza o resolvedor interno.

A comprobación que che di que funcionou

Despois de calquera destes cambios, executa unha petición nova desde dentro do convidado coa VPN do host conectada, non antes. Volve comprobar o uso compartido tras unha reconexión e tras un reinicio, porque unha corrección que só sobrevive a un dos dous non é unha corrección. Confirma que a lista de resolvedores do convidado coincide coa rede que o seu tráfico usa de verdade. Despois proba o reenvío de portas desde o enderezo do host, porque probalo desde o convidado non demostra nada. Desde dentro do convidado, dúas comprobacións de PowerShell cobren o resolvedor e a porta reenviada:

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

Rexistra cada cambio de conmutador ou controlador co seu paso de desfacer. A guía de Microsoft sobre Hyper-V NAT explica que é realmente o Default Switch, e paga a pena lela antes de crear unha segunda rede NAT que entre en conflito con ela.