El convidat en pont de VMware va perdre la xarxa després d'OpenVPN

Un convidat que fa una hora estava en pont i era accessible ara es queda sense resposta a tot, i ningú no ha editat la seva configuració. A l'amfitrió, internet continua funcionant a través del túnel. Els dos fets junts apunten lluny de la VPN i cap a l'hipervisor, perquè l'amfitrió i el convidat ja no utilitzen el mateix camí. Un sol adaptador virtual nou n'hi ha prou per causar-ho.

El convidat no va canviar, el pont sí

Instal·lar el client OpenVPN a Windows afegeix un adaptador de xarxa virtual al qual el servei s'enllaça quan s'aixeca un túnel. Per al sistema operatiu sembla una interfície corrent amb un estat d'enllaç i, sovint, amb adreces pròpies. Això ja n'hi ha prou perquè VMware el tracti com a candidat a pont.

VMnet0 està definit com a Automàtic per defecte, cosa que vol dir que l'hipervisor tria un adaptador de l'amfitrió cada vegada que fa pont. Un adaptador virtual acabat d'instal·lar s'afegeix a aquest conjunt i, si és triat, cada trama que emet el convidat va a un dispositiu de túnel en lloc del port físic del commutador.

Fixeu el pont o encamineu el convidat

La primera branca és la correcta quan el convidat ha de ser un parell a la LAN física: deixeu de permetre que el pont triï i anomeneu l'adaptador explícitament. La segona branca s'aplica quan el convidat ha d'utilitzar el túnel corporatiu, i en aquest cas un pont mai no va ser el disseny correcte, perquè un convidat en pont no hereta la ruta VPN de l'amfitrió.

Decidiu-ho primer, perquè les dues respostes porten a feina diferent. Invertir l'ordre produeix un pont fixat correctament unit a un convidat que mai no hauria hagut d'estar en pont.

Per a la primera branca, obriu l'Editor de xarxa virtual a l'amfitrió, seleccioneu VMnet0 i substituïu Automàtic per l'adaptador físic. Si hi ha diversos adaptadors, feu servir la llista de configuració automàtica i desmarqueu tot allò que no ha de transportar mai trànsit del convidat: el dispositiu TAP o Wintun d'OpenVPN, més els adaptadors Hyper-V, WSL, Docker i loopback. Mantingueu marcades tant l'adaptador físic per cable com el sense fil en un portàtil, o el convidat perdrà el pont la propera vegada que l'usuari l'ancori.

Tres condicions que decideixen l'elecció

Si un pont és adient o no depèn de per a què serveix el convidat. Si el convidat ha d'aparèixer com a amfitrió propi a la LAN, amb adreça pròpia i accessibilitat entrant pròpia, el pont és el model correcte i fixar-lo és tota la solució. Si el convidat només necessita accés de sortida, una xarxa només d'amfitrió o NAT és més simple i immune als canvis d'adaptador.

Si el convidat ha d'utilitzar el mateix túnel que l'amfitrió, ni el mode pont ni un adaptador fixat hi ajuden, perquè el trànsit del convidat no entra mai a la decisió d'encaminament de l'amfitrió. Aquest cas necessita un camí encaminat o traduït a l'amfitrió, i l'elecció d'adaptador esdevé irrellevant.

VMware Player no té editor de xarxa a la seva interfície, així que un amfitrió que només té Player necessita l'editor independent o una instal·lació de Workstation per arribar a aquesta configuració. Aquesta restricció de vegades decideix l'enfocament tota sola.

Llegiu el resultat des de dins del convidat

Reinicieu la NIC virtual, o reinicieu el convidat, perquè torni a demanar una concessió. Després llegiu què ha rebut realment, no què creu l'amfitrió que ha configurat.

ipconfig /all
ip addr
ip route

Llegiu dos camps d'aquesta sortida i ignoreu la resta per ara. La passarel·la hauria de ser el router de la LAN, i la descripció de l'adaptador hauria de nomenar el dispositiu Ethernet de VMware i no un túnel. Una adreça autoassignada dins de 169.254.0.0/16 vol dir que cap servidor DHCP ha respost, que és com es veu un pont sobre un adaptador de túnel des del costat del convidat.

Val la pena fer una distinció més abans de canviar res més. Un convidat que arriba al router però no a internet té un pont que funciona i un problema aigües amunt. Un convidat que rep una adreça dins del rang del túnel encara està connectat al dispositiu equivocat. Desactivar l'adaptador TAP no és una solució per a cap dels dos casos, perquè el servei OpenVPN el necessita.