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;
}