HiperGalaxia

Introducción.

Este es el panorama del esquema de red de la oficina del grupo de desarrollo.

Esquema de la red

Un servidor (centro) alberga los proyectos web (Apache) de los cuales el grupo de desarrollo manipula sus archivos (SSH + Samba), así como sus bases de datos (MySQL).  El servidor cuenta con dos interfaces de red las cuales separan físicamente el acceso de la red privada (eth1) de la red pública o Internet (eth0).

Los desarrolladores utilizan los clientes desde la red privada para la cual no hay ningún tipo de filtro en el servidor y pueden acceder a la totalidad de sus servicios.  Desde el exterior, el servidor implementa un firewall que sólo permite la consulta web de los proyectos y el acceso al SSH.  Como fácilmente se concluye, el firewall de la interfaz pública (eth0) filtra explícitamente el acceso a los servicios de MySQL y Samba que son considerados como inseguros.

El problema.

Se requiere ahora que los desarrolladores puedan acceder al servidor desde sus clientes a través de Internet.

El problema se divide en dos aproximaciones.

1. Manipular el software, el código y los datos remotamente.
2. Manipular el software y el código localmente, y los datos remotamente.

La solución.

Manipular el software, el código y los datos remotamente (1).

Este es el caso mas simple.  Como los aplicativos son web se acceden a través de un navegador, su código es manipulado a través de SSHFS (ver instrucciones para Linux y Windows) y sus datos son manipulados a través de la web con PHPMyAdmin.

Manipular el software y el código localmente y los datos remotamente (2).

Este caso es mas elaborado que el anterior ya que el software y el código reside localmente porque lo es muy fácil de manipular, sin embargo los datos (la base de datos MySQL) de los proyectos continúan viviendo en el servidor de desarrollo.

Dado que el puerto de acceso a MySQL se encuentra filtrado para el exterior por razones de seguridad es inicialmente imposible conectarse a la base de datos desde el cliente a través de Internet.  La solución es crear un tunel SSH desde el cliente remoto hasta el servidor a través del medio inseguro (Internet) y desde allí, ahora un lugar seguro, realizar la conexión con el puerto de la base de datos que en este caso reside en el mismo servidor.

Implementación de la solución (2).

Por razones que serán obvias, es necesario que los usuarios remotos cuenten con cuentas (nombre de usuario/contraseña) en el sistema operativo del servidor de desarrollo y que estas estén habilitadas para acceder al mismo a través de SSH.

Las siguientes acciones se realizan desde el cliente remoto.

Establecer el tunel SSH entre el cliente remoto y el servidor de desarrollo.

$ ssh desarrollador@desarrollo.com -L 3307:localhost:3306 -N -f

Con la instrucción anterior estamos creando un tunel entre el cliente remoto y el servidor desarrollo.com con el usuario desarrollador y utilizando al protocolo SSH.  Se le está indicando además que el tunel se deberá establecer entre el puerto 3307 local y el puerto 3306 del servidor remoto, en este caso el mismo localhost.  Es muy importante tener en cuenta que la referencia de este último servidor remoto se realiza previa conexión a desarrollo.com, es decir que su acceso se hace desde este y no directamente desde el cliente que inicia la conexión del tunel ejecutando el comando.

Otro aspecto interesante a tener en cuenta es que los puertos utilizados no necesariamente deben ser diferentes ya que uno es local (3307 en este ejemplo) y el otro es remoto (3306 el estándar de MySQL), sin embargo en el caso de que ya se cuente con una instalación local de MySQL (utilizando el puerto 3306) será entonces necesario utilizarlos diferentes como se ha planeado en este artículo.

Realizar la conexión a MySQL a través del tunel SSH.

Después de establecido el tunel entre cliente y servidor la conexión se realiza directamente con el puerto local (3307) del cliente remoto como si el servicio se estuviera ejecutando en la misma máquina cliente, el tunel se encarga de transmitir la información encriptada y realizar las conversiones necesarias a cada uno de los lados.

$ mysql -h 127.0.0.1 -u bd_usuario -p -P 3307 bd_nombre

