El invitado puenteado de VMware perdió su red tras OpenVPN

Un invitado que hace una hora estaba puenteado y era accesible ahora agota el tiempo en todo, y nadie ha editado su configuración. En el anfitrión, internet sigue funcionando por el túnel. Los dos hechos juntos apuntan lejos de la VPN y hacia el hipervisor, porque el anfitrión y el invitado ya no usan la misma ruta. Un solo adaptador virtual nuevo basta para provocarlo.

El invitado no cambió, el puente sí

Instalar el cliente OpenVPN en Windows añade un adaptador de red virtual al que el servicio se enlaza cuando se levanta un túnel. Para el sistema operativo parece una interfaz corriente con un estado de enlace y, a menudo, con sus propias direcciones. Eso basta para que VMware lo trate como candidato a puente.

VMnet0 está en Automático de forma predeterminada, lo que significa que el hipervisor elige un adaptador del anfitrión cada vez que hace puente. Un adaptador virtual recién instalado entra en ese conjunto y, si se elige, cada trama que emite el invitado va a un dispositivo de túnel en lugar del puerto físico del conmutador.

Fije el puente o enrute al invitado

La primera rama es la correcta cuando el invitado debe ser un par en la LAN física: deje de permitir que el puente elija y nombre el adaptador de forma explícita. La segunda rama se aplica cuando el invitado debe usar el túnel corporativo, y en ese caso un puente nunca fue el diseño correcto, porque un invitado puenteado no hereda la ruta VPN del anfitrión.

Decida eso primero, porque las dos respuestas llevan a trabajos distintos. Invertir el orden produce un puente bien fijado unido a un invitado que nunca debió estar puenteado.

Para la primera rama, abra el Editor de red virtual en el anfitrión, seleccione VMnet0 y sustituya Automático por el adaptador físico. Si hay varios adaptadores, use la lista de configuración automática y desmarque todo lo que nunca deba transportar tráfico del invitado: el dispositivo TAP o Wintun de OpenVPN, además de los adaptadores Hyper-V, WSL, Docker y loopback. Mantenga marcados tanto el adaptador físico por cable como el inalámbrico en un portátil, o el invitado perderá el puente la próxima vez que el usuario lo acople.

Tres condiciones que zanjan la elección

Que un puente sea siquiera apropiado depende de para qué sirve el invitado. Si el invitado debe aparecer como un anfitrión propio en la LAN, con su propia dirección y su propia accesibilidad entrante, el puente es el modelo correcto y fijarlo es toda la solución. Si el invitado solo necesita acceso saliente, una red solo de anfitrión o NAT es más simple e inmune a los cambios de adaptador.

Si el invitado debe usar el mismo túnel que el anfitrión, no ayuda ni el modo puente ni un adaptador fijado, porque el tráfico del invitado nunca entra en la decisión de enrutamiento del anfitrión. Ese caso necesita una ruta enrutada o traducida en el anfitrión, y la elección de adaptador deja de importar.

VMware Player no tiene editor de red en su interfaz, así que un anfitrión que solo ejecuta Player necesita el editor independiente o una instalación de Workstation para llegar a estos ajustes. Esa restricción a veces decide el enfoque por sí sola.

Lea el resultado desde dentro del invitado

Reinicie la NIC virtual, o reinicie el invitado, para que vuelva a pedir una concesión. Luego lea lo que realmente recibió, y no lo que el anfitrión cree haber configurado.

ipconfig /all
ip addr
ip route

Lea dos campos de esa salida e ignore el resto por ahora. La puerta de enlace debería ser el router de la LAN, y la descripción del adaptador debería nombrar el dispositivo Ethernet de VMware en lugar de un túnel. Una dirección autoasignada dentro de 169.254.0.0/16 significa que ningún servidor DHCP respondió, que es como se ve un puente sobre un adaptador de túnel desde el lado del invitado.

Vale la pena hacer una distinción más antes de cambiar cualquier otra cosa. Un invitado que llega al router pero no a internet tiene un puente que funciona y un problema aguas arriba. Un invitado que recibe una dirección dentro del rango del túnel sigue conectado al dispositivo equivocado. Desactivar el adaptador TAP no es una solución para ninguno de los dos casos, porque el servicio OpenVPN lo necesita.