Hyper-V-gis verloor DNS wanneer die gasheer se VPN aanskakel

Die gis was vanoggend reg. Toe bring die gasheer Cisco AnyConnect op en die VM verloor DNS, sy domeinvertroue en die gedeelde vouer, sonder dat enigiets binne-in dit verander het. ’n Gasheertonnel en ’n gisnetwerk is aparte bane, en om die een te verbind beweeg nie die ander nie. Werk van binne die gis na buite, en skryf neer wat jy sien voordat jy enigiets verander.

Wat die gis nog kan sien

Teken die adres, die verstekpoort en die oplosser in die VM op, een keer voordat die gasheer verbind en een keer daarna. ’n Gis wat sy adres behou het en net naamoplossing verloor het, het ’n oplosserprobleem. ’n Gis wat nooit ’n roete gehad het nie, het ’n baanprobleem, en die twee verg verskillende werk. Vanaf die gasheer kan jy hulle nie onderskei nie, en daarom moet die lesing van binne kom.

Daardie drie lesings, twee keer geneem, is jou basislyn. Alles later word daarteen gemeet.

Watter uitgang die gis gebruik

Hyper-V antwoord dit met twee opdragte: Get-VMSwitch lys die skakelaars, en Get-VMNetworkAdapter -VMName TestVM wys die een waaraan die gis gekoppel is. Die Default Switch is ’n NAT-netwerk wat Windows bestuur; ’n eksterne skakelaar gee verkeer aan ’n fisiese adapter oor; ’n interne skakelaar dra niks totdat iemand NAT of ’n roeteerder byvoeg. VirtualBox bied dieselfde drie idees as NAT, NAT Network en bridged.

Die modus bepaal of die gasheertonnel hoegenaamd kan saak maak. ’n NAT-gis word deur WinNAT vertaal en dan deur die gasheer se stapel aangestuur, so dit volg die gasheer se roetetabel; met ’n voltonnel-kliënt is sy verkeer die verkeer wat die VPN-adapter binnegaan, en dit word laat val wanneer die kliënt die plaaslike subnet blokkeer. ’n Gebrugde gis op ’n eksterne skakelaar bereik nooit gasheerroetering nie: sy rame verlaat die fisiese NIC direk, so dit omseil beide die tonnel en die kliënt se plaaslike-LAN-beleid.

Die gasheertonnel met Hyper-V deel

As die gis die tonnel nodig het en nie sy eie kliënt kan laat loop nie, kan Windows die VPN-verbinding deel. Maak die VPN-adapter se eienskappe oop, gaan na Deling, en laat ander netwerkgebruikers daardeur verbind. Wys die tuisnetwerkverbinding na die Hyper-V-adapter, vEthernet (Default Switch), en toets dan ’n vars versoek van binne die gis.

Behandel die reëling as ’n laboratoriumoplossing, want dit gedra hom so. Dit moet weer toegepas word ná ’n ontkoppeling, ’n herverbinding of ’n herlaai van die gasheer. Op sommige Windows 11-boude ontbreek die adapter heeltemal uit die aftreklys, en dan is hierdie roete gesluit.

Die herinstallasie van die Hyper-V-kenmerk het ’n paar hardnekkige gisse gered. Hou dit vir laaste, en let eers op die gis se toestand.

Poortaansturing wanneer die subnet gefiltreer word

’n Gasheer-VPN wat die gis se NAT-subnet filtreer, breek direkte toegang eerder as naamoplossing. Die VM loop, maar ssh [email protected] hang, terwyl die hipervisor se vertaling steeds werk. Stuur die poorte aan wat die werk nodig het en verbind eerder na die gasheeradres. Die Vagrantfile-reëls hieronder dek SSH en een HTTPS-diens; albei gaan in voor die herlaai.

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

Naamoplossing is ’n aparte besluit en verdien sy eie oplossing. Skakel die gasheer se oplosserkenmerk vir daardie NAT-adapter aan, of stel die interne DNS-bediener met die hand binne die gis op. Om die gis na ’n publieke oplosser te wys, laat blaai werk en breek elke interne naam, wat erger is as die onderbreking omdat dit soos sukses lyk. Toets ’n naam wat net die interne oplosser ken.

Die toets wat wys dit het gewerk

Laat ná enige van hierdie veranderinge ’n vars versoek van binne die gis loop terwyl die gasheer-VPN verbind is, nie voor dit nie. Hersien die deling ná ’n herverbinding en ná ’n herlaai, want ’n oplossing wat net een van dié oorleef, is nie ’n oplossing nie. Bevestig dat die gis se oplosserlys ooreenstem met die netwerk wat sy verkeer werklik gebruik. Toets dan poortaansturing vanaf die gasheeradres, want om dit van die gis af te toets bewys niks. Van binne die gis dek twee PowerShell-toetse die oplosser en die aangestuurde poort:

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

Teken elke skakelaar- of drywerverandering met sy onttrekstap op. Die Microsoft Hyper-V NAT-gids verduidelik wat die Default Switch werklik is, en dit is die moeite werd om te lees voordat jy ’n tweede NAT-netwerk skep wat daarmee bots.