Hyper-V-gjest mistar DNS når verten sin VPN koplar til
Ein gjeste-VM arvar ikkje tunnelen til verten. Finn svitsj- eller NAT-modusen, del VPN-adapteren der det blir tilbode, og vidaresend portar der det ikkje blir gjort.
Gjesten hadde det fint i morgon. Så starta verten Cisco AnyConnect, og VM-en mista DNS, domenetillit og den delte mappa, utan at noko endra seg inni henne. Ein vertstunnel og eit gjestenettverk er skilde vegar, og å kopla til den eine flyttar ikkje den andre. Arbeid innanfrå og ut, og skriv ned det du ser før du endrar noko.
Kva gjesten framleis kan sjå
Noter adressa, standardgatewayen og resolveren i VM-en, éin gong før verten koplar til og éin gong etterpå. Ein gjest som heldt på adressa og berre mista namneoppslag, har eit resolverproblem. Ein gjest som aldri hadde ei rute, har eit vegproblem, og dei to krev ulikt arbeid. Frå verten kan du ikkje skilja dei, difor må avlesinga koma innanfrå.
Dei tre avlesingane, tekne to gonger, er utgangspunktet ditt. Alt seinare blir målt mot dei.
Kva utgang gjesten brukar
Hyper-V svarar på dette med to kommandoar: Get-VMSwitch viser svitsjane, og Get-VMNetworkAdapter -VMName TestVM viser den gjesten er knytt til. Default Switch er eit NAT-nettverk som Windows styrer; ein ekstern svitsj gjev trafikken til ein fysisk adapter; ein intern svitsj ber ingenting før nokon legg til NAT eller ein ruter. VirtualBox presenterer dei same tre ideane som NAT, NAT Network og bridged.
Modusen avgjer om vertstunnelen i det heile kan ha noko å seia. Ein NAT-gjest blir omsett av WinNAT og deretter vidaresend av vertsstakken, så han følgjer rutetabellen til verten; med ein full-tunnel-klient er trafikken hans den trafikken som går inn i VPN-adapteren, og han blir droppa når klienten blokkerer det lokale subnettet. Ein brua gjest på ein ekstern svitsj når aldri rutinga til verten: rammene hans forlèt den fysiske NIC-en direkte, så han går utanom både tunnelen og lokalnettspolicyen til klienten.
Dela vertstunnelen med Hyper-V
Viss gjesten treng tunnelen og ikkje kan køyra sin eigen klient, kan Windows dela VPN-tilkoplinga. Opne eigenskapane til VPN-adapteren, gå til Deling, og la andre nettverksbrukarar kopla til gjennom han. Peik heimenettverkstilkoplinga mot Hyper-V-adapteren, vEthernet (Default Switch), og test deretter ein ny førespurnad innanfrå gjesten.
Handter ordninga som ein laboratoriefiks, fordi ho oppfører seg som ein. Ho må brukast på nytt etter ei fråkopling, ei attkopling eller ein omstart av verten. I nokre Windows 11-bygg manglar adapteren heilt i rullegardinlista, og då er denne vegen stengd.
Reinstallering av Hyper-V-funksjonen har redda nokre sta gjester. Spare det til sist, og noter tilstanden til gjesten først.
Portvidaresending når subnettet er filtrert
Ein verts-VPN som filtrerer NAT-subnettet til gjesten bryt direkte tilgang, ikkje namneoppslag. VM-en køyrer, men ssh [email protected] heng, medan omsetjinga til hypervisoren framleis verkar. Vidaresend portane arbeidet treng, og kopla til vertsadressa i staden. Vagrantfile-linjene nedanfor dekkjer SSH og éin HTTPS-teneste; begge blir lagde inn før omlastinga.
config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443Namneoppslag er ei eiga avgjerd og fortener si eiga retting. Slå på resolverfunksjonen til verten for den NAT-adapteren, eller konfigurer den interne DNS-tenaren inne i gjesten manuelt. Å peika gjesten mot ein offentleg resolver gjer nettlesinga verksam og bryt kvart internt namn, noko som er verre enn avbrotet fordi det ser ut som suksess. Test eit namn som berre den interne resolveren kjenner.
Sjekken som fortel deg at det verka
Etter ein av desse endringane, køyr ein ny førespurnad innanfrå gjesten med VPN-en til verten tilkopla, ikkje før. Kontroller delinga på nytt etter ei attkopling og etter ein omstart, fordi ei retting som berre overlever éin av dei, ikkje er ei retting. Stadfest at resolverlista til gjesten svarar til nettverket trafikken faktisk brukar. Test deretter portvidaresendinga frå vertsadressa, fordi å testa henne frå gjesten ikkje provar noko. Innanfrå gjesten dekkjer to PowerShell-sjekkar resolveren og den vidaresende porten:
Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22Noter kvar svitsj- eller drivarändring med tilbakekallingssteget. Microsofts Hyper-V NAT-vegvisning forklarar kva Default Switch faktisk er, og ho er verdt å lesa før du lagar eit nytt NAT-nettverk som kolliderer med det.