Tenga en cuenta que el inicio de conexión (connect) a una base de datos toma cierto tiempo ya que el motor de bases de datos realiza una carga previa de los nombres de las tablas y de los campos de estas.  Si desea evitar esta precarga de información puede utilizar el parámetro -A en la invocación al cliente de MySQL (mysql).

Enlaces.

• Connecting to MySQL via an SSH Tunnel.
  http://wiki.joyent.com/facebook:kb:mysql-tunnel
• Secure Shell Tunneling.
  http://en.wikipedia.org/wiki/Ssh_tunnel#Secure_Shell_tunneling

Introducción.

El portafolio de DynDNS incluye un servicio gratuito de DNS Dinámico (entre otros servicios algunos pagos) que permite asociar una dirección IP dinámica como la asignada por los proveedores de servicio de internet a las cuentas de banda ancha, a un nombre de dominio proporcionado por ellos.

La principal ventaja de este servicio es que se actualiza frecuentemente adaptando el DNS según se modifique la dirección dinámica del router, permitiéndole a los clientes acceder al servidor utilizando siempre el nombre DNS y desconociendo por completo la dirección IP o su eventual actualización.

El servicio de Free Dynamic DNS se puede solicitar directamente desde el sitio web de la empresa, http://www.dyndns.com/.  Del lado del cliente, nosotros, debemos configurar a los equipos para que actualicen dinámicamente la información del servicio cuando se detecte un cambio en la dirección IP local.  Esto frecuentemente se realiza en los enrrutadores.  Por ejemplo, los enrrutadores que se utilizan en los hogares, como era antes mi caso con un Netgear, permiten desde su misma interfaz web de administración suministrar los datos de la cuenta DynDNS.org y ellos se encargan de mantener actualizados los datos.

Ahora utilizo un enrrutador marca Scientific Atlanta 2325 el cual aparentemente no incluye esta facilidad por lo cual me veo obligado a implementarla en el servidor de desarrollo que utiliza Linux Ubuntu Server 9.10 como sistema operativo.

Para hacer esto utilizo Inadyn, un software para la actualización de DNS dinámicos que es muy fácil de utilizar e incluye el soporte a DynDNS.org y otros servicios mas.  Este paquete se puede utilizar en Linux (por supuesto), MacOS, OpenBSD e inclusive Windows.

Instalación & Configuración.

Instalación de los paquetes de Inadyn.

$ sudo aptitude install inadyn

Crear el archivo de configuración por defecto.

$ sudo cp /usr/share/doc/inadyn/examples/inadyn.conf /etc/inadyn.conf

Asegurar los permisos del archivo de configuración por defecto.

$ sudo chmod 600 /etc/inadyn.conf

Editar la configuración de Inadyn con la información específica del servicio de DynDNS.org.

$ sudo vi /etc/inadyn.conf

–username USUARIO
–password CONTRASEÑA
update_period_sec 3600
log_file /var/log/inadyn.log
alias DOMINIO_DYNDNS
background

Modifique el archivo de configuración de acuerdo a sus valores específicos.

• USUARIO: su nombre de usuario en DynDNS.org.
• CONTRASEÑA: la contraseña correspondiente al usuario mencionado anteriormente.
• DOMINIO_DYNDNS: dominio que se configuró gratuitamente con la cuenta en DynDNS.org.

Crear un proceso cron para ejecutar Inadyn automáticamente al inicio del sistema operativo.

$ sudo crontab -e

@reboot /usr/sbin/inadyn

Comprobación del funcionamiento.

Cuando reinicie la máquina verifique que el proceso Inadyn se encuentre ejecutándose correctamente.

$ ps -A | grep inadyn

1149 ?        00:00:00 inadyn

$ cat /var/log/inadyn.log

INADYN: Started ‘INADYN version 1.96′ – dynamic DNS updater.
INADYN:IP: Error ‘0xb’ resolving host name ‘checkip.dyndns.org’
…

Verifique la dirección IP asociada al nombre DNS del servicio utilizando un ping por ejemplo.

