Nawawala ang DNS ng bisita ng Hyper-V kapag kumonekta ang VPN ng host

Maayos ang bisita kaninang umaga. Pagkatapos ay binuksan ng host ang Cisco AnyConnect at nawala ang DNS, tiwala sa domain at shared folder ng VM, nang walang nagbago sa loob nito. Magkahiwalay na landas ang tunnel ng host at network ng bisita, at ang pagkonekta sa isa ay hindi naglilipat sa isa. Magtrabaho mula sa loob ng bisita palabas, at isulat ang nakikita mo bago baguhin ang anuman.

Ano pa ang nakikita ng bisita

Itala ang address, default gateway at resolver sa VM, isang beses bago kumonekta ang host at isang beses pagkatapos. Ang bisitang nagpanatili ng address at nawalan lamang ng resolution ng pangalan ay may problema sa resolver. Ang bisitang hindi kailanman nagkaroon ng ruta ay may problema sa landas, at ang dalawa ay nangangailangan ng magkaibang gawain. Mula sa host hindi mo sila makikilala, kaya ang pagbasa ay dapat manggaling sa loob.

Ang tatlong pagbasang iyon, kinuha nang dalawang beses, ang baseline mo. Lahat ng sumunod ay sinusukat laban sa kanila.

Aling labasan ang ginagamit ng bisita

Sinasagot ito ng Hyper-V sa dalawang utos: Get-VMSwitch naglilista ng mga switch, at Get-VMNetworkAdapter -VMName TestVM ipinapakita ang konektado sa bisita. Ang Default Switch ay NAT network na pinamamahalaan ng Windows; ang external switch ay nagbibigay ng trapiko sa pisikal na adapter; ang internal switch ay wala namang dinadala hanggang may magdagdag ng NAT o router. Ipinapakita ng VirtualBox ang parehong tatlong ideya bilang NAT, NAT Network at bridged.

Ang mode ang nagpapasya kung may halaga man ang tunnel ng host. Ang NAT guest ay isinasalin ng WinNAT at pagkatapos ay ipinapasa ng host stack, kaya sinusunod nito ang routing table ng host; sa full-tunnel client, ang trapiko nito ay ang trapikong pumapasok sa VPN adapter, at itinatapon kapag hinarang ng client ang lokal na subnet. Ang naka-bridge na bisita sa external switch ay hindi kailanman umabot sa routing ng host: direktang lumalabas ang mga frame nito mula sa pisikal na NIC, kaya nilalampasan nito ang tunnel at ang lokal na patakaran ng LAN ng client.

Ibinabahagi ang tunnel ng host sa Hyper-V

Kung kailangan ng bisita ang tunnel at hindi nito mapatakbo ang sariling client, maaaring ibahagi ng Windows ang koneksyon ng VPN. Buksan ang mga katangian ng VPN adapter, pumunta sa Pagbabahagi, at payagan ang ibang mga network user na kumonekta sa pamamagitan nito. Ituro ang home networking connection sa Hyper-V adapter, vEthernet (Default Switch), pagkatapos ay subukan ang bagong kahilingan mula sa loob ng bisita.

Ituring ang setup na ito na solusyong pang-laboratoryo, dahil ganoon ang ugali nito. Kailangan itong muling ilapat pagkatapos ng disconnect, reconnect o reboot ng host. Sa ilang build ng Windows 11, wala nang tuluyan ang adapter sa drop-down, at sarado na ang landas na ito.

Nailigtas ng muling pag-install ng Hyper-V feature ang ilang matigas ang ulong bisita. Itabi iyon sa huli, at itala muna ang kalagayan ng bisita.

Pag-forward ng port kapag na-filter ang subnet

Ang host VPN na nagfi-filter sa NAT subnet ng bisita ay sumisira sa direktang access, hindi sa resolution ng pangalan. Tumakbo ang VM, ngunit ssh [email protected] bumabagal, habang gumagana pa ang pagsasalin ng hypervisor. I-forward ang mga port na kailangan ng gawain at kumonekta sa address ng host sa halip. Ang mga linya ng Vagrantfile sa ibaba ay sumasaklaw sa SSH at isang HTTPS service; parehong ipinasok bago ang reload.

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

Ang resolution ng pangalan ay hiwalay na desisyon at karapat-dapat sa sariling pagwawasto. I-on ang resolver feature ng host para sa NAT adapter na iyon, o mano-manong i-configure ang internal DNS server sa loob ng bisita. Ang pagtutok sa bisita sa pampublikong resolver ay nagpapagana sa pag-browse at sumisira sa bawat panloob na pangalan, na mas malala pa sa outage dahil mukhang tagumpay ito. Subukan ang pangalang alam lamang ng internal resolver.

Ang tseke na nagsasabing gumana ito

Pagkatapos ng alinman sa mga pagbabagong ito, magpatakbo ng bagong kahilingan mula sa loob ng bisita habang konektado ang VPN ng host, hindi bago. Muling suriin ang pagbabahagi pagkatapos ng reconnect at pagkatapos ng reboot, dahil ang pagwawastong nakakaligtas sa isa lamang sa kanila ay hindi pagwawasto. Kumpirmahin na tumutugma ang listahan ng resolver ng bisita sa network na talagang ginagamit ng trapiko nito. Pagkatapos ay subukan ang pag-forward ng port mula sa address ng host, dahil walang pinatutunayan ang pagsubok mula sa bisita. Mula sa loob ng bisita, dalawang pagsusuri ng PowerShell ang sumasaklaw sa resolver at sa na-forward na port:

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

Itala ang bawat pagbabago ng switch o driver kasama ang hakbang sa pag-undo. Ang gabay ng Microsoft sa Hyper-V NAT ay nagpapaliwanag kung ano talaga ang Default Switch, at sulit itong basahin bago ka gumawa ng pangalawang NAT network na sumasalungat dito.