VMware-gjest i bro mistet nettverket etter OpenVPN

En gjest som for en time siden var broet og tilgjengelig, får nå tidsavbrudd på alt, og ingen har redigert innstillingene dens. På verten fungerer internett fortsatt gjennom tunnelen. De to fakta peker sammen bort fra VPN-en og mot hypervisoren, fordi verten og gjesten ikke lenger bruker samme vei. Én ny virtuell adapter er nok til å forårsake det.

Gjesten endret seg ikke, broen gjorde det

Installasjon av OpenVPN-klienten på Windows legger til en virtuell nettverksadapter som tjenesten binder seg til når en tunnel kommer opp. For operativsystemet ser den ut som et vanlig grensesnitt med en koblingstilstand og ofte egne adresser. Det er nok for at VMware skal behandle den som en brokandidat.

VMnet0 er som standard satt til Automatisk, noe som betyr at hypervisoren velger en vertsadapter hver gang den broer. En nyinstallert virtuell adapter kommer inn i den gruppen, og hvis den velges, går hver ramme gjesten sender til en tunnel-enhet i stedet for til den fysiske svitsjporten.

Fest broen eller rute gjesten

Den første grenen er den riktige når gjesten skal være en likeverdig deltaker på det fysiske LAN-et: slutt å la broen velge, og navngi adapteren eksplisitt. Den andre grenen gjelder når gjesten skal bruke bedriftstunnelen, og i så fall var en bro aldri riktig design, fordi en broet gjest arver ikke vertens VPN-rute.

Bestem det først, fordi de to svarene fører til forskjellig arbeid. Snu rekkefølgen gir en korrekt festet bro koblet til en gjest som aldri burde vært broet.

For den første grenen åpner du Virtual Network Editor på verten, velger VMnet0 og erstatter Automatisk med den fysiske adapteren. Hvis det finnes flere adaptere, bruk listen med automatiske innstillinger og fjern merket for alt som aldri skal bære gjestetrafikk: OpenVPN TAP- eller Wintun-enheten, samt Hyper-V-, WSL-, Docker- og loopback-adaptere. La både den kablede og den trådløse fysiske adapteren være merket på en bærbar PC, ellers mister gjesten broen neste gang brukeren dokker den.

Tre betingelser som avgjør valget

Om en bro i det hele tatt passer, avhenger av hva gjesten er til. Hvis gjesten skal fremstå som sin egen vert på LAN-et, med egen adresse og egen innkommende tilgjengelighet, er broen riktig modell, og festingen er hele rettelsen. Hvis gjesten bare trenger utgående tilgang, er et vertsbare- eller NAT-nettverk enklere og immun mot adapterbytter.

Hvis gjesten skal bruke samme tunnel som verten, hjelper verken bro-modus eller en festet adapter, fordi gjestens trafikk aldri kommer inn i vertens rutingsbeslutning. Det tilfellet trenger en rutet eller oversatt vei på verten, og valget av adapter blir uten betydning.

VMware Player har ingen nettverkseditor i grensesnittet, så en vert som bare kjører Player trenger den frittstående editoren eller en Workstation-installasjon for å nå disse innstillingene. Den begrensningen avgjør noen ganger tilnærmingen helt alene.

Les resultatet inne fra gjesten

Start den virtuelle nettverksadapteren på nytt, eller start gjesten på nytt, slik at den ber om en ny lease. Les deretter hva den faktisk fikk, i stedet for hva verten tror den har konfigurert.

ipconfig /all
ip addr
ip route

Les to felt i den utskriften og ignorer resten foreløpig. Gatewayen skal være LAN-ruteren, og adapterbeskrivelsen skal navngi VMware Ethernet-enheten i stedet for en tunnel. En selvvalgt adresse i 169.254.0.0/16 betyr at ingen DHCP-server svarte, og det er slik en bro til en tunneladapter ser ut fra gjestens side.

Én forskjell til er verdt å gjøre før du endrer noe annet. En gjest som når ruteren men ikke internett, har en fungerende bro og et problem lenger oppe. En gjest som mottar en adresse i tunnelområdet, er fortsatt koblet til feil enhet. Å deaktivere TAP-adapteren er ikke en løsning for noen av de to tilfellene, fordi OpenVPN-tjenesten trenger den.