$ ping ejemplo.gotdns.org

Si ejecuta la verificación desde la misma red interna del equipo, la dirección IP obtenida deberá ser la misma de su modem/router, la cual podrá verificar en servicios como http://whatismyipaddress.com/.

Relacionar el dominio DynDNS.org con un dominio privado.

Es posible relacionar el dominio que nos ofrece gratuitamente DynDNS (ejemplo.gotdns.org) con un dominio de nuestra propiedad.  Esto es muy útil ya que permite utilizar el dominio DNS oficial del administrador o de la empresa que lo está configurando haciendo que sea totalmente transparente para el usuario final que se está utilizando DynDNS.org en el intermedio para la conexión.

Para hacer esto sólo es necesario crear una nueva entrada en el servidor DNS incluyendo un registro CNAME entre el nuevo dominio y el asignado por DynDNS.org.

ejemplo.jorgeivanmeza.com IN CNAME ejemplo.gotdns.org

Gracias a lo anterior, el nuevo dominio (ejemplo.jorgeivanmeza.com) hará siempre referencia al original (ejemplo.gotdns.org) el cual se mantendrá siempre actualizado con los cambios de la dirección IP dinámica gracias a la configuración del Inadyn realizada anteriormente.

La configuración del DNS para agregar el CNAME varía el paquete de DNS u operador de hosting que se utilice.  Estos pasos describen los procedimientos necesarios con los principales operadores de hosting, en un servidor Linux y en un servidor Windows.

Enlaces.

• INADYN – Simple Dynamic DNS Client.
  http://www.inatech.eu/inadyn/
• Using inadyn With DynDNS.com Services.
  http://www.dyndns.com/support/kb/using_inadyn_with_dyndns_services.html
• Dynamic DNS – Ubuntu Documentation.
  https://help.ubuntu.com/community/DynamicDNS

Introducción.

De manera análoga a como se realizó anteriormente la instalación de una imagen con CentOS (para Scientific Linux se igual procedimiento) procedimos a crear una máquina virtual KVM con una instalación genérica de Ubuntu Server 9.10 para futuras experimentaciones con un plan de trabajo ligeramente modificado.

1. Actualización de paquetes.
2. Instalar ACPID.
3. Instalación del JDK de Java.
4. Instalación del ambiente de desarrollo C/C++.
5. Instalación del servidor X y IceWM como administrador de ventanas.
6. Depurar el software instalado.

Creación de la máquina virtual para la instalación del sistema operativo.

$ virt-install \
–connect qemu:///system \
-n ubuntuserver-9.10_x64-general \
-r 384 \
–os-type linux \
–os-variant generic26 \
–hvm \
–cdrom /u/isos/ubuntu-9.10-server-amd64.iso \
–network bridge:br0 \
–disk path=/u/vms/ubuntuserver-9.10_x64-general.img,size=7 \
–vnc –noautoconsole \
–accelerate

Conexión remota a la KVM para el proceso de instalación y administración.

$ /usr/bin/virt-viewer -c qemu+ssh://ivy/system ubuntuserver-9.10_x64-general

Actualización de paquetes.

$ sudo aptitude update

$ sudo aptitude safe-upgrade

Instalación de ACPID.

$ sudo aptitude install acpid

Instalación del JDK de Java.

$ sudo aptitude install sun-java6-bin sun-java6-fonts sun-java6-jdk sun-java6-jre sun-java6-plugin

Instalación del ambiente de desarrollo C/C++.

$ sudo aptitude install build-essential

Instalación del servidor X y IceWM como administrador de ventanas.

$ sudo aptitude install xorg icewm icewm-themes

Introducción.

El fin del presente artículo es el de preparar una imagen básica del sistema operativo, en este caso CentOS 5.4 de 64 bits, para futuros usos en experimentos y pruebas.  La infraestructura de virtualización que utilizo para implementarla es KVM.

En términos generales estos son las adecuaciones que tendrá está imagen básica.

