¿Manipular las redes de Vmware Player?
Como dije en el podcast, Vmware Player no trae las herramientas para tocar las redes virtuales, pero aún así, permitidme que os muestre como hacerlo.
Origen. Mis orígenes
Partimos de que, inicialmente, yo no sabía absolutamente nada y siempre use cosas completas, incluso alguna vez sin licencia.
La primera vez que me encontré sin gestor de redes fue con Vmware Server 2.0, el sucesor del GSX y mi primer producto licenciado a mi nombre. Pero para poder usarlo, yo, que conocí GSX, Vmware Workstation desde la 4 y alguna cosa más, me quedaba corto.
En la documentación siempre salía la invocación arcana primigenia rundll32.exe vmnetui.dll VMNetUI_ShowStandalone
Esto, de rudimentario pasa a ideal. Es la interfaz completa.
Pero como todo, duró poco.
En la versión 8 de Workstation seguía funcionando pero en cuanto llegó player a la versión 7, se acabó.
En otra documentación leí algo como que con vnetlib se podía trabajar, desde la ubicación c:\Program Files (x86)\VMware\VMware Player> y con permisos de administrador.
vnetlib64.exe --stop nat
vnetlib64.exe --stop dhcp
vnetlib64.exe --set vnet vmnet8 mask 255.255.255.0
vnetlib64.exe --set vnet vmnet8 addr 172.31.255.0
vnetlib64.exe --set adapter vmnet8 addr 172.31.255.2
vnetlib64.exe --set nat vmnet8 internalipaddr 172.31.255.254
vnetlib64.exe --update dhcp vmnet8
vnetlib64.exe --update nat vmnet8
vnetlib64.exe --update adapter vmnet8
vnetlib64.exe --start dhcp
vnetlib64.exe --start nat
Se supone que con este sencillo script o su versión de 32 bits para instalaciones más antiguas, podía configurar en este caso el adaptador vmnet8.
Quizás en Workstation 11 y 12, player 7 y 10, pero no más allá.
El futuro se oscureció.
Hasta que encontré una forma adecuada de hacerlo
Como podéis apreciar, el uso de vnetlib o vnetlib64 en player es inviable.
Partimos de una serie de direcciones que me han venido generadas de forma aleatoria.
Podemos verlo con el command-let get-netipaddress | select ipaddress,interfacealias o con ipconfig
Pero claro, no me gustan. O a lo mejor he reinstalado o cambiado mi sistema y tengo máquinas de laboratorio a las que no puedo cambiar la IP, como por ejemplo un controlador de dominio o algún sistema complejo.
Player por defecto, como hemos visto, no permite este tipo de operación, pero vamos a realizarla de todas maneras.
Para poder “saltar” esta restricción, debemos bajar a las tripas. Al más bajo nivel. Así que empezaremos por buscar los ficheros de configuración, que se ubican en %programdata%\vmware o lo que es lo mismo, habitualmente en c:\programdata\vmware
En ellos están las reservas (leases) tablas de nat, y configuraciones (conf).
Pero antes de poder tocarlos, necesitamos parar los servicios que dependen, en parte, de estos ficheros.
Hay que parar ambos servicios, tanto VMware DHCP Service como VMware NAT Service puesto que son las interfaces que vamos a tocar.
Punto de partida
Partimos de la siguiente situación:
| Red | Nombre | Rango |
|---|---|---|
| vmnet1 | Host-only | 192.168.79.0 |
| vmnet8 | Nat | 192.168.23.0 |
Según se ve en el fichero, y en los comandos del inicio.
y queremos ir a:
| Red | Nombre | Rango |
|---|---|---|
| vmnet1 | Host-only | 172.31.254.0 |
| vmnet8 | Nat | 172.31.255.0 |
Por lo que empezamos por tocar el primero de los ficheros y vamos a reemplazar todas las cadenas 192.168.79. por 172.31.254.
Para las cadenas 192.168.23. haremos lo mismo, reemplazar por 172.31.255.
Ahora toca continuar haciendo cosas interesantes, como arrancar los servicios. Y fallar.
Continuando con la frente muy alta
Vale. Ha fallado el inicio de los servicios.
¿Por qué?
Pues porque hay que tocar más cosas para que podamos realmente aplicar la configuración, y si no coincide la configuración del fichero con la del registro, pues falla, tal como atestigua el visor de eventos del cual no me he acordado de sacar imagen.
Empezamos con el registro
Lo primero es saber donde están las entradas que nos interesan.
La primera entrada, corresponde al hive [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig] y contieene los rangos de red asignados a cada adaptador.
En concreto tendremos:
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet1]
"IPSubnetAddress"="192.168.79.0"
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet8]
"IPSubnetAddress"="192.168.23.0"
Y habrá que sustituirlo por…
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet1]
"IPSubnetAddress"="172.31.255.0"
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet8]
"IPSubnetAddress"="172.31.255.0"
Como se que el código se ve un poco peor que las imágenes, foto va.
La primera tarjeta será…
Y la segunda, modificada…
Eso no es todo.
Subiendo la complejidad
Ahora tenemos que tocar algo más complejo, y es que la dirección IP del adaptador virtual ya no está en modo legible, si no que está ofuscado tal que así:
En ambos adaptadores:
Extrayendo, queda algo como este código.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VMnetDHCP\Parameters\VirtualEthernetSegments\1]
"HostIpAddress"=dword:014fa8c0
"ListenTo"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VMnetDHCP\Parameters\VirtualEthernetSegments\8]
"HostIpAddress"=dword:0117a8c0
"ListenTo"=dword:00000001
Bueno, pues resulta que tenemos un número muy extraño. dword:014fa8c0 es un hexadecimal, está claro, y a la vez es un decimal sin mucho sentido. Pero ¿Por qué?…
Sin duda es una forma rebuscada de ofuscación, la cual codifica lo siguiente:
| Grupo menos relevante | tercer grupo | Segundo grupo | Grupo más relevante | |
|---|---|---|---|---|
| Hexadecimal | 01 | 4f | a8 | c0 |
| Decimal | 1 | 79 | 168 | 192 |
Como podemos ver, la dirección ip 192.168.79.1 del adaptador vmnet1 está escondida como 0x0117a8c0 en ese dword.
Así que vamos a realizar la operación contraria, y para ello, la calculadora de programación es bastante útil, eso si, calculando de dos en dos desde la derecha.
Las modificaciones, tras calcular correctamente las necesidades y las direcciones, tendremos esto.
| Grupo menos relevante | tercer grupo | Segundo grupo | Grupo más relevante | |
|---|---|---|---|---|
| vmnet1 | ||||
| Hexadecimal | 01 | 4f | a8 | c0 |
| Decimal | 1 | 79 | 168 | 192 |
| Hexadecimal | 01 | fe | 1f | ac |
| Decimal | 1 | 254 | 31 | 172 |
| vmnet8 | ||||
| Hexadecimal | 01 | 4f | a8 | c0 |
| Decimal | 1 | 23 | 168 | 192 |
| Hexadecimal | 01 | ff | 1f | ac |
| Decimal | 1 | 255 | 31 | 172 |
Podemos modificarlos en el editor del registro y guardar los datos.
Probando el sistema
Lo que toca ahora es iniciar los servicios. Si arrancan, los cambios habrán sido satisfactorios, y solo nos quedará reiniciar.
Una vez reiniciado el sistema, o quizás con ipconfig podríamos liberar y solicitar de nuevo el direccionamiento de las interfaces, podremos confirmar los datos.
Con eso, queda igualada esta característica entre vmware player y workstation.
¿Lograré hacer lo mismo en linux?
YoVirtualizador en formato podcast. Ahora también en Sospechosos Habituales: https://feedpress.me/sospechososhabituales
Y sin más, os dejo los enlaces:
Web: https://www.yovirtualizador.com
Grupo de telegram: https://t.me/grupovirtualizador
Podcast: https://www.ivoox.com/podcast-yovirtualizador_fg_f1563806_filtro_1.xml
Canal de youtube: https://www.youtube.com/channel/UC0R70cABSsmC6TFyXth0qPg
Enlace de afiliados de amazon: https://amzn.to/3gX3HmK
Enlace de referidos de la Asociación Podcast: https://www.asociacionpodcast.es/registrarse/socio/?coupon=SB6A70
