VMware-gjest i bru miste nettet etter OpenVPN

Ein gjest som for ein time sidan var brua og tilgjengeleg, får no tidsavbrot på alt, og ingen har endra innstillingane hans. På verten fungerer internett framleis gjennom tunnelen. Dei to fakta peikar saman bort frå VPN-en og mot hypervisoren, fordi verten og gjesten ikkje lenger brukar same veg. Éin ny virtuell adapter er nok til å valde det.

Gjesten endra seg ikkje, brua gjorde det

Installasjon av OpenVPN-klienten på Windows legg til ein virtuell nettverksadapter som tenesta bind seg til når ein tunnel kjem opp. For operativsystemet ser han ut som eit vanleg grensesnitt med ein koplingstilstand og ofte eigne adresser. Det er nok for at VMware skal handsame han som ein brukandidat.

VMnet0 er som standard sett til Automatisk, noko som betyr at hypervisoren vel ein vertsadapter kvar gong han bruar. Ein nyinstallert virtuell adapter kjem inn i den gruppa, og blir han vald, går kvar ramme gjesten sender til ei tunneleining i staden for til den fysiske svitsjporten.

Fest brua eller rute gjesten

Den første greina er den rette når gjesten skal vere ein likeverdig deltakar på det fysiske LAN-et: slutt å la brua velje, og nemn adapteren eksplisitt. Den andre greina gjeld når gjesten skal bruke bedriftstunnelen, og i så fall var ei bru aldri rett design, fordi ein brua gjest arvar ikkje VPN-ruta til verten.

Avgjer det først, fordi dei to svara fører til ulikt arbeid. Snur du rekkjefølgja, får du ei korrekt festa bru kopla til ein gjest som aldri burde vore brua.

For den første greina opnar du Virtual Network Editor på verten, vel VMnet0 og byter ut Automatisk med den fysiske adapteren. Finst det fleire adapterar, bruk lista med automatiske innstillingar og fjern merket for alt som aldri skal bera gjestetrafikk: OpenVPN TAP- eller Wintun-eininga, samt Hyper-V-, WSL-, Docker- og loopback-adapterar. La både den kabelbundne og den trådlause fysiske adapteren vere merkt på ein berbar PC, elles mistar gjesten brua neste gong brukaren dokkar han.

Tre vilkår som avgjer valet

Om ei bru i det heile passar, kjem an på kva gjesten er til. Skal gjesten framstå som sin eigen vert på LAN-et, med eiga adresse og eiga innkomande tilgjenge, er brua rett modell, og festinga er heile rettinga. Treng gjesten berre utgåande tilgang, er eit berre-vert-nettverk eller NAT-nettverk enklare og immunt mot adapterbytte.

Skal gjesten bruke same tunnel som verten, hjelper korkje bru-modus eller ein festa adapter, fordi trafikken til gjesten aldri kjem inn i rutingsavgjerda til verten. Det tilfellet treng ein ruta eller omsett veg på verten, og valet av adapter blir utan tyding.

VMware Player har ingen nettverkseditor i grensesnittet, så ein vert som berre køyrer Player treng den frittståande editoren eller ein Workstation-installasjon for å nå desse innstillingane. Den avgrensinga avgjer stundom tilnærminga heilt åleine.

Les resultatet inne frå gjesten

Start den virtuelle nettverksadapteren på nytt, eller start gjesten på nytt, slik at han ber om ein ny lease. Les deretter kva han faktisk fekk, i staden for kva verten trur han har konfigurert.

ipconfig /all
ip addr
ip route

Les to felt i den utskrifta og ignorer resten førebels. Gatewayen skal vere LAN-ruteren, og adapteromtalen skal nemne VMware Ethernet-eininga i staden for ein tunnel. Ei sjølvvald adresse i 169.254.0.0/16 betyr at ingen DHCP-tenar svara, og slik ser ei bru til ein tunneladapter ut frå gjestesida.

Ein skilnad til er verdt å gjere før du endrar noko anna. Ein gjest som når ruteren men ikkje internett, har ei fungerande bru og eit problem lenger oppe. Ein gjest som får ei adresse i tunnelområdet, heng framleis på feil eining. Å slå av TAP-adapteren er ikkje ei løysing for nokon av dei to tilfella, fordi OpenVPN-tenesta treng han.