1. Actualización de paquetes.
2. Instalar ACPID.
3. Permitir la ejecución de sudo para el usuario jimezam.
4. Bloquear la contraseña del usuario root.
5. Instalación del JDK de Java.
6. Instalación del ambiente de desarrollo C/C++.
7. Depurar el software instalado.

Creación de la máquina virtual para la instalación del sistema operativo.

$ virt-install \
–connect qemu:///system \
-n centos-5.4_x64-general \
-r 384 \
–os-type linux \
–os-variant generic26 \
–hvm \
–cdrom /u/isos/CentOS-5.4-x86_64-bin-DVD.iso \
–network bridge:br0 \
–disk path=/u/vms/centos-5.4_x64-general.img,size=7 \
–vnc –noautoconsole \
–accelerate

Conexión remota a la KVM para el proceso de instalación y administración.

$ /usr/bin/virt-viewer -c qemu+ssh://ivy/system centos-5.4_x64-general

Actualización de paquetes.

# yum check-update

# yum update

Instalación de ACPID.

# yum install acpid

Activar el acceso a sudo para wheel.

# visudo

%wheel     ALL=(ALL)    ALL

# usermod -G wheel jimezam

Bloquear la contraseña del usuario root.

# passwd -l root

Instalación del JDK de Java.

# yum install java-1.6.0-openjdk java-1.6.0-openjdk-devel

Instalación del ambiente de desarrollo C/C++.

# yum install gcc gcc-c++ autoconf automake

Procedimiento.

Instalar el ambiente de desarrollo y los paquetes requeridos.

# yum install gcc gcc-c++ autoconf automake byacc ncurses-devel libtool flex bison bison-devel openssl-devel libX11-devel

Descargar las fuentes de Condor.

Acceder al sitio Current Stable Release: Condor 7.4.1 en http://www.cs.wisc.edu/condor/downloads-v2/download.pl y descargar el paquete Condor Source: condor_src-7.4.1-all-all.tar.gz.

Descomprimir las fuentes.

# tar zxvf condor_src-7.4.1-all-all.tar.gz

# cd condor-7.4.1/src

Construír el proyecto.

# ./build_init

# ./configure

# ./make

Generar el directorio con la distribución.

Si desea generar binarios enlazados dinámicamente con información de depuración ejecute el siguiente comando.

# ./make release

Si por el contrario, desea generar binarios enlazados dinámica y estáticamente SIN información de depuración, ejecute el siguiente comando.

# ./make public

La distribución de Condor recién construída se ubicará bajo el directorio src/release_dir.

Enlaces.

• Página web del proyecto Condor.
  http://www.cs.wisc.edu/condor/
• Descargar Condor.
  http://www.cs.wisc.edu/condor/downloads-v2/download.pl
• Repositorio de manuales.
  http://www.cs.wisc.edu/condor/manual/index.html
• Manual – capítulo de instalación.
  http://www.cs.wisc.edu/condor/manual/v7.4/3_2Installation.html

Introducción.

Después de configurar el puente entre las interfaces de red para permitirle el acceso a la red a las máquinas virtuales basadas en KVM encontré un problema: el servidor podía ser accedido pero este no tenía acceso a Internet.

Después de algunas pruebas determiné el problema sin embargo su solución me tomó mas de lo esperado ya que previamente había instalado wicd para administrar con mayor sencillez las interfaces de red, especialmente la inalámbrica, y esto hizo que mis intentos previos de solución sin tenerlo en cuenta fracasaran miserablemente.

El problema.

Después de la creación del puente sobre la interfaz de red alámbrica (eth0)  se crea la interfaz bridge (br0) la cual toma su información de red.  El problema radica en que, aparentemente wicd, se crean dos gateways por defecto.

$ sudo route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
default         192.168.1.1     0.0.0.0         UG    100    0        0 br0

La solución.

Versión temporal.

El problema se soluciona removiendo el camino establecido a través de la interfaz de red alámbrica de la siguiente manera.

$ sudo route del -net default netmask 0.0.0.0 dev eth0

De esta manera el servidor ya puede acceder a la red WAN, sin embargo al reiniciarse el problema se vuelve a presentar.

