O convidado en ponte de VMware perdeu a súa rede tras OpenVPN

Un convidado que hai unha hora estaba en ponte e era accesible agora esgota o tempo en todo, e ninguén editou a súa configuración. No anfitrión, internet segue funcionando polo túnel. Os dous feitos xuntos apuntan lonxe da VPN e cara ao hipervisor, porque o anfitrión e o convidado xa non usan o mesmo camiño. Abonda un só adaptador virtual novo para provocalo.

O convidado non cambiou, a ponte si

Instalar o cliente OpenVPN en Windows engade un adaptador de rede virtual ao que o servizo se liga cando se levanta un túnel. Para o sistema operativo parece unha interface corrente cun estado de enlace e, a miúdo, coas súas propias direccións. Iso abonda para que VMware o trate como candidato a ponte.

VMnet0 está en Automático por defecto, o que significa que o hipervisor escolle un adaptador do anfitrión cada vez que fai ponte. Un adaptador virtual recén instalado entra nese conxunto e, se se escolle, cada trama que emite o convidado vai a un dispositivo de túnel en lugar do porto físico do conmutador.

Fixe a ponte ou encamiñe o convidado

A primeira rama é a correcta cando o convidado debe ser un par na LAN física: deixe de permitir que a ponte escolla e nomee o adaptador de forma explícita. A segunda rama aplícase cando o convidado debe usar o túnel corporativo, e nese caso unha ponte nunca foi o deseño correcto, porque un convidado en ponte non herda a ruta VPN do anfitrión.

Decida iso primeiro, porque as dúas respostas levan a traballos distintos. Inverter a orde produce unha ponte ben fixada unida a un convidado que nunca debería estar en ponte.

Para a primeira rama, abra o Editor de rede virtual no anfitrión, seleccione VMnet0 e substitúa Automático polo adaptador físico. Se hai varios adaptadores, use a lista de configuración automática e desmarque todo o que nunca deba transportar tráfico do convidado: o dispositivo TAP ou Wintun de OpenVPN, ademais dos adaptadores Hyper-V, WSL, Docker e loopback. Manteña marcados tanto o adaptador físico por cable como o inalámbrico nun portátil, ou o convidado perderá a ponte a próxima vez que o usuario o acople.

Tres condicións que resolven a elección

Que unha ponte sexa sequera axeitada depende de para que serve o convidado. Se o convidado debe aparecer como un anfitrión propio na LAN, coa súa propia dirección e a súa propia accesibilidade entrante, a ponte é o modelo correcto e fixala é toda a solución. Se o convidado só necesita acceso de saída, unha rede só de anfitrión ou NAT é máis simple e inmune aos cambios de adaptador.

Se o convidado debe usar o mesmo túnel que o anfitrión, non axuda nin o modo ponte nin un adaptador fixado, porque o tráfico do convidado nunca entra na decisión de encamiñamento do anfitrión. Ese caso necesita un camiño encamiñado ou traducido no anfitrión, e a elección de adaptador deixa de importar.

VMware Player non ten editor de rede na súa interface, así que un anfitrión que só executa Player necesita o editor independente ou unha instalación de Workstation para chegar a estes axustes. Esa restrición ás veces decide o enfoque por si soa.

Lea o resultado desde dentro do convidado

Reinicie a NIC virtual, ou reinicie o convidado, para que volva pedir unha concesión. Despois lea o que realmente recibiu, e non o que o anfitrión cre que configurou.

ipconfig /all
ip addr
ip route

Lea dous campos desa saída e ignore o resto por agora. A porta de enlace debería ser o router da LAN, e a descrición do adaptador debería nomear o dispositivo Ethernet de VMware en lugar dun túnel. Unha dirección autoasignada dentro de 169.254.0.0/16 significa que ningún servidor DHCP respondeu, que é como se ve unha ponte sobre un adaptador de túnel desde o lado do convidado.

Vale a pena facer outra distinción antes de cambiar calquera outra cousa. Un convidado que chega ao router pero non a internet ten unha ponte que funciona e un problema augas arriba. Un convidado que recibe unha dirección dentro do rango do túnel segue conectado ao dispositivo equivocado. Desactivar o adaptador TAP non é unha solución para ningún dos dous casos, porque o servizo OpenVPN necesita del.