En VMWare a la hora de crear un dispositivo de red se puede elegir entre:

En Qemu hay dos formas de utilizar la red. Por defecto se usa -net socket, que sería el equivalente al modo NAT de Vmware. Mediante la opción -redir se pueden abrir puertos de servidor. Una diferencia interesante sobre Vmware es que esta solución se implementa enteramente en espacio de usuario, por lo que no se crea interfaz de red ni se precisa cargar ningún módulo del kernel, lo que es bueno porque en el caso de Vmware es un módulo privativo que activa la marca "tained" del kérnel, con lo que perdemos toda opción de soporte. Además así no hay que tener privilegios de superusuario para instalar Qemu (Vmware no requiere privilegios para ejecutarse, pero sí hace falta para insertar el módulo en el kernel).

Las interfaces de red vmnet1, vmnet2, vment8, se crean al ejecutar vmware-config, en la parte de configuración de red. Una posibilidad interesante si vamos a ejecutar varios sistemas simultáneamente o si queremos que un sistema tenga más de una interfaz es crear más de un dispositivo de red para "host only", de modo que aparte de vmnet1 haya otros. De otro modo todas las máquinas virtuales estarán conectadas a la misma red, la de vmnet1. Así, una máquina podrá tener la IP 192.168.152.128, otra la 192.168.152.129 y el host la 192.168.152.1; las dos máquinas virtuales se verán la una a la otra y podrán comunicarse, aunque eso sí, con un sniffer una máquina no verá el tráfico de los otros nodos.

La red vmnet1 que crea Vmware es de máscara de red 255.255.255.0; ejecuta un servidor DHCP automáticamente, cuya configuración y arrendamientos pueden verse en /etc/vmware/vmnet1. Pero nada impide que podamos cambiar esta configuración, pues se emula a una interfaz ethernet. Por ejemplo un nodo puede cambiar su IP a otra de la red o incluso crear un alias y usar una red distinta, tanto en el host como en las máquinas virtuales.

Si usamos vmnet1 para hacer NAT utilizando iptables, hay que tener en cuenta que habrá que configurar la red de la máquina virtual para añadirle una ruta por defecto y la configuración del DNS y que el firewall deberá permitir que llegue al servidor DNS. Para pasar la configuración de DNS y ruta por defecto podemos usar el servidor DHCP de Vmware: "option routers" y "option domain-name-servers".

Un inconveniente de -net socket es que como ocurre con los modos NAT y Bridge de Vmware los paquetes no pasan por ninguna interfaz de red, por lo que no se puede utilizar iptables para restringir la red.

La solución está en el uso del soporte de TUN/TAP del kernel. Consiste en que una aplicación puede abrir el fichero de dispositivo /dev/net/tun y con eso crear una nueva interfaz de red (por defecto tun0). Todo lo que la aplicación escriba en ese dispositivo se recibirá en la interfaz de red recién creada; de igual modo todo lo que llegue a esa interfaz de red (por ejemplo a través de enrutamiento) lo leerá la aplicación del fichero de dispositivo.

Los dispositivos TUN operan a nivel IP y son punto a punto. Los dispositivos TAP operan a nivel 2 y son multipunto, como las interfaces eth*. Un dispositivo tap0 y un dispositivo vmnet1 vienen a funcionar de forma muy similar y a nivel de ejemplos de configuración con iptables o brctl donde aparezca un tap0 podría aparecer un vmnet1 y viceversa. Por lo general se usa tun0 en lugar de tap0; para la mayoría de los usos son equivalentes por lo que es mucho más habitual utilizar tun0 que resulta más sencillo y directo.

Normalmente un dispositivo tun/tap sólo existe mientras el programa no cierra el fichero /dev/net/tun. Esto a veces es problemático, especialmente porque para crear un dispositivo TUN/TAP hacen falta privilegios de superusuario. Afortunadamente, con root se puede abrir un dispositivo en modo persistente para un determinado usuario, de modo que luego un programa ejecutado por ese usario sin privilegios podrá abrir ese dispositivo tun/tap creado para él por el root. Este se puede hacer con el programa tunctl, que forma parte del paquete uml-utilities.

¿Por qué no usa Vmware TUN/TAP en lugar de vmnet1? quizás por unicidad entre plataformas, o por diferencia de implementación; es posible que vmnet1 también permita driver de red de la máquina virtual directamente en espacio del kernel.

TUN/TAP es la solución utilizada también por otros virtualizadores, como Virtual Box. Muy interesantes los documentos sobre red avanzada en la web de Virtual Box: http://www.virtualbox.org/wiki/User_HOWTOS.

Permitir acceso sólo a red local 192.168.10.0 y además excluir el nodo 9 de esa red.