Version final.

Probablemente en condiciones normales el problema se solucione agregando el comando mencionado anteriormente en /etc/rc.local y asignándole permisos de ejecución a este archivo, sin embargo esta estrategia resultó infructuosa en el servidor ya que este estaba utilizando wicd.

Para solucionar el problema de manera definitiva utilizando wicd se deben realizar los siguientes pasos.

$ sudo vi /etc/wicd/wired-settings.conf

Agregar un elemento afterscript de la siguiente manera.

[wired-default]
afterscript = /etc/wicd/scripts/postconnect/removeEth0GatewayRoute
…

Crear el script asociado.

$ sudo vi /etc/wicd/scripts/postconnect/removeEth0GatewayRoute

route del -net default netmask 0.0.0.0 dev eth0

$ sudo chmod +x /etc/wicd/scripts/postconnect/removeEth0GatewayRoute

Reiniciar el servidor y verificar que el script se ha ejecutado exitosamente.

$ sudo route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
default         192.168.1.1     0.0.0.0         UG    100    0        0 br0

Introducción.

Linux CentOS utiliza Yum como herramienta para administrar sus paquetes, de manera análoga a como Debian utiliza al Aptitude.

A continuación se describe el breve proceso que se debe realizar para actualizar para actualizar los paquetes y el sistema operativo desde la línea de comando utilizando esta herramienta.

Procedimiento.

Verificar si hay actualizaciones disponibles.

$ yum check-update

Descargar e instalar las actualizaciones disponibles.

$ sudo yum update

Enlaces.

• yum – Yellowdog Updater Modified.
  http://yum.baseurl.org/
• CentOS – The Community ENterprise Operative System.
  http://www.centos.org/

Introducción.

Por defecto en Linux CentOS, hijo de RedHat, la configuración del comando sudo viene restringida.  Su filosofía es la de utilizar al usuario root directamente.  Si intentamos ejecutar cualquier comando mediante sudo se obtiene siempre este mensaje de error.

xxxxx is not in the sudoers file.  This incident will be reported.

Quienes utilizamos Ubuntu, hijo de Debian, estamos acostumbrados a un usuario root sin contraseña y a utilizar el sudo cada vez que se va a desarrollar alguna actividad de administración que requiera los privilegios del superusuario. A continuación se detallan los pasos necesarios para configurar de esta manera el comportamiento del comando sudo.

Procedimiento.

Configuración de sudoers.

Realice los pasos de esta sección como usuario administrador.

$ su – # visudo

Remueva el comentario inicial de la siguiente línea según como se muestra a continuación.

## Allows people in group wheel to run all commands
%wheel    ALL=(ALL)    ALL

Autorización a los usuarios.

Utilizando las herramientas de administración gráficas.

Ejecute la herramienta de administración de usuarios y grupos.

Administración de los usuarios y los grupos

Seleccione las preferencias del Administrador de Usuarios y Grupos mediante el siguiente menú.

Edit > Preferences.

Remueva la marca de la casilla de verificación llamada Hide system users and groups.

Mostrar los usuarios y grupos del sistema

Seleccione la hoja Groups y en ella ubique al grupo wheel y presione el botón de Properties en la parte superior.

Editar las propiedades del grupo wheel.

Seleccione los usuarios que estarán autorizados para ejecutar el comando sudo y presione el botón de Ok .

Agregar usuarios al grupo wheel.

Utilizando las herramientas de administración de línea de comando.

# usermod -G wheel jimezam

Listo!

Aposteriori.

Si se desea una aproximación un poco mas cercana a la forma como Debian maneja este tipo de autorizaciones, puede que le sea interesante bloquear el acceso directo al usuario root mediante su contraseña.  Para hacer esto ejecute el siguiente comando.

$ sudo passwd -l root

De esta manera no será posible iniciar sesión de ninguna manera con el usuario root y las tareas administrativas sólo podrán ser ejecutadas mediante la invocación del sudo por los sudoers, es decir, por los usuarios que se hayan inscrito en el grupo wheel. Este procedimiento se revierte fácilmente al asignarle una nueva contraseña al usuario root con passwd.

