VMware-broet gæst mistede sit netværk efter OpenVPN

En gæst, der for en time siden var broet og kunne nås, får nu timeout på alt, og ingen har redigeret dens indstillinger. På værten virker internettet stadig gennem tunnelen. De to fakta peger tilsammen væk fra VPN'en og mod hypervisoren, fordi værten og gæsten ikke længere bruger samme vej. Én ny virtuel adapter er nok til at forårsage det.

Gæsten ændrede sig ikke, broen gjorde

Installation af OpenVPN-klienten på Windows tilføjer en virtuel netværksadapter, som tjenesten binder til, når en tunnel kommer op. For styresystemet ser den ud som en almindelig grænseflade med en linktilstand og ofte sine egne adresser. Det er nok til, at VMware behandler den som en brokandidat.

VMnet0 er som standard sat til Automatisk, hvilket betyder, at hypervisoren vælger en værtsadapter, hver gang den broer. En nyinstalleret virtuel adapter kommer med i den pulje, og hvis den vælges, går hver ramme, gæsten sender, til en tunnel-enhed i stedet for til den fysiske switch-port.

Fastgør broen eller route gæsten

Den første gren er den rigtige, når gæsten skal være en ligeværdig deltager på det fysiske LAN: stop med at lade broen vælge, og navngiv adapteren eksplicit. Den anden gren gælder, når gæsten skal bruge den virksomhedstunnel, og i så fald var en bro aldrig det rigtige design, fordi en broet gæst ikke arver værtens VPN-rute.

Beslut det først, fordi de to svar fører til forskelligt arbejde. Bytter man rækkefølgen, får man en korrekt fastgjort bro, der er knyttet til en gæst, som aldrig burde have været broet.

Til den første gren åbner du Virtual Network Editor på værten, vælger VMnet0 og erstatter Automatisk med den fysiske adapter. Hvis der findes flere adaptere, brug listen med automatiske indstillinger, og fjern markeringen for alt, der aldrig må bære gæstetrafik: OpenVPN TAP- eller Wintun-enheden samt Hyper-V-, WSL-, Docker- og loopback-adaptere. Behold både den kablede og den trådløse fysiske adapter markeret på en bærbar computer, ellers mister gæsten sin bro, næste gang brugeren sætter den i dockingen.

Tre betingelser, der afgør valget

Om en bro overhovedet er passende, afhænger af, hvad gæsten er til. Hvis gæsten skal fremstå som sin egen vært på LAN'et med sin egen adresse og sin egen indgående tilgængelighed, er broen den rigtige model, og fastgørelsen er hele rettelsen. Hvis gæsten kun har brug for udgående adgang, er et værtskun- eller NAT-netværk enklere og immun over for udskiftning af adaptere.

Hvis gæsten skal bruge samme tunnel som værten, hjælper hverken broet tilstand eller en fastgjort adapter, fordi gæstens trafik aldrig kommer ind i værtens routingbeslutning. Det tilfælde kræver en routet eller oversat vej på værten, og valget af adapter bliver uden betydning.

VMware Player har ingen netværkseditor i sin grænseflade, så en vært, der kun kører Player, har brug for den separate editor eller en Workstation-installation for at nå disse indstillinger. Den begrænsning afgør nogle gange tilgangen helt alene.

Læs resultatet inde fra gæsten

Genstart den virtuelle netværksadapter, eller genstart gæsten, så den anmoder om en ny lease. Læs derefter, hvad den faktisk modtog, i stedet for hvad værten tror, den har konfigureret.

ipconfig /all
ip addr
ip route

Læs to felter i det output og ignorér resten for nu. Gatewayen bør være LAN-routeren, og adapterbeskrivelsen bør angive VMware Ethernet-enheden i stedet for en tunnel. En selvvalgt adresse i 169.254.0.0/16 betyder, at ingen DHCP-server svarede, og det er sådan en bro til en tunneladapter ser ud fra gæstens side.

Én forskel mere er værd at nævne, før du ændrer noget andet. En gæst, der når routeren men ikke internettet, har en fungerende bro og et problem længere oppe. En gæst, der modtager en adresse i tunnelområdet, er stadig knyttet til den forkerte enhed. Deaktivering af TAP-adapteren er ikke en løsning på nogen af de to tilfælde, fordi OpenVPN-tjenesten har brug for den.