iptables -A FORWARD -i vmnet1 --destination 192.168.10.9 -j REJECT

iptables -A FORWARD -i vmnet1 --destination 192.168.10.0/24 -j ACCEPT

iptables -A FORWARD -i vmnet1 -j REJECT

iptables -t nat -A POSTROUTING -j MASQUERADE -o eth0

echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding

echo 1 > /proc/sys/net/ipv4/conf/vmnet1/forwarding

Crear un bridge, pero prohibiendo el acceso a la IP 157.88.10.20. Se puede filtrar con ebtables o con iptables.

Ojo, muchas tarjetas wireless no soportan bridge. Un AP generalmente sí.

ifconfig eth0 0.0.0.0

ifconfig vmnet1 0.0.0.0

brctl addbr puente

brctl addbr puente

brctl addif eth0

brctl addif vmnet1

ifconfig puente 192.168.10.1

iptables -O FORWARD -m physdev --physdev-in vmnet1 --destination 157.88.10.20 -j REJECT

Para compilar kqemu no hace falta versión vieja de compilador gcc, ni las fuentes de qemu. Es bastante rápido:

./configure

make

sudo make install

modprobe kqemu

Por defecto, necesitamos permisos de root para leer /dev/kqemu

Ejemplos:

./qemu -net nic -net tap,script=no ~/linux-0.2.img -net nic,vlan=1 -net socket,vlan=1,listen=:8081 centos.qcow2

ifconfig tap0 up

ifconfig eth0

brctl addif puente tap0

ifconfig eth0 0.0.0.0

brctl addif puente eth0

ifconfig eth0 192.168.15.45

./qemu -net nic -net tap,script=no ~/centos.qcow2 -no-kqemu

qemu-img create -f qcow2 centos.qcow2 3G

Con esta orden se crea una imagen de un disco de 3GB; en realidad con GNU/Linux este fichero no ocupa 3GB; el espacio sin usar del fichero no ocupa espacio en el disco.

Para arrancar del CD de instalación podemos ejecutar:

qemu -kernel-kqemu -cdrom /home/jomar/centos1of6.iso -boot d -m 512 centos.qcow2

La opción -kernel-kqemu es para obtener la máxima aceleración: acelera también el código del espacio del kernel; por defecto sólo se acelera la de usuario. Si se produce algún problema, reintentaremos sin esta opción; si sigue habiendo problemas podemos probar con -no-kqemu a quitar incluso la aceleración de espacio de usuario. Tras la instalación, podemos probar a volver a utilizar aceleración: a veces los posibles problemas sólo se dan durante la instalación, aunque esta situación es más propia de Windows que GNU/Linux.

Con la opción -cdrom le indicamos que el CDROM es en realidad esa ISO; así evitamos el tener que tostar un CD. Con la opción -boot d indicamos que arranque de CD en vez de disco duro. La opción -m 512 establece que la máquina virtual tenga 512 MB de memoria. La cantidad de memoria puede cambiarse de una ejecución a otra, pero hay que tener en cuenta que los instaladores suelen crear una partición de intercambio con el doble de la memoria RAM.

¿Cómo cambiar de CD durante la instalación? Con ctrl-alt-2 (ojo 1, no F1) pasamos al monitor, en el que ejecutamos el comando:

change cdrom /home/jomar/centos2of6.iso

Tras escribir la orden (qemu no indica ni errores ni que la operación se ha realizado con éxito) volvemos a la pantalla de la máquina virtual con ctrl-alt-1.

Una característica interesante de Qemu es que permite crear a partir de un fichero de imagen, otra imagen que sólo contendrá los cambios que se produzcan en la primera, si la primera permanece sin modificar. Esta característica es útil por ejemplo para crear dos imágenes muy parecidas para hacer pruebas de redes entre las dos imágenes, sin que ocupe tanto en el disco.

qemu-img create -b xubuntu.qcow2 xubuntu1.qcow2

qemu-img create -b xubuntu.qcow2 xubuntu2.qcow2

Listado para usar el dispositivo creado para este usuario (en kernels viejos lo crea si no existe): muestra primer paquete que recibe, una salida similar a la de tcpdump -x -i tun0. Para probarlo configuramos con ifconfig el dispositivo tun0, usando pointtopoint para indicar una IP supuestamente destino; podemos hacer un ping a esa dirección y ver lo que recibe el programa.

Listado para crear como persistente el nodo:

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <linux/if_tun.h>
#include <linux/if.h>
#include <string.h>

