A Hyper-V vendég elveszíti a DNS-t, amikor a gazdagép VPN-je csatlakozik

A vendég ma reggel jól volt. Aztán a gazdagép elindította a Cisco AnyConnectet, és a VM elveszítette a DNS-t, a tartományi bizalmat és a megosztott mappát, miközben belül semmi sem változott. A gazdagép-alagút és a vendéghálózat külön útvonalak, és az egyik csatlakoztatása nem mozgatja a másikat. Belülről kifelé dolgozzon, és írja le, mit lát, mielőtt bármit megváltoztat.

Mit lát még a vendég

Jegyezze fel a címet, az alapértelmezett átjárót és a feloldót a VM-ben, egyszer a gazdagép csatlakozása előtt és egyszer utána. Az a vendég, amely megtartotta a címét és csak a névfeloldást vesztette el, feloldóproblémával küzd. Az a vendég, amelynek soha nem volt útvonala, útvonalproblémával küzd, és a kettő más munkát igényel. A gazdagépről nem tudja megkülönböztetni őket, ezért az olvasásnak belülről kell jönnie.

Ez a három olvasat, kétszer véve, az alapvonala. Minden későbbi ehhez mérten értékelendő.

Melyik kijáratot használja a vendég

A Hyper-V két paranccsal válaszol erre: Get-VMSwitch felsorolja a kapcsolókat, és Get-VMNetworkAdapter -VMName TestVM megmutatja azt, amelyhez a vendég csatlakozik. A Default Switch egy Windows által kezelt NAT-hálózat; a külső kapcsoló a forgalmat fizikai adapternek adja át; a belső kapcsoló semmit sem szállít, amíg valaki NAT-ot vagy útválasztót nem ad hozzá. A VirtualBox ugyanezt a három ötletet NAT, NAT Network és bridged néven mutatja be.

A mód dönti el, hogy a gazdagép alagútja egyáltalán számíthat-e. A NAT-vendéget a WinNAT fordítja le, majd a gazdagép verem továbbítja, így a gazdagép útvonaltáblázatát követi; teljes alagútú klienssel a forgalma az a forgalom, amely a VPN-adapterbe belép, és eldobódik, amikor a kliens blokkolja a helyi alhálózatot. A külső kapcsolóra hídolt vendég soha nem éri el a gazdagép útválasztását: a keretei közvetlenül a fizikai NIC-ről távoznak, így megkerüli az alagutat és a kliens helyi hálózati szabályzatát is.

A gazdagép alagútjának megosztása a Hyper-V-vel

Ha a vendégnek szüksége van az alagútra, és nem tudja saját kliensét futtatni, a Windows megoszthatja a VPN-kapcsolatot. Nyissa meg a VPN-adapter tulajdonságait, lépjen a Megosztásra, és engedje meg más hálózati felhasználóknak, hogy rajta keresztül csatlakozzanak. Irányítsa az otthoni hálózati kapcsolatot a Hyper-V adapterre, vEthernet (Default Switch), majd teszteljen egy friss kérést a vendég belsejéből.

Tekintse ezt a megoldást laboratóriumi javításnak, mert így viselkedik. Újra kell alkalmazni leválasztás, újracsatlakozás vagy a gazdagép újraindítása után. Egyes Windows 11 buildekben az adapter teljesen hiányzik a legördülő listából, és akkor ez az útvonal zárva van.

A Hyper-V szolgáltatás újratelepítése megmentett néhány makacs vendéget. Hagyja ezt a végére, és először jegyezze fel a vendég állapotát.

Porttovábbítás, amikor az alhálózat szűrt

A vendég NAT-alhálózatát szűrő gazdagép-VPN a közvetlen hozzáférést töri meg, nem a névfeloldást. A VM fut, mégis ssh [email protected] lefagy, miközben a hypervisor fordítása még működik. Továbbítsa a munkához szükséges portokat, és csatlakozzon inkább a gazdagép címéhez. Az alábbi Vagrantfile-sorok az SSH-t és egy HTTPS-szolgáltatást fedik le; mindkettő az újratöltés előtt kerül be.

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

A névfeloldás külön döntés, és saját javítást érdemel. Kapcsolja be a gazdagép feloldófunkcióját ahhoz a NAT-adapterhez, vagy állítsa be kézzel a belső DNS-kiszolgálót a vendégen belül. Ha a vendéget nyilvános feloldóra irányítja, a böngészés működik, és minden belső név eltörik, ami rosszabb a kiesésnél, mert sikernek látszik. Teszteljen egy nevet, amelyet csak a belső feloldó ismer.

Az ellenőrzés, amely megmondja, hogy sikerült

Ezek bármelyike után futtasson friss kérést a vendég belsejéből a gazdagép VPN-jének csatlakoztatva, nem előtte. Ellenőrizze újra a megosztást újracsatlakozás és újraindítás után, mert a javítás, amely csak az egyiket éli túl, nem javítás. Erősítse meg, hogy a vendég feloldólistája megegyezik azzal a hálózattal, amelyet a forgalma valóban használ. Ezután tesztelje a porttovábbítást a gazdagép címéről, mert a vendégből tesztelve semmit sem bizonyít. A vendég belsejéből két PowerShell-ellenőrzés fedi le a feloldót és a továbbított portot:

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

Jegyezze fel minden kapcsoló- vagy illesztőprogram-változtatást a visszavonási lépésével együtt. A Microsoft útmutatója a Hyper-V NAT témában elmagyarázza, mi is valójában a Default Switch, és érdemes elolvasni, mielőtt olyan második NAT-hálózatot hoz létre, amely ütközik vele.