Hyper-V NAT koliduje z siecią lokalną

Hyper-V NAT koliduje z siecią lokalną wskazuje na nakładającą się adresację między wirtualną siecią NAT Hyper-V a fizyczną siecią domową — wymaga zmiany zakresu podsieci wirtualnej.

Czym jest konflikt Hyper-V NAT z siecią lokalną

Hyper-V NAT koliduje z siecią lokalną wtedy, gdy prywatna sieć utworzona dla maszyn wirtualnych korzysta z zakresu adresów nakładającego się na adresację używaną przez fizyczną sieć domową lub biurową. W takiej sytuacji system Windows może mieć trudność z rozróżnieniem, czy dany pakiet powinien zostać skierowany do urządzenia znajdującego się w sieci lokalnej, do wirtualnej maszyny, czy do bramy zapewniającej dostęp do internetu. Problem nie musi oznaczać uszkodzenia Hyper-V. Częściej wynika z nieprawidłowego projektu podsieci, istniejącego wcześniej zakresu VPN albo automatycznie dobranej konfiguracji wirtualnego przełącznika.

W typowym układzie NAT urządzenia działające wewnątrz wirtualnej sieci otrzymują prywatne adresy, a ruch wychodzący jest tłumaczony na adres komputera gospodarza. Dzięki temu maszyny wirtualne mogą korzystać z połączenia zewnętrznego bez bezpośredniego wystawiania ich adresów w sieci fizycznej. Jeżeli jednak wirtualny zakres jest taki sam lub częściowo pokrywa się z zakresem routera, tunelu VPN albo innego interfejsu, tablice routingu zaczynają prowadzić ruch w niewłaściwą stronę. Objawem może być brak dostępu do wybranych urządzeń, niedostępność zasobów udostępnionych w sieci albo niestabilne działanie po ponownym uruchomieniu systemu.

Kontekst techniczny i porównanie sposobów połączenia - Hyper-V NAT koliduje z siecią lokalną

W Hyper-V można spotkać kilka odmiennych sposobów podłączania maszyn wirtualnych do sieci. Wewnętrzny przełącznik pozwala na komunikację między hostem a maszynami wirtualnymi, a przy zastosowaniu NAT może również zapewnić wyjście do internetu. Zewnętrzny przełącznik łączy środowisko wirtualne z fizycznym interfejsem sieciowym i pozwala urządzeniom pojawiać się w tej samej sieci co komputer gospodarza. Przełącznik prywatny ogranicza natomiast komunikację do samych maszyn wirtualnych. Każdy wariant ma inne wymagania dotyczące adresacji, bramy i routingu.

Konflikt NAT jest szczególnie łatwy do przeoczenia, ponieważ dostęp do internetu może działać, mimo że komunikacja z lokalnymi urządzeniami zostaje zaburzona. Tłumaczenie adresów ukrywa część ruchu przed siecią fizyczną, lecz nie rozwiązuje problemu błędnie wybranego zakresu. Jeśli podsieć wirtualna pokrywa się z podsiecią używaną przez router, komputer może uznać, że urządzenie docelowe znajduje się lokalnie po stronie niewłaściwego interfejsu. Podobne skutki mogą powodować aktywne profile VPN, dodatkowe karty wirtualne, oprogramowanie do kontenerów oraz pozostałe mechanizmy tworzące prywatne zakresy adresowe.

Przy analizie nie powinno się ograniczać do samego adresu IP maszyny wirtualnej. Znaczenie mają również maska podsieci, adres bramy, trasa domyślna, trasy bardziej szczegółowe, kolejność interfejsów oraz reguły zapory. Warto porównać konfigurację hosta z konfiguracją routera i sprawdzić, czy wybrany zakres nie występuje już na innym połączeniu. Samo przełączenie karty sieciowej albo ponowne uruchomienie usługi może chwilowo zmienić objawy, ale nie usuwa przyczyny związanej z nakładaniem się adresacji.

Typowe problemy i błędy konfiguracyjne - Hyper-V NAT koliduje z siecią lokalną

Jednym z najczęstszych błędów jest użycie tej samej podsieci po stronie NAT i po stronie fizycznego routera. W efekcie host oraz maszyny wirtualne mogą mieć pozornie poprawne adresy, lecz pakiety do wybranych zasobów będą kierowane niezgodnie z oczekiwaniem. Przykładowo, internet może być dostępny, podczas gdy nie można otworzyć panelu routera, połączyć się z udziałem sieciowym albo uzyskać odpowiedzi od urządzenia znajdującego się w lokalnej podsieci.

Innym problemem jest pozostawienie kilku konkurujących mechanizmów udostępniania połączenia. Ręcznie zdefiniowany NAT, udostępnianie połączenia internetowego oraz dodatkowe oprogramowanie sieciowe mogą tworzyć odmienne bramy i zakresy DHCP. Wtedy konfiguracja maszyny wirtualnej może wyglądać poprawnie, ale odpowiedzi wracają inną drogą albo są blokowane przez reguły filtrowania. Kłopoty mogą pojawić się także po zmianie routera, przejściu z sieci przewodowej na bezprzewodową, podłączeniu firmowego VPN lub przywróceniu starszych ustawień wirtualnego przełącznika.

Do charakterystycznych objawów należą: brak dostępu do hosta z maszyny wirtualnej, brak dostępu z hosta do usługi uruchomionej w maszynie, niemożność połączenia z urządzeniami w tej samej sieci, losowe rozłączanie, błędne rozwiązywanie nazw oraz różnica między działaniem połączeń przez adres IP i przez nazwę. W niektórych przypadkach działa tylko ruch wychodzący, natomiast połączenia inicjowane z sieci lokalnej nie docierają do środowiska wirtualnego z powodu translacji adresów i zapory.

Diagnostyka powinna obejmować odczyt adresów wszystkich aktywnych interfejsów, sprawdzenie tras oraz testy wykonywane z kilku miejsc: z hosta, z maszyny wirtualnej i z urządzenia w sieci fizycznej. Przydatne jest ustalenie, gdzie kończy się komunikacja — przed bramą, za bramą, na etapie rozwiązywania nazw czy dopiero przy konkretnym porcie usługi. Zmiana zakresu prywatnej podsieci może usunąć konflikt, ale po takiej zmianie trzeba również uwzględnić adres bramy, reguły zapory, konfigurację usług i ewentualne statyczne wpisy w systemach gości.

Kiedy trzeba skorzystać z pomocy serwisu - Hyper-V NAT koliduje z siecią lokalną

Do serwisu warto zgłosić problem, gdy połączenie z internetem działa tylko częściowo, dostęp do zasobów lokalnych zmienia się po uruchomieniu środowiska wirtualnego albo kilka interfejsów sieciowych zaczyna konkurować o tę samą trasę. Pomoc jest szczególnie wskazana wtedy, gdy konfiguracja obejmuje równocześnie VPN, dodatkowe karty wirtualne, usługi dostępne z sieci lokalnej oraz reguły zapory, a samodzielne zmiany powodują kolejne, trudne do odtworzenia objawy.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić uporządkowanie konfiguracji sieciowej komputera, sprawdzenie zależności między interfejsami oraz ustalenie, czy przyczyną jest konflikt adresacji, routing, zapora czy nieprawidłowo działająca usługa. Przed zmianami warto przygotować opis objawów, informację o tym, które urządzenia są niedostępne, oraz wskazać, czy problem pojawia się wyłącznie po uruchomieniu maszyny wirtualnej. Takie dane ułatwiają odtworzenie sytuacji i ograniczają ryzyko przypadkowej zmiany ustawień niezwiązanych z usterką.