VMware-brêgegast ferlear nei OpenVPN syn netwurk

In gast dy't in oere lyn noch oerbrêge en berikber wie, krijt no by alles in time-out, en nimmen hat syn ynstellings bewurke. Op de host wurket it ynternet noch troch de tunnel. Dy twa feiten tegearre wize fuort fan de VPN en nei de hypervisor, om't de host en de gast net mear deselde paad brûke. Ien nije firtuele adapter is genôch om it te feroarsaakjen.

De gast feroare net, de brêge wol

It ynstallearjen fan de OpenVPN-klant op Windows foeget in firtuele netwurkadapter ta dêr't de tsjinst oan bynt as in tunnel omheech komt. Foar it bestjoeringssysteem liket it op in gewoane ynterfaasje mei in linkstatus en, faak, syn eigen adressen. Dat is genôch foar VMware om it as brêgekandidaat te behanneljen.

VMnet0 stiet standert op Automatysk, wat betsjut dat de hypervisor by elk oerbrêgjen in hostadapter kiest. In nij ynstallearre firtuele adapter komt yn dat poel, en as dy keazen wurdt, giet elk frame dat de gast útstjoert nei in tunnelapparaat ynstee fan nei de fysike switchpoarte.

Fêstset de brêge of routearje de gast

De earste tûke is de juste as de gast in lykweardige partner op de fysike LAN wêze moat: stop mei de brêge kieze te litten, en neam de adapter eksplisyt. De twadde tûke jildt as de gast de bedriuwstunnel brûke moat, en yn dat gefal wie in brêge nea it juste ûntwerp, om't in oerbrêge gast de VPN-rûte fan de host net erft.

Beslis dat earst, om't de twa antwurden nei oar wurk liede. De folchoarder omdraaie leveret in korrekt fêstsette brêge op dy't oan in gast fêstsit dy't nea oerbrêge wurde moatten hie.

Foar de earste tûke iepenje jo de Firtuele Netwurk-editor op de host, selektearje VMnet0 en ferfange Automatysk troch de fysike adapter. As der ferskate adapters binne, brûk de list mei automatyske ynstellings en helje it fekje fuort by alles dat nea gastferkear drage mei: it OpenVPN TAP- of Wintun-apparaat, plus Hyper-V-, WSL-, Docker- en loopback-adapter. Hâld op in laptop sawol de betrape as de draadleaze fysike adapter oanfinke, oars ferliest de gast syn brêge de folgjende kear as de brûker dokket.

Trije betingsten dy't de kar beslis

Oft in brêge wol past, hinget derfan ôf wêr't de gast foar is. As de gast as syn eigen host op de LAN ferskine moat, mei syn eigen adres en syn eigen ynkommende berikberens, is oerbrêgjen it juste model en is fêstsetten de hiele oplossing. As de gast allinnich útgeande tagong nedich hat, is in host-only- of NAT-netwurk ienfâldiger en ûnfêstber foar adapterferoaringen.

As de gast deselde tunnel as de host brûke moat, helpt noch de oerbrêge modus noch in fêstsette adapter, om't it ferkear fan de gast nea yn de routingbeslissing fan de host komt. Dat gefal hat in routearre of oerset paad op de host nedich, en de kar fan adapter wurdt ûnbelangryk.

VMware Player hat gjin netwurkeditor yn syn ynterfaasje, dus in host dy't allinnich Player hat, hat de selsstannige editor of in Workstation-ynstallaasje nedich om by dizze ynstellings te kommen. Dy beheining beslist soms op himsels de oanpak.

Lês it resultaat fan binnen de gast

Start de firtuele NIC opnij, of start de gast opnij, sadat er wer in lease oanfreget. Lês dan wat er echt krige hat, ynstee fan wat de host tinkt dat er konfigurearre hat.

ipconfig /all
ip addr
ip route

Lês twa fjilden yn dy útfier en negearje de rest foarearst. De gateway heart de LAN-router te wêzen, en de adapterbeskriuwing heart it VMware Ethernet-apparaat te neamen ynstee fan in tunnel. In sels tawiisde adres yn 169.254.0.0/16 betsjut dat gjin DHCP-tsjinner antwurde, en dat is hoe't in brêge nei in tunneladapter fan de gastkant útsjocht.

Ien ferskil mear is de muoite wurdich foardat jo eat oars feroarje. In gast dy't de router berikt mar it ynternet net, hat in wurkjende brêge en in probleem streamop. In gast dy't in adres yn it tunnelberik krijt, sit noch oan it ferkearde apparaat. It útskeakeljen fan de TAP-adapter is net in oplossing foar ien fan beide gefallen, om't de OpenVPN-tsjinst it nedich hat.