Introducción.

A continuación se realizará la instalación de un Linux CentOS 5.4 básico en una máquina virtual basada en KVM utilizando LibVirt.

Preparación preliminar.

• La infraestructura necesaria para la virtualización basada en KVM se encuentra instalada y configurada.
• Se ha descargado la imagen ISO de la última distribución (5.4 en este caso) de Linux CentOS de su sitio web.
  http://www.centos.org/modules/tinycontent/index.php?id=15
• La imagen ISO de Linux CentOS se ha ubicado en /u/isos.
• La imagen del disco duro de la máquina virtual se creará en /u/vms.
• La red de la máquina virtual se implementará sobre una interfaz puente (br0) en el huésped.  Puede utilizarse también la configuración de NAT por defecto de KVM sin nigún problema.
• La máquina virtual (dominio) será identificada por la etiqueta centos-general.
• Se le asignarán 256MB de memoria RAM y un disco duro de 7GB a la máquina virtual.

Creación de la máquina virtual.

$ virt-install \
–connect qemu:///system \
-n centos-general \
-r 256 \
–os-type linux \
–os-variant generic26 \
–hvm \
–cdrom /u/isos/CentOS-5.4-i386-bin-DVD.iso \
–network bridge:br0 \
–disk path=/u/vms/centos-general.img,size=7 \
–vnc –noautoconsole \
–accelerate

Conexión a la interfaz gráfica de la máquina virtual.

$ /usr/bin/virt-viewer -c qemu+ssh://IP_SERVIDOR/system centos-general

• Si la conexión es remota utilice el protocolo qemu+ssh y reemplace la constante IP_SERVIDOR por la dirección IP o nombre FQDN del huésped.
• En caso de realizarse una conexión local utilice el protocolo qemu y obvie la dirección del servidor.

Instalación normal de Linux CentOS.

Realice la instalación habitual de Linux CentOS 5.4 mediante el visor de la máquina virtual recién invocado.

Introducción.

Cuando se instala KVM se crea una red privada por defecto (192.168.122.0) para las máquinas virtuales las cuales sólo son accesibles desde el mismo huésped.

(revisar) Si lo que se desea, como en mi caso, es que las máquinas virtuales obtengan una dirección del servicio de DHCP y puedan ser accedidas desde la red LAN como un servidor real es necesario crear un puente en la interfaz de red del servidor para permitirle a las máquinas virtuales acceder a la red física a través de este.

El procedimiento para hacer esto es simple y se describe a continuación.

Advertencia acerca de la red inalámbrica.

Utilizando el método convencional para la creación de puentes no es posible utilizar interfaces de red inalámbricas ya que sus tarjetas no permiten realizar ip spoofing necesario para su implementación.  Es necesario entonces contar con un acceso alámbrico a la red LAN para poder realizar el procedimiento descrito en este artículo.

Investigando en Internet encontré varios foros en los que se menciona que es posible dar solución a este problema sin utilizar el procedimiento estándar sino utilizando aproximaciones alternativas que no estarían supeditadas a la red alámbrica, sin embargo después de cuatro días de intentos y pruebas no me funcionaron así que tuve que utilizar la red cableada.  Las aproximaciones alternativas que sugieren mayor posibilidad de éxito son las siguientes.

• Establecer un proxy ARP.
  http://savvyadmin.com/virtualbox-wireless-bridging/
• Utilizar parprouted para establecer el puente de red.
  http://www.daryl.mu/2008/08/21/howto-set-up-wireless-networking-between-virtualbox-vms-on-ubuntu-hardy-heron/

En mi caso lo que revisió mayor dificultad para realizar las pruebas de estos procedimientos resultó, mas que la implementación de los mismos que de por si es bastante simple, la configuración de las máquinas KVM (he utilizado libvirt para su manipulación) para que utilicen la nueva interfaz de red ya que los ejemplos mejor descritos que encontré hacían referencia a Virtualbox y para KVM su configuración es notoriamente diferente.

