Oaspetele Hyper-V pierde DNS când se conectează VPN-ul gazdei

Oaspetele era bine dimineață. Apoi gazda a pornit Cisco AnyConnect și VM-ul a pierdut DNS-ul, încrederea în domeniu și folderul partajat, fără ca nimic să se schimbe în interiorul lui. Tunelul gazdei și rețeaua oaspetelui sunt căi separate, iar conectarea uneia nu o mută pe cealaltă. Lucrați din interiorul oaspetelui spre exterior și notați ce vedeți înainte de a schimba ceva.

Ce mai poate vedea oaspetele

Înregistrați adresa, gateway-ul implicit și resolverul din VM, o dată înainte ca gazda să se conecteze și o dată după. Un oaspete care și-a păstrat adresa și a pierdut doar rezolvarea numelor are o problemă de resolver. Un oaspete care nu a avut niciodată o rută are o problemă de cale, iar cele două cer muncă diferită. Din gazdă nu le puteți distinge, de aceea citirea trebuie să vină din interior.

Acele trei citiri, luate de două ori, sunt linia voastră de bază. Tot ce urmează se măsoară față de ele.

Ce ieșire folosește oaspetele

Hyper-V răspunde la aceasta cu două comenzi: Get-VMSwitch listează switch-urile, iar Get-VMNetworkAdapter -VMName TestVM arată cel la care este conectat oaspetele. Default Switch este o rețea NAT administrată de Windows; un switch extern predă traficul unui adaptor fizic; un switch intern nu transportă nimic până când cineva adaugă NAT sau un router. VirtualBox prezintă aceleași trei idei ca NAT, NAT Network și bridged.

Modul decide dacă tunelul gazdei poate conta deloc. Un oaspete NAT este tradus de WinNAT și apoi transmis de stiva gazdei, așa că urmează tabela de rutare a gazdei; cu un client de tunel complet, traficul său este traficul care intră în adaptorul VPN și este aruncat când clientul blochează subrețeaua locală. Un oaspete punte pe un switch extern nu ajunge niciodată la rutarea gazdei: cadrele sale ies direct din NIC-ul fizic, așa că ocolește atât tunelul, cât și politica de LAN locală a clientului.

Partajarea tunelului gazdei cu Hyper-V

Dacă oaspetelui îi trebuie tunelul și nu poate rula propriul client, Windows poate partaja conexiunea VPN. Deschideți proprietățile adaptorului VPN, mergeți la Partajare și permiteți altor utilizatori de rețea să se conecteze prin el. Îndreptați conexiunea de rețea de domiciliu spre adaptorul Hyper-V, vEthernet (Default Switch), apoi testați o cerere nouă din interiorul oaspetelui.

Tratați această configurare ca pe o soluție de laborator, pentru că așa se comportă. Trebuie reaplicată după o deconectare, o reconectare sau o repornire a gazdei. În unele versiuni Windows 11 adaptorul lipsește complet din lista derulantă, iar atunci această cale este închisă.

Reinstalarea funcției Hyper-V a salvat câțiva oaspeți încăpățânați. Păstrați asta pentru final și notați mai întâi starea oaspetelui.

Redirecționarea porturilor când subrețeaua este filtrată

Un VPN al gazdei care filtrează subrețeaua NAT a oaspetelui rupe accesul direct, nu rezolvarea numelor. VM-ul rulează, totuși ssh [email protected] se blochează, în timp ce traducerea hipervizorului încă funcționează. Redirecționați porturile de care are nevoie lucrul și conectați-vă la adresa gazdei în schimb. Liniile Vagrantfile de mai jos acoperă SSH și un serviciu HTTPS; ambele se adaugă înainte de reîncărcare.

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

Rezolvarea numelor este o decizie separată și merită propria corectare. Activați funcția de resolver a gazdei pentru acel adaptor NAT, sau configurați manual serverul DNS intern din interiorul oaspetelui. Direcționarea oaspetelui către un resolver public face navigarea să funcționeze și rupe fiecare nume intern, ceea ce este mai rău decât întreruperea pentru că pare un succes. Testați un nume pe care îl știe doar resolverul intern.

Verificarea care vă spune că a funcționat

După oricare dintre aceste modificări, rulați o cerere nouă din interiorul oaspetelui cu VPN-ul gazdei conectat, nu înainte. Verificați din nou partajarea după o reconectare și după o repornire, pentru că o corectare care supraviețuiește doar uneia dintre ele nu este o corectare. Confirmați că lista de resolvere a oaspetelui corespunde rețelei pe care traficul său o folosește cu adevărat. Apoi testați redirecționarea porturilor de la adresa gazdei, pentru că testarea din oaspete nu demonstrează nimic. Din interiorul oaspetelui, două verificări PowerShell acoperă resolverul și portul redirecționat:

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

Notați fiecare modificare de switch sau driver împreună cu pasul de anulare. Ghidul Microsoft despre Hyper-V NAT explică ce este de fapt Default Switch și merită citit înainte de a crea o a doua rețea NAT care intră în conflict cu el.