int main() {
   struct ifreq ifr;
   int fd, err;
   char dev[IFNAMSIZ];

   fd = open("/dev/net/tun", O_RDWR) ;
   memset(&ifr, 0, sizeof(ifr));

   /* Flags: escoger entre IFF_TAP o IFF_TUN; opcionalmente
    * añadir IFF_NO_PI
    * IFF_TAP   - Dispositivo TAP: Nivel ethernet (Layer2),           
    *             multipunto; útil para hacer bridge o para tráfico no IP
    *             también para Qemu, pues usa TAP
    * IFF_TUN   - Dispositivo TUN: nivel IP (Layer3); punto a
    *             punto; la opción recomendada normalmente si
    *             sólo trafico IP sin bridge
    * IFF_NO_PI - No añadir a paquetes TUN información adicional
    *             antes del paquete. 
    */
    ifr.ifr_flags = IFF_TUN|IFF_NO_PI;
    if( *dev )
        strncpy(ifr.ifr_name, "tun0",5);
    err= ioctl(fd, TUNSETIFF, (void *) &ifr);
    if (!(err<0)) {
      // Hacer dispositivo persistente, es decir, que permanece
      // creado aunque se cierre dispositivo; normalmente el
      // dispositivo sólo existe mientras está abierto el
      // descriptor de fichero a /dev/net/tun.
      // Cambiar 1 por 0 para borrar un dispositivo persistente.
      err= ioctl(fd, TUNSETPERSIST, 1);

      // Poner como dueño del dispositivo al UID 1000; de este
      // modo puede crear dispositivo proceso ejecutado por
      // usuario con este UID en lugar de root, si además tiene
      // permiso de lectura y escritura sobre /dev/net/tun
      // antes de kernel 2.6.18 no era necesario hacer esto, pero
      // ahora ya sí. Con Qemu otra alternativa es hacer un
      // programa lanzador setuid que abra fichero, revoque
      // privilegios y lance Qemu pasándole handler abierto; o que
      // un programa con privilegio de root abra fichero y pase el
      // handler vía un socket UNIX (ver man cmsg)
      if (!(err<0))
          err= ioctl(fd, TUNSETOWNER, 1000);
    }

    if( err<0) {
        perror("falló");
        close(fd);
        return err;
    }
    strcpy(dev, ifr.ifr_name);
    printf("%s\n",ifr.ifr_name);
    return 0;
}

Programa para crear un dispositivo TUN/TAP persistente

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <linux/if_tun.h>
#include <linux/if.h>
#include <string.h>

int main() {
   struct ifreq ifr;
   int fd, err;
   char dev[IFNAMSIZ];

   fd = open("/dev/net/tun", O_RDWR) ;
   memset(&ifr, 0, sizeof(ifr));

   /* Flags: escoger entre IFF_TAP o IFF_TUN; opcionalmente
    * añadir IFF_NO_PI
    * IFF_TAP   - Dispositivo TAP: Nivel ethernet (Layer2),           
    *             multipunto.
    *             útil para hacer bridge o para tráfico no IP
    *             también para Qemu, pues usa TAP
    * IFF_TUN   - Dispositivo TUN: nivel IP (Layer3); punto a
    *             punto; la opción recomendada normalmente si
    *             sólo tráfico IP sin bridge
    * IFF_NO_PI - No añadir a paquetes TUN información adicional
    *             antes del paquete. 
    */
    ifr.ifr_flags = IFF_TUN|IFF_NO_PI;
    if( *dev )
        strncpy(ifr.ifr_name, "tun0",5);
    err= ioctl(fd, TUNSETIFF, (void *) &ifr);
    if (!(err<0)) {
      // Hacer dispositivo persistente, es decir, que permanece
      // creado aunque se cierre dispositivo; normalmente el
      // dispositivo sólo existe mientras está abierto el
      // descriptor de fichero a /dev/net/tun.
      // Cambiar 1 por 0 para borrar un dispositivo persistente.
      err= ioctl(fd, TUNSETPERSIST, 1);

      // Poner como dueño del dispositivo al UID 1000; de este
      // modo puede crear dispositivo proceso ejecutado por
      // usuario con este UID en lugar de root, si además tiene
      // permiso de lectura y escritura sobre /dev/net/tun
      // antes de kernel 2.6.18 no era necesario hacer esto, pero
      // ahora ya sí. Con Qemu otra alternativa es hacer un
      // programa lanzador setuid que abra fichero, revoque
      // privilegios y lance Qemu pasándole handler abierto; o que
      // un programa con privilegio de root abra fichero y pase el
      // handler vía un socket UNIX (ver man cmsg)
      if (!(err<0))
          err= ioctl(fd, TUNSETOWNER, 1000);
    }

    if( err<0) {
        perror("falló");
        close(fd);
        return err;
    }
    strcpy(dev, ifr.ifr_name);
    printf("%s\n",ifr.ifr_name);
    return 0;
}