VMware-bryggad gäst förlorade nätverket efter OpenVPN

En gäst som för en timme sedan var bryggad och nåbar får nu timeout på allt, och ingen har redigerat dess inställningar. På värden fungerar internet fortfarande genom tunneln. De två fakta pekar tillsammans bort från VPN:en och mot hypervisorn, eftersom värden och gästen inte längre använder samma väg. En enda ny virtuell adapter räcker för att orsaka det.

Gästen ändrades inte, bryggan gjorde det

När OpenVPN-klienten installeras på Windows läggs en virtuell nätverksadapter till, som tjänsten binder sig till när en tunnel kommer upp. För operativsystemet ser den ut som ett vanligt gränssnitt med länkstatus och ofta egna adresser. Det räcker för att VMware ska behandla den som en bryggkandidat.

VMnet0 är som standard inställt på Automatiskt, vilket betyder att hypervisorn väljer en värdadapter varje gång den bryggar. En nyinstallerad virtuell adapter hamnar i den poolen, och om den väljs går varje ram gästen skickar till en tunnelenhet i stället för till den fysiska switchporten.

Fäst bryggan eller routa gästen

Den första grenen är den rätta när gästen ska vara en jämlik deltagare på det fysiska LAN:et: sluta låta bryggan välja, och namnge adaptern uttryckligen. Den andra grenen gäller när gästen ska använda företagstunneln, och då var en brygga aldrig rätt design, eftersom en bryggad gäst inte ärver värdens VPN-rutt.

Bestäm det först, eftersom de två svaren leder till olika arbete. Att vända på ordningen ger en korrekt fäst brygga kopplad till en gäst som aldrig borde ha bryggats.

För den första grenen öppnar du Virtual Network Editor på värden, väljer VMnet0 och ersätter Automatiskt med den fysiska adaptern. Om det finns flera adaptrar använder du listan med automatiska inställningar och tar bort bocken för allt som aldrig får bära gästtrafik: OpenVPN TAP- eller Wintun-enheten, plus Hyper-V-, WSL-, Docker- och loopback-adaptrar. Låt både den trådbundna och den trådlösa fysiska adaptern vara ikryssade på en laptop, annars tappar gästen sin brygga nästa gång användaren dockar den.

Tre villkor som avgör valet

Om en brygga ens är lämplig beror på vad gästen är till för. Om gästen ska framträda som sin egen värd på LAN:et, med egen adress och egen inkommande nåbarhet, är bryggan rätt modell och fästningen är hela åtgärden. Om gästen bara behöver utgående åtkomst är ett värdbegränsat eller NAT-nätverk enklare och immunt mot adapterbyten.

Om gästen måste använda samma tunnel som värden, hjälper varken bryggläget eller en fäst adapter, eftersom gästens trafik aldrig kommer in i värdens routningsbeslut. Det fallet kräver en routad eller översatt väg på värden, och valet av adapter blir betydelselöst.

VMware Player har ingen nätverksredigerare i sitt gränssnitt, så en värd som bara kör Player behöver den fristående redigeraren eller en Workstation-installation för att nå dessa inställningar. Den begränsningen avgör ibland angreppssättet på egen hand.

Läs resultatet inifrån gästen

Starta om den virtuella nätverksadaptern, eller starta om gästen, så att den begär en ny lease. Läs sedan vad den faktiskt fick, i stället för vad värden tror sig ha konfigurerat.

ipconfig /all
ip addr
ip route

Läs två fält i den utskriften och ignorera resten tills vidare. Gatewayen bör vara LAN-routern, och adapterbeskrivningen bör namnge VMware Ethernet-enheten i stället för en tunnel. En självtilldelad adress i 169.254.0.0/16 betyder att ingen DHCP-server svarade, och det är precis så en brygga mot en tunneladapter ser ut från gästens sida.

En skillnad till är värd att göra innan du ändrar något annat. En gäst som når routern men inte internet har en fungerande brygga och ett problem uppströms. En gäst som får en adress i tunnelområdet sitter fortfarande på fel enhet. Att inaktivera TAP-adaptern löser inget av de två fallen, eftersom OpenVPN-tjänsten behöver den.