O convidado em bridge do VMware perdeu a rede depois do OpenVPN

Um convidado que há uma hora estava em bridge e era acessível agora esgota o tempo em tudo, e ninguém editou as suas configurações. No anfitrião, a internet continua a funcionar através do túnel. Os dois factos juntos afastam a pista da VPN e apontam para o hipervisor, porque o anfitrião e o convidado já não usam o mesmo caminho. Basta um único adaptador virtual novo para o provocar.

O convidado não mudou, a bridge mudou

Instalar o cliente OpenVPN no Windows acrescenta um adaptador de rede virtual ao qual o serviço se liga quando um túnel sobe. Para o sistema operativo, parece uma interface comum com um estado de ligação e, muitas vezes, com endereços próprios. Isso basta para o VMware o tratar como candidato a bridge.

O VMnet0 está em Automático por predefinição, o que significa que o hipervisor escolhe um adaptador do anfitrião sempre que faz a bridge. Um adaptador virtual recém-instalado entra nesse conjunto e, se for escolhido, cada frame emitido pelo convidado vai para um dispositivo de túnel em vez da porta física do comutador.

Fixe a bridge ou encaminhe o convidado

O primeiro ramo é o correto quando o convidado deve ser um par na LAN física: deixe de permitir que a bridge escolha e nomeie o adaptador de forma explícita. O segundo ramo aplica-se quando o convidado deve usar o túnel da empresa, e nesse caso uma bridge nunca foi o desenho correto, porque um convidado em bridge não herda a rota VPN do anfitrião.

Decida isso primeiro, porque as duas respostas levam a trabalho diferente. Inverter a ordem produz uma bridge corretamente fixada e ligada a um convidado que nunca deveria ter estado em bridge.

Para o primeiro ramo, abra o Editor de rede virtual no anfitrião, selecione o VMnet0 e substitua Automático pelo adaptador físico. Se existirem vários adaptadores, use a lista de configurações automáticas e desmarque tudo o que nunca deve transportar tráfego do convidado: o dispositivo TAP ou Wintun do OpenVPN, além dos adaptadores Hyper-V, WSL, Docker e loopback. Mantenha marcados tanto o adaptador físico com cabo como o sem fios num portátil, ou o convidado perde a bridge da próxima vez que o utilizador o acoplar.

Três condições que resolvem a escolha

Se uma bridge é sequer apropriada depende daquilo para que o convidado serve. Se o convidado tiver de aparecer como anfitrião próprio na LAN, com endereço próprio e acessibilidade de entrada própria, a bridge é o modelo correto e fixá-la é toda a correção. Se o convidado só precisar de acesso de saída, uma rede só de anfitrião ou NAT é mais simples e imune a mudanças de adaptador.

Se o convidado tiver de usar o mesmo túnel que o anfitrião, nem o modo bridge nem um adaptador fixado ajudam, porque o tráfego do convidado nunca entra na decisão de encaminhamento do anfitrião. Esse caso exige um caminho encaminhado ou traduzido no anfitrião, e a escolha do adaptador deixa de importar.

O VMware Player não tem editor de rede na sua interface, por isso um anfitrião que só execute o Player precisa do editor autónomo ou de uma instalação do Workstation para chegar a estas definições. Essa restrição às vezes decide a abordagem por si só.

Leia o resultado de dentro do convidado

Reinicie a NIC virtual, ou reinicie o convidado, para que volte a pedir uma concessão. Depois leia o que ele recebeu realmente, e não o que o anfitrião pensa ter configurado.

ipconfig /all
ip addr
ip route

Leia dois campos nessa saída e ignore o resto por agora. A gateway deve ser o router da LAN, e a descrição do adaptador deve nomear o dispositivo Ethernet da VMware em vez de um túnel. Um endereço auto-atribuído em 169.254.0.0/16 significa que nenhum servidor DHCP respondeu, e é assim que uma bridge sobre um adaptador de túnel se vê do lado do convidado.

Vale a pena fazer mais uma distinção antes de mudar qualquer outra coisa. Um convidado que chega ao router mas não à internet tem uma bridge a funcionar e um problema a montante. Um convidado que recebe um endereço dentro do intervalo do túnel continua ligado ao dispositivo errado. Desativar o adaptador TAP não é solução para nenhum dos dois casos, porque o serviço OpenVPN precisa dele.