Gość Hyper-V traci DNS, gdy łączy się VPN hosta
Maszyna wirtualna gościa nie dziedziczy tunelu hosta. Ustal tryb przełącznika lub NAT, udostępnij adapter VPN tam, gdzie jest to oferowane, i przekieruj porty tam, gdzie nie jest.
Gość działał dobrze dziś rano. Wtedy host uruchomił Cisco AnyConnect i maszyna wirtualna straciła DNS, zaufanie domeny i folder udostępniony, choć w jej wnętrzu nic się nie zmieniło. Tunel hosta i sieć gościa to osobne ścieżki, a połączenie jednej nie przesuwa drugiej. Pracuj od wnętrza gościa na zewnątrz i zapisz, co widzisz, zanim cokolwiek zmienisz.
Co gość jeszcze widzi
Zapisz adres, bramę domyślną i resolver w maszynie wirtualnej, raz przed połączeniem hosta i raz po nim. Gość, który zachował adres i stracił tylko rozwiązywanie nazw, ma problem z resolverem. Gość, który nigdy nie miał trasy, ma problem ze ścieżką, a oba przypadki wymagają innej pracy. Z hosta nie da się ich odróżnić, dlatego odczyt musi pochodzić z wnętrza.
Te trzy odczyty, wzięte dwa razy, są twoją linią bazową. Wszystko późniejsze mierzy się względem nich.
Którego wyjścia używa gość
Hyper-V odpowiada na to dwiema poleceniami: Get-VMSwitch wylicza przełączniki, a Get-VMNetworkAdapter -VMName TestVM pokazuje ten, do którego podłączony jest gość. Default Switch to sieć NAT zarządzana przez Windows; przełącznik zewnętrzny przekazuje ruch do adaptera fizycznego; przełącznik wewnętrzny nic nie przenosi, dopóki ktoś nie doda NAT lub routera. VirtualBox przedstawia te same trzy idee jako NAT, NAT Network i bridged.
Tryb decyduje, czy tunel hosta może w ogóle mieć znaczenie. Gość NAT jest tłumaczony przez WinNAT, a następnie przekazywany przez stos hosta, więc podąża za tablicą routingu hosta; z klientem pełnego tunelu jego ruch to ruch wchodzący do adaptera VPN i jest odrzucany, gdy klient blokuje lokalną podsieć. Gość w trybie mostka na przełączniku zewnętrznym nigdy nie dociera do routingu hosta: jego ramki wychodzą bezpośrednio z fizycznej karty sieciowej, więc omija zarówno tunel, jak i politykę lokalnej sieci klienta.
Udostępnianie tunelu hosta przez Hyper-V
Jeśli gość potrzebuje tunelu i nie może uruchomić własnego klienta, Windows może udostępnić połączenie VPN. Otwórz właściwości adaptera VPN, przejdź do Udostępniania i zezwól innym użytkownikom sieci na łączenie się przez niego. Wskaż połączenie sieci domowej na adapter Hyper-V, vEthernet (Default Switch), a następnie przetestuj nowe żądanie z wnętrza gościa.
Traktuj ten układ jako rozwiązanie laboratoryjne, bo tak się zachowuje. Trzeba je stosować ponownie po rozłączeniu, ponownym połączeniu lub restarcie hosta. W niektórych kompilacjach Windows 11 adapter w ogóle nie występuje na liście rozwijanej, a wtedy ta droga jest zamknięta.
Ponowna instalacja funkcji Hyper-V uratowała kilka upartych gości. Zostaw to na koniec i najpierw zanotuj stan gościa.
Przekierowywanie portów, gdy podsieć jest filtrowana
VPN hosta, który filtruje podsieć NAT gościa, psuje dostęp bezpośredni, a nie rozwiązywanie nazw. Maszyna działa, a jednak ssh [email protected] zawiesza się, podczas gdy tłumaczenie hiperwizora wciąż działa. Przekieruj porty potrzebne do pracy i połącz się zamiast tego z adresem hosta. Poniższe wiersze Vagrantfile obejmują SSH i jedną usługę HTTPS; oba wpisy dodaje się przed przeładowaniem.
config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443Rozwiązywanie nazw to osobna decyzja i zasługuje na własną poprawkę. Włącz funkcję resolvera hosta dla tego adaptera NAT, albo skonfiguruj wewnętrzny serwer DNS wewnątrz gościa ręcznie. Wskazanie gościa na publiczny resolver sprawia, że przeglądanie działa, i psuje każdą nazwę wewnętrzną, co jest gorsze od awarii, bo wygląda jak sukces. Przetestuj nazwę, którą zna tylko wewnętrzny resolver.
Sprawdzenie, które mówi, że zadziałało
Po którejkolwiek z tych zmian uruchom nowe żądanie z wnętrza gościa przy połączonym VPN hosta, a nie przedtem. Sprawdź ponownie udostępnianie po ponownym połączeniu i po restarcie, bo poprawka, która przetrwa tylko jedno z nich, nie jest poprawką. Potwierdź, że lista resolverów gościa odpowiada sieci, której jego ruch naprawdę używa. Następnie przetestuj przekierowanie portów z adresu hosta, bo testowanie go z gościa niczego nie dowodzi. Z wnętrza gościa dwie kontrole PowerShell obejmują resolver i przekierowany port:
Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22Zapisz każdą zmianę przełącznika lub sterownika wraz z krokiem jej cofnięcia. Przewodnik Microsoftu dotyczący Hyper-V NAT wyjaśnia, czym naprawdę jest Default Switch, i warto go przeczytać przed utworzeniem drugiej sieci NAT, która z nim koliduje.