VMware-gjest i bro mistet nettet etter OpenVPN

En gjest som for en time siden var broet og nåbar, får nå tidsavbrudd på alt, og ingen har endret innstillingene. På verten virker internett fortsatt gjennom tunnelen. De to fakta peker samlet 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 dette.

Gjesten forandret seg ikke, broen gjorde det

Installerer du OpenVPN-klienten på Windows, legges en virtuell nettverksadapter til, og tjenesten binder seg til den når en tunnel reises. For operativsystemet ser den ut som et vanlig grensesnitt med koblingstilstand og ofte egne adresser. Det holder for at VMware behandler den som kandidat for bro.

VMnet0 står som standard på Automatisk, altså velger hypervisoren en vertsadapter hver gang den broer. En fersk virtuell adapter blir med i dette utvalget, og blir den valgt, går hver ramme gjesten sender, til en tunnelenhet i stedet for til den fysiske svitsjporten.

Lås broen eller rute gjesten

Den første grenen er riktig når gjesten skal være en jevnbyrdig deltaker på det fysiske LAN-et: slutt å la broen velge, og navngi adapteren uttrykkelig. Den andre grenen gjelder når gjesten skal bruke bedriftstunnelen, og da var bro aldri riktig design, fordi en broet gjest arver ikke VPN-ruten til verten.

Avgjør det først, siden de to svarene fører til ulikt arbeid. Tar du rekkefølgen baklengs, får du en riktig låst bro festet til en gjest som aldri burde vært broet.

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

Tre vilkår som avgjør valget

Om bro i det hele tatt passer, avhenger av hva gjesten skal brukes til. Skal gjesten opptre som sin egen vert på LAN-et, med egen adresse og egen innkommende nåbarhet, er bro riktig modell, og låsing er hele rettelsen. Trenger gjesten bare utgående tilgang, er et vertsbegrenset eller NAT-basert nett enklere og immunt mot adapterbytter.

Skal gjesten bruke samme tunnel som verten, hjelper verken bromodus eller en låst adapter, fordi trafikken fra gjesten aldri kommer inn i rutingsavgjørelsen til verten. Det tilfellet krever 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 fremgangsmåten på egen hånd.

Les resultatet fra gjesten

Start den virtuelle nettverksadapteren på nytt, eller start gjesten på nytt, slik at den ber om 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 denne 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.

Det er verdt å gjøre én forskjell til før du endrer noe annet. En gjest som når ruteren, men ikke internett, har en virkende bro og et problem lenger opp. En gjest som mottar en adresse i tunnelområdet, henger fortsatt på feil enhet. Å slå av TAP-adapteren løser ingen av de to tilfellene, fordi OpenVPN-tjenesten trenger den.