Nawala ang network ng VMware bridged guest matapos ang OpenVPN

Ang guest na naka-bridge at naaabot isang oras ang nakalipas ay nag-time out na ngayon sa lahat, at walang nag-edit ng mga setting nito. Sa host, gumagana pa rin ang internet sa pamamagitan ng tunnel. Ang dalawang katotohanang magkasama ay tumuturo palayo sa VPN at patungo sa hypervisor, dahil hindi na gumagamit ng parehong landas ang host at guest. Sapat na ang isang bagong virtual adapter para maging sanhi nito.

Hindi nagbago ang guest, ang bridge ang nagbago

Ang pag-install ng OpenVPN client sa Windows ay nagdaragdag ng virtual network adapter na kinakabit ng serbisyo kapag tumaas ang tunnel. Para sa operating system, mukha itong ordinaryong interface na may link state at, kadalasan, may sariling mga address. Sapat na iyon para ituring ito ng VMware bilang kandidato sa bridge.

Ang VMnet0 ay nakatakda sa Automatic bilang default, na nangangahulugang pumipili ang hypervisor ng host adapter sa tuwing nagb-bridge ito. Ang bagong install na virtual adapter ay sumasama sa pool na iyon, at kung mapili ito, ang bawat frame na ipinapadala ng guest ay napupunta sa tunnel device sa halip na sa pisikal na port ng switch.

I-pin ang bridge o i-route ang guest

Ang unang sangay ang tama kapag ang guest ay dapat maging kapantay sa pisikal na LAN: itigil ang pagpapahintulot sa bridge na pumili, at pangalanan ang adapter nang tahasan. Nalalapat ang ikalawang sangay kapag ang guest ay dapat gumamit ng corporate tunnel, at sa ganoong kaso ang bridge ay hindi kailanman naging tamang disenyo, dahil ang naka-bridge na guest ay hindi nagmamana ng VPN route ng host.

Pagpasyahan iyon muna, dahil ang dalawang sagot ay humahantong sa magkaibang gawain. Ang baligtad na pagkakasunod-sunod ay gumagawa ng wastong naka-pin na bridge na nakakabit sa guest na hindi dapat na-bridge kailanman.

Para sa unang sangay, buksan ang Virtual Network Editor sa host, piliin ang VMnet0 at palitan ang Automatic ng pisikal na adapter. Kung may maraming adapter, gamitin ang listahan ng automatic settings at alisin ang tsek sa anumang hindi dapat kailanman magdala ng trapiko ng guest: ang OpenVPN TAP o Wintun device, kasama ang Hyper-V, WSL, Docker at loopback adapter. Panatilihing naka-tsek ang parehong wired at wireless na pisikal na adapter sa laptop, o mawawala ng guest ang bridge nito sa susunod na i-dock ito ng user.

Tatlong kondisyon na nagpapasya sa pagpili

Kung angkop ba ang bridge ay depende sa gamit ng guest. Kung ang guest ay dapat lumitaw bilang sariling host sa LAN, may sariling address at sariling inbound reachability, ang bridge ang tamang modelo at ang pag-pin ang buong pagtatama. Kung kailangan lang ng guest ng outbound access, ang host-only o NAT network ay mas simple at hindi apektado ng pagbabago ng adapter.

Kung ang guest ay dapat gumamit ng parehong tunnel ng host, walang tumutulong sa bridged mode o naka-pin na adapter, dahil ang trapiko ng guest ay hindi kailanman pumapasok sa routing decision ng host. Ang kasong iyon ay nangangailangan ng routed o translated na landas sa host, at ang pagpili ng adapter ay nagiging walang kaugnayan.

Walang network editor sa interface ng VMware Player, kaya ang host na Player lang ang tumatakbo ay nangangailangan ng standalone editor o Workstation install para maabot ang mga setting na ito. Minsan ay nagpapasya na lang ang paghihigpit na iyon sa approach.

Basahin ang resulta mula sa loob ng guest

I-restart ang virtual NIC, o i-restart ang guest, para humingi muli ito ng lease. Pagkatapos basahin kung ano talaga ang natanggap nito, hindi kung ano ang inaakalang na-configure ng host.

ipconfig /all
ip addr
ip route

Basahin ang dalawang field sa output na iyon at huwag pansinin ang iba pa sa ngayon. Ang gateway ay dapat ang router ng LAN, at ang paglalarawan ng adapter ay dapat pangalanan ang VMware Ethernet device sa halip na tunnel. Ang self-assigned address sa 169.254.0.0/16 ay nangangahulugang walang sumagot na DHCP server, at ganoon ang hitsura ng bridge papunta sa tunnel adapter mula sa panig ng guest.

Isang pagkakaiba pa ang sulit gawin bago palitan ang anumang iba. Ang guest na nakakaabot sa router pero hindi sa internet ay may gumaganang bridge at problemang nasa itaas. Ang guest na tumatanggap ng address sa tunnel range ay nakakabit pa rin sa maling device. Ang pag-disable ng TAP adapter ay hindi solusyon sa alinman sa dalawang kaso, dahil kailangan ito ng OpenVPN service.