Il guest in bridge di VMware ha perso la rete dopo OpenVPN

Un guest che un’ora fa era in bridge e raggiungibile ora va in timeout su tutto, e nessuno ha modificato le sue impostazioni. Sull’host Internet funziona ancora attraverso il tunnel. I due fatti insieme allontanano la pista dalla VPN e la spostano verso l’hypervisor, perché host e guest non usano più lo stesso percorso. Basta un solo nuovo adattatore virtuale a causarlo.

Il guest non è cambiato, è cambiato il bridge

Installare il client OpenVPN su Windows aggiunge un adattatore di rete virtuale a cui il servizio si lega quando sale un tunnel. Per il sistema operativo sembra un’interfaccia ordinaria con uno stato del collegamento e, spesso, con indirizzi propri. Questo basta a VMware per trattarlo come candidato al bridge.

VMnet0 è impostato su Automatico per impostazione predefinita, il che significa che l’hypervisor sceglie una NIC dell’host ogni volta che fa bridging. Un adattatore virtuale appena installato entra in quel gruppo e, se viene scelto, ogni frame emesso dal guest va a un dispositivo di tunnel invece che alla porta fisica dello switch.

Fissare il bridge o instradare il guest

Il primo ramo è quello giusto quando il guest deve essere un pari sulla LAN fisica: smettete di lasciare che il bridge scelga e nominate l’adattatore in modo esplicito. Il secondo ramo vale quando il guest deve usare il tunnel aziendale, e in quel caso un bridge non è mai stata la progettazione corretta, perché un guest in bridge non eredita la rotta VPN dell’host.

Decidetelo prima, perché le due risposte portano a lavori diversi. Invertire l’ordine produce un bridge fissato correttamente ma collegato a un guest che non avrebbe mai dovuto essere in bridge.

Per il primo ramo, aprite l’Editor di rete virtuale sull’host, selezionate VMnet0 e sostituite Automatico con l’adattatore fisico. Se esistono più adattatori, usate l’elenco delle impostazioni automatiche e togliete la spunta a tutto ciò che non deve mai trasportare traffico del guest: il dispositivo TAP o Wintun di OpenVPN, oltre agli adattatori Hyper-V, WSL, Docker e loopback. Tenete spuntati sia l’adattatore fisico cablato sia quello wireless su un portatile, altrimenti il guest perde il bridge la volta successiva che l’utente lo inserisce nella docking station.

Tre condizioni che risolvono la scelta

Se un bridge sia addirittura appropriato dipende da a cosa serve il guest. Se il guest deve apparire come host a sé stante sulla LAN, con un proprio indirizzo e una propria raggiungibilità in ingresso, il bridge è il modello corretto e il fissaggio è l’intera correzione. Se il guest ha bisogno solo di accesso in uscita, una rete solo host o NAT è più semplice e immune ai cambi di adattatore.

Se il guest deve usare lo stesso tunnel dell’host, non aiuta né la modalità bridge né un adattatore fissato, perché il traffico del guest non entra mai nella decisione di instradamento dell’host. Quel caso richiede un percorso instradato o tradotto sull’host, e la scelta dell’adattatore diventa irrilevante.

VMware Player non ha un editor di rete nella sua interfaccia, quindi un host che esegue solo Player ha bisogno dell’editor autonomo o di un’installazione di Workstation per raggiungere queste impostazioni. Quel vincolo a volte decide l’approccio da solo.

Leggere il risultato dall’interno del guest

Riavviate la NIC virtuale, o riavviate il guest, in modo che richieda di nuovo un lease. Poi leggete ciò che ha effettivamente ricevuto, non ciò che l’host crede di aver configurato.

ipconfig /all
ip addr
ip route

Leggete due campi in quell’output e ignorate il resto per ora. Il gateway dovrebbe essere il router della LAN, e la descrizione dell’adattatore dovrebbe nominare il dispositivo Ethernet di VMware invece di un tunnel. Un indirizzo autoassegnato in 169.254.0.0/16 significa che nessun server DHCP ha risposto, ed è esattamente l’aspetto di un bridge su un adattatore di tunnel visto dal lato del guest.

Vale la pena fare un’altra distinzione prima di cambiare qualcos’altro. Un guest che raggiunge il router ma non Internet ha un bridge funzionante e un problema a monte. Un guest che riceve un indirizzo nell’intervallo del tunnel è ancora collegato al dispositivo sbagliato. Disattivare l’adattatore TAP non è una soluzione per nessuno dei due casi, perché il servizio OpenVPN ne ha bisogno.