Гост на Hyper-V губи DNS, когато VPN на хоста се свърже

Гостът беше добре тази сутрин. После хостът стартира Cisco AnyConnect и VM загуби DNS, доверието към домейна и споделената папка, без нищо вътре в нея да се е променило. Тунелът на хоста и мрежата на госта са отделни пътища и свързването на единия не мести другия. Работете отвътре на госта навън и запишете какво виждате, преди да промените нещо.

Какво гостът все още вижда

Запишете адреса, шлюза по подразбиране и резолвера във VM — веднъж преди хостът да се свърже и веднъж след това. Гост, който е запазил адреса си и е загубил само разрешаването на имена, има проблем с резолвера. Гост, който никога не е имал маршрут, има проблем с пътя, и двете изискват различна работа. От хоста не можете да ги различите, затова четенето трябва да идва отвътре.

Тези три показания, взети два пъти, са вашата базова линия. Всичко по-нататък се измерва спрямо тях.

Кой изход използва гостът

Hyper-V отговаря на това с две команди: Get-VMSwitch изброява суичовете, а Get-VMNetworkAdapter -VMName TestVM показва този, към който е прикачен гостът. Default Switch е NAT мрежа, управлявана от Windows; външният суич предава трафика на физически адаптер; вътрешният суич не носи нищо, докато някой не добави NAT или рутер. VirtualBox представя същите три идеи като NAT, NAT Network и bridged.

Режимът решава дали тунелът на хоста може изобщо да има значение. Гостът зад NAT се транслатира от WinNAT и след това се препраща от стека на хоста, така че следва маршрутната таблица на хоста; при клиент с пълен тунел неговият трафик е трафикът, който влиза във VPN адаптера, и се отхвърля, когато клиентът блокира локалната подмрежа. Гост с мост към външен суич никога не достига до маршрутизацията на хоста: кадрите му излизат директно от физическата мрежова карта, така че заобикаля и тунела, и политиката за локална мрежа на клиента.

Споделяне на тунела на хоста с Hyper-V

Ако гостът се нуждае от тунела и не може да стартира собствен клиент, Windows може да сподели VPN връзката. Отворете свойствата на VPN адаптера, отидете на Споделяне и разрешете на други мрежови потребители да се свързват през него. Насочете домашната мрежова връзка към адаптера на Hyper-V, vEthernet (Default Switch), след което тествайте нова заявка отвътре на госта.

Третирайте тази подредба като лабораторно решение, защото тя се държи точно така. Тя трябва да се прилага отново след прекъсване, повторно свързване или рестартиране на хоста. В някои сборки на Windows 11 адаптерът липсва напълно от падащия списък и тогава този път е затворен.

Преинсталирането на функцията Hyper-V е спасявало няколко упорити госта. Запазете това за накрая и първо отбележете състоянието на госта.

Пренасочване на портове, когато подмрежата е филтрирана

VPN на хоста, който филтрира NAT подмрежата на госта, чупи директния достъп, а не разрешаването на имена. VM работи, но ssh [email protected] виси, докато транслацията на хипервизора все още работи. Пренасочете портовете, от които работата се нуждае, и се свържете към адреса на хоста вместо това. Редовете във Vagrantfile по-долу покриват SSH и една HTTPS услуга; и двете се добавят преди презареждането.

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

Разрешаването на имена е отделно решение и заслужава собствено поправяне. Включете функцията за резолвер на хоста за този NAT адаптер, или конфигурирайте вътрешния DNS сървър вътре в госта ръчно. Насочването на госта към публичен резолвер прави сърфирането да работи и чупи всяко вътрешно име, което е по-лошо от прекъсването, защото изглежда като успех. Тествайте име, което знае само вътрешният резолвер.

Проверката, която показва, че е проработило

След някоя от тези промени стартирайте нова заявка отвътре на госта, докато VPN на хоста е свързан, а не преди това. Проверете отново споделянето след повторно свързване и след рестартиране, защото поправка, която издържа само на едното, не е поправка. Потвърдете, че списъкът с резолвери на госта съвпада с мрежата, която трафикът му наистина използва. След това тествайте пренасочването на портове от адреса на хоста, защото тестването от госта не доказва нищо. Отвътре на госта две проверки в PowerShell покриват резолвера и пренасочения порт:

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

Записвайте всяка промяна на суич или драйвер заедно със стъпката за отмяна. Наръчникът на Microsoft за Hyper-V NAT обяснява какво всъщност е Default Switch и си заслужава да се прочете, преди да създадете втора NAT мрежа, която му противоречи.