VMware-bridge-gast verloor zijn netwerk na OpenVPN

Een gast die een uur geleden nog gebrugd en bereikbaar was, krijgt nu op alles een time-out, en niemand heeft zijn instellingen aangepast. Op de host werkt het internet nog steeds via de tunnel. Beide feiten samen wijzen weg van de VPN en richting de hypervisor, omdat host en gast niet langer hetzelfde pad gebruiken. Eén nieuwe virtuele adapter is genoeg om het te veroorzaken.

De gast veranderde niet, de bridge wel

Het installeren van de OpenVPN-client op Windows voegt een virtuele netwerkadapter toe waaraan de dienst zich bindt wanneer een tunnel opkomt. Voor het besturingssysteem ziet die eruit als een gewone interface met een linkstatus en vaak met eigen adressen. Dat is genoeg voor VMware om hem als bridge-kandidaat te behandelen.

VMnet0 staat standaard op Automatisch, wat betekent dat de hypervisor elke keer dat hij een bridge legt een hostadapter kiest. Een vers geïnstalleerde virtuele adapter komt in die pool, en als die wordt gekozen, gaat elk frame dat de gast uitzendt naar een tunnelapparaat in plaats van naar de fysieke switchpoort.

Zet de bridge vast of routeer de gast

De eerste tak is de juiste wanneer de gast een gelijkwaardige deelnemer op het fysieke LAN moet zijn: stop met de bridge laten kiezen, en benoem de adapter expliciet. De tweede tak geldt wanneer de gast de bedrijfstunnel moet gebruiken, en in dat geval was een bridge nooit het juiste ontwerp, omdat een gebrugde gast de VPN-route van de host niet erft.

Beslis dat eerst, want de twee antwoorden leiden tot ander werk. De volgorde omdraaien levert een correct vastgezette bridge op die aan een gast hangt die nooit gebrugd had mogen worden.

Open voor de eerste tak de Virtual Network Editor op de host, selecteer VMnet0 en vervang Automatisch door de fysieke adapter. Als er meerdere adapters zijn, gebruik dan de lijst met automatische instellingen en verwijder het vinkje bij alles wat nooit gastverkeer mag dragen: het OpenVPN TAP- of Wintun-apparaat, plus Hyper-V-, WSL-, Docker- en loopback-adapters. Laat op een laptop zowel de bekabelde als de draadloze fysieke adapter aangevinkt, anders verliest de gast zijn bridge de volgende keer dat de gebruiker hem dockt.

Drie voorwaarden die de keuze beslechten

Of een bridge eigenlijk passend is, hangt ervan af waarvoor de gast dient. Als de gast als een eigen host op het LAN moet verschijnen, met een eigen adres en eigen inkomende bereikbaarheid, dan is de bridge het juiste model en is vastzetten de hele oplossing. Als de gast alleen uitgaande toegang nodig heeft, is een host-only- of NAT-netwerk eenvoudiger en immuun voor adapterwisselingen.

Als de gast dezelfde tunnel als de host moet gebruiken, helpt noch de bridgemodus noch een vastgezette adapter, omdat het verkeer van de gast nooit in de routeringsbeslissing van de host terechtkomt. Dat geval vereist een gerouteerd of vertaald pad op de host, en de keuze van adapter wordt irrelevant.

VMware Player heeft geen netwerkeditor in zijn interface, dus een host die alleen Player draait heeft de zelfstandige editor of een Workstation-installatie nodig om deze instellingen te bereiken. Die beperking bepaalt soms op zichzelf de aanpak.

Lees het resultaat vanuit de gast

Start de virtuele NIC opnieuw, of herstart de gast, zodat hij weer een lease aanvraagt. Lees dan wat hij werkelijk heeft ontvangen, in plaats van wat de host denkt te hebben geconfigureerd.

ipconfig /all
ip addr
ip route

Lees twee velden in die uitvoer en negeer de rest voorlopig. De gateway hoort de LAN-router te zijn, en de adapterbeschrijving hoort het VMware Ethernet-apparaat te noemen in plaats van een tunnel. Een zelf toegewezen adres in 169.254.0.0/16 betekent dat geen DHCP-server heeft geantwoord, en zo ziet een bridge naar een tunneladapter er vanaf de gastzijde uit.

Nog één onderscheid is de moeite waard voordat je iets anders verandert. Een gast die de router bereikt maar niet het internet heeft een werkende bridge en een probleem stroomopwaarts. Een gast die een adres in het tunnelbereik ontvangt, hangt nog aan het verkeerde apparaat. De TAP-adapter uitschakelen is voor geen van beide gevallen een oplossing, omdat de OpenVPN-dienst hem nodig heeft.