Gość w trybie mostu VMware stracił sieć po OpenVPN

Gość, który godzinę temu był w trybie mostu i był osiągalny, teraz przekracza limit czasu na wszystkim, a nikt nie edytował jego ustawień. Na hoście internet nadal działa przez tunel. Oba fakty razem wskazują z dala od VPN i w stronę hipervisora, ponieważ host i gość nie używają już tej samej ścieżki. Wystarczy jeden nowy wirtualny adapter, aby to wywołać.

Gość się nie zmienił, zmienił się most

Instalacja klienta OpenVPN w systemie Windows dodaje wirtualny adapter sieciowy, do którego usługa wiąże się, gdy tunel się podnosi. Dla systemu operacyjnego wygląda on jak zwykły interfejs ze stanem łącza i często własnymi adresami. To wystarcza, aby VMware traktował go jako kandydata do mostu.

VMnet0 jest domyślnie ustawiony na Automatyczny, co oznacza, że hipervisor wybiera adapter hosta za każdym razem, gdy tworzy most. Świeżo zainstalowany wirtualny adapter wchodzi do tej puli, a jeśli zostanie wybrany, każda ramka wysyłana przez gościa trafia do urządzenia tunelowego zamiast do fizycznego portu przełącznika.

Przypnij most albo trasuj gościa

Pierwsza gałąź jest właściwa, gdy gość ma być równorzędnym uczestnikiem fizycznej sieci LAN: przestań pozwalać mostowi wybierać i nazwij adapter wprost. Druga gałąź dotyczy sytuacji, gdy gość ma korzystać z tunelu firmowego, a wtedy most nigdy nie był właściwym projektem, ponieważ gość w trybie mostu nie dziedziczy trasy VPN hosta.

Zdecyduj to najpierw, ponieważ obie odpowiedzi prowadzą do innej pracy. Odwrócenie kolejności daje poprawnie przypięty most podłączony do gościa, którego nigdy nie należało mostkować.

W pierwszej gałęzi otwórz Virtual Network Editor na hoście, wybierz VMnet0 i zastąp Automatyczny fizycznym adapterem. Jeśli adapterów jest kilka, użyj listy ustawień automatycznych i odznacz wszystko, co nigdy nie powinno przenosić ruchu gościa: urządzenie OpenVPN TAP lub Wintun oraz adaptery Hyper-V, WSL, Docker i loopback. Na laptopie pozostaw zaznaczone zarówno przewodowe, jak i bezprzewodowe fizyczne adaptery, inaczej gość straci most przy następnym zadokowaniu.

Trzy warunki, które rozstrzygają wybór

To, czy most jest w ogóle właściwy, zależy od przeznaczenia gościa. Jeśli gość ma się pojawiać jako osobny host w sieci LAN, z własnym adresem i własną osiągalnością przychodzącą, most jest właściwym modelem, a przypięcie to cała naprawa. Jeśli gość potrzebuje tylko dostępu wychodzącego, sieć tylko dla hosta lub NAT jest prostsza i odporna na zmiany adapterów.

Jeśli gość ma korzystać z tego samego tunelu co host, nie pomaga ani tryb mostu, ani przypięty adapter, ponieważ ruch gościa nigdy nie trafia do decyzji hosta o trasowaniu. Ten przypadek wymaga na hoście ścieżki trasowanej lub tłumaczonej, a wybór adaptera staje się nieistotny.

VMware Player nie ma edytora sieci w swoim interfejsie, więc host z samym Playerem potrzebuje edytora samodzielnego lub instalacji Workstation, aby dotrzeć do tych ustawień. To ograniczenie czasem samo decyduje o podejściu.

Odczytaj wynik od środka gościa

Zrestartuj wirtualną kartę sieciową lub zrestartuj gościa, aby ponownie poprosił o dzierżawę. Następnie odczytaj, co faktycznie otrzymał, a nie to, co host uważa, że skonfigurował.

ipconfig /all
ip addr
ip route

Odczytaj dwa pola w tym wyniku, a resztę na razie pomiń. Brama powinna być routerem sieci LAN, a opis adaptera powinien wskazywać urządzenie VMware Ethernet, a nie tunel. Samodzielnie przypisany adres w 169.254.0.0/16 oznacza, że żaden serwer DHCP nie odpowiedział, i właśnie tak wygląda most na adapter tunelowy od strony gościa.

Jeszcze jedno rozróżnienie jest warte zrobienia, zanim zmienisz cokolwiek innego. Gość, który dociera do routera, ale nie do internetu, ma działający most i problem wyżej. Gość, który otrzymuje adres z zakresu tunelu, nadal jest podłączony do niewłaściwego urządzenia. Wyłączenie adaptera TAP nie jest rozwiązaniem żadnego z tych przypadków, ponieważ usługa OpenVPN go potrzebuje.