„Hyper-V“ svečias praranda DNS, kai prisijungia pagrindinio kompiuterio VPN

Svečias šįryt veikė gerai. Tada pagrindinis kompiuteris įjungė Cisco AnyConnect, ir VM prarado DNS, domeno pasitikėjimą bei bendrą aplanką, nors viduje niekas nepasikeitė. Pagrindinio kompiuterio tunelis ir svečio tinklas yra atskiri keliai, o vieno prijungimas neperkelia kito. Dirbkite iš svečio vidaus į išorę ir užsirašykite, ką matote, prieš ką nors keisdami.

Ką svečias dar gali matyti

Užrašykite adresą, numatytąją tinklų sietuvą ir sprendiklį VM, kartą prieš pagrindiniam kompiuteriui prisijungiant ir kartą po to. Svečias, kuris išsaugojo adresą ir prarado tik vardų sprendimą, turi sprendiklio problemą. Svečias, kuris niekada neturėjo maršruto, turi kelio problemą, ir abiem reikia skirtingo darbo. Iš pagrindinio kompiuterio jų neatskirsite, todėl skaitymas turi ateiti iš vidaus.

Tie trys rodmenys, paimti du kartus, yra jūsų bazinė linija. Viskas, kas vėliau, matuojama pagal juos.

Kokią išėjimą naudoja svečias

Hyper-V atsako į tai dviem komandomis: Get-VMSwitch išvardija jungiklius, o Get-VMNetworkAdapter -VMName TestVM parodo tą, prie kurio prijungtas svečias. Default Switch yra Windows valdomas NAT tinklas; išorinis jungiklis perduoda srautą fiziniam adapteriui; vidinis jungiklis nieko neneša, kol kas nors nepridės NAT arba maršrutizatoriaus. VirtualBox pateikia tas pačias tris idėjas kaip NAT, NAT Network ir bridged.

Režimas nusprendžia, ar pagrindinio kompiuterio tunelis apskritai gali turėti reikšmės. NAT svečias verčiamas WinNAT, o paskui persiunčiamas pagrindinio kompiuterio steko, todėl jis seka pagrindinio kompiuterio maršrutų lentelę; su viso tunelio klientu jo srautas yra tas srautas, kuris patenka į VPN adapterį, ir jis išmetamas, kai klientas blokuoja vietinį potinklį. Prie išorinio jungiklio tiltu prijungtas svečias niekada nepasiekia pagrindinio kompiuterio maršrutizavimo: jo kadrai išeina tiesiai iš fizinės NIC, todėl jis apeina ir tunelį, ir kliento vietinio tinklo politiką.

Pagrindinio kompiuterio tunelio bendrinimas su Hyper-V

Jei svečiui reikia tunelio ir jis negali paleisti savo kliento, Windows gali bendrinti VPN ryšį. Atidarykite VPN adapterio ypatybes, eikite į Bendrinimas ir leiskite kitiems tinklo naudotojams jungtis per jį. Nukreipkite namų tinklo ryšį į Hyper-V adapterį, vEthernet (Default Switch), tada išbandykite naują užklausą iš svečio vidaus.

Traktuokite šią sąranką kaip laboratorinį sprendimą, nes ji taip ir elgiasi. Ją reikia taikyti iš naujo po atsijungimo, prisijungimo iš naujo ar pagrindinio kompiuterio perkrovimo. Kai kuriuose Windows 11 leidimuose adapterio išskleidžiamajame sąraše visai nėra, ir tada šis kelias uždarytas.

Hyper-V funkcijos perinstaliavimas išgelbėjo kelis užsispyrusius svečius. Palikite tai pabaigai ir pirmiausia užrašykite svečio būseną.

Prievadų peradresavimas, kai potinklis filtruojamas

Pagrindinio kompiuterio VPN, filtruojantis svečio NAT potinklį, sulaužo tiesioginę prieigą, o ne vardų sprendimą. VM veikia, tačiau ssh [email protected] pakimba, kol hipervizoriaus vertimas dar veikia. Peradresuokite prievadus, kurių reikia darbui, ir prisijunkite prie pagrindinio kompiuterio adreso. Žemiau esančios Vagrantfile eilutės apima SSH ir vieną HTTPS paslaugą; abi įterpiamos prieš perkrovimą.

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

Vardų sprendimas yra atskiras sprendimas ir nusipelno savo pataisos. Įjunkite pagrindinio kompiuterio sprendiklio funkciją tam NAT adapteriui, arba rankiniu būdu sukonfigūruokite vidinį DNS serverį svečio viduje. Nukreipus svečią į viešą sprendiklį, naršymas veikia, bet sugadinamas kiekvienas vidinis vardas, o tai blogiau už sutrikimą, nes atrodo kaip sėkmė. Išbandykite vardą, kurį žino tik vidinis sprendiklis.

Patikra, kuri pasako, kad pavyko

Po bet kurio iš šių pakeitimų paleiskite naują užklausą iš svečio vidaus su prijungtu pagrindinio kompiuterio VPN, o ne prieš tai. Dar kartą patikrinkite bendrinimą po prisijungimo iš naujo ir po perkrovimo, nes pataisa, kuri išlieka tik vienu iš tų atvejų, nėra pataisa. Patvirtinkite, kad svečio sprendiklių sąrašas atitinka tinklą, kurį jo srautas iš tikrųjų naudoja. Tada išbandykite prievadų peradresavimą iš pagrindinio kompiuterio adreso, nes bandymas iš svečio nieko neįrodo. Iš svečio vidaus dvi PowerShell patikros apima sprendiklį ir peradresuotą prievadą:

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

Užrašykite kiekvieną jungiklio ar tvarkyklės pakeitimą su jo atšaukimo žingsniu. Microsoft Hyper-V NAT vadovas paaiškina, kas iš tikrųjų yra Default Switch, ir verta jį perskaityti prieš kuriant antrą NAT tinklą, kuris su juo konfliktuoja.