Procedimiento.

Configurar el huésped (servidor de máquinas virtuales).

Instalar el paquete de utilidades para la creación de puentes de red.

$ sudo apt-get install bridge-utils

Editar el archivo de configuración de interfaces de red para agregar la configuración del puente.

$ sudo vi /etc/network/interfaces

Este procedimiento se puede realizar de dos maneras: de manera estática especificando la información precisa de conexión a la red o de manera dinámica permitiendo adquirir la configuración automática desde un servidor DHCP.

De manera estática se realiza de la siguiente manera.

auto br0
iface br0 inet static
address 192.168.1.10
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0

De manera dinámica se realiza de la siguiente manera.

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0

En ambos casos se está creando el puente br0 para acceder a la red a través de la interfaz eth0 (red alámbrica).

Reiniciar la configuración de red para tomar en cuenta los cambios recién realizados.

$ sudo /etc/init.d/networking restart

Verificar el estado de los cambios.

$ ifconfig

br0 Link encap:Ethernet  HWaddr 00:24:21:b6:12:11
inet addr:192.168.1.99 Bcast:192.168.1.255  Mask:255.255.255.0
inet6 addr: fe80::224:21ff:feb6:1211/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:991 errors:0 dropped:0 overruns:0 frame:0
TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:62573 (62.5 KB)  TX bytes:14537 (14.5 KB)

eth0 Link encap:Ethernet  HWaddr 00:24:21:b6:12:11
inet addr:192.168.1.99 Bcast:192.168.1.255  Mask:255.255.255.0
inet6 addr: fe80::224:21ff:feb6:1211/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:991 errors:0 dropped:0 overruns:0 frame:0
TX packets:898 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:77339 (77.3 KB)  TX bytes:67197 (67.1 KB)
Interrupt:27

Nótese como aparece la nueva interfaz de red del puente (br0) que toma igual configuración de red de su destino (eth0).

Configurar el invitado (máquinas virtuales).

Editar la información de especificación de la máquina virtual.

$ virsh edit IDENTIFICADOR_DOMINIO

Modificar la sección de la configuración de red (<interface>) con el siguiente estilo.

<interface type=’bridge’>
<source bridge=’br0‘/>
<model type=’virtio’/>
<mac address=’00:11:22:33:44:55′/>
</interface>

Actualice la información de la máquina virtual en el Hypervisor e iníciela.

$ virsh -c qemu:///system define /etc/libvirt/qemu/IDENTIFICADOR_DOMINIO.xml

$ virsh -c qemu:///system start IDENTIFICADOR_DOMINIO

Para confirmar el éxito de la configuración, en la máquina virtual consulte su dirección IP, la cual deberá coincidir con la especificada durante la configuración (estática) o la proporcionada por el servidor DHCP (dinámica).

Acerca de la dirección MAC de las interfaces virtuales.

Siempre es conveniente especificar una dirección MAC y que esta sea única entre las diferentes máquinas virtuales para evitar cualquier tipo de confusión.  Con respecto a esta dirección se recomienda que el primer valor sea par (como por ejemplo 00).

Para facilitar la generación de direcciones MAC al azar, la documentación de KVM en Ubuntu incluye un script muy útil.

$ sudo apt-get install randomize-lines

$ vi ~/bin/kvmGenMac               # Almacénelo donde desee.

#!/bin/sh
echo -n "54:52:00"
for i in 1 2 3; do
    echo -n ":"
    for j in 1 2; do
        for k in 0 1 2 3 4 5 6 7 8 9 A B C D E F; do
            echo $k
        done|rl|sed -n 1p
    done|while read m; do
        echo -n $m
    done
done
echo

$ chmod +x ~/bin/kvmGenMac

Para ejecutarlo simplemente invoque el shell y obtenga la dirección MAC al azar de la salida estándar.

$ ./bin/kvmGenMac

Enlaces.

• KVM Networking.
  https://help.ubuntu.com/community/KVM/Networking
• libvirt Virtualization API.
  http://libvirt.org/