Es muy común que debido al alto tráfico que se genera entre los nodos trabajadores de un clúster y su nodo principal, estos se separen en una red independiente y el nodo principal, con dos interfaces de red, actúe como puente entre los clientes en la red LAN y los nodos trabajadores en la red finalmente oculta.

La configuración de esto es tan simple como la simple conexión física de los dispositivos y la configuración de direcciones IP estáticas para los nodos trabajadores si es que no se desea instalar un servidor DHCP en el nodo principal para que realice esta tarea a través de la interfaz de red específica.  El problema surge cuando es necesario actualizar los nodos trabajadores o en general, que estos accedan a Internet.  Como estos se encuentran en un red diferente de la LAN, no hay nada que los enrrute hacia la WAN, quedando completamente aislados.

La solución a este problema es muy fácil de implementar gracias a las características intrínsecas de enrrutamiento de Linux (y en general de los sistemas operativos *nix).  Simplemente es necesario indicarle al nodo principal que actúe como enrrutador entre sus interfaces de red: red LAN y red de nodos trabajadores, pudiéndose aplicar los controles que se consideren necesarios a través del uso de iptables.

El panorama.

Estructura general del cluster

El nodo principal del cluster cuenta con dos interfaces de red: eth0 que se comunica con la red LAN de la organización y eth1 que se conecta con los nodos trabajadores, los cuales sólo cuentan con una única interfaz de red eth0.  Estos últimos se encuentran aislados del exterior ya que no son enrrutados inicialmente hacía la red LAN y eventualmente hacia Internet.

Implementación del enrrutamiento.

Configuración en el nodo principal del cluster.

Este actuará como enrrutador para la información enviada desde los nodos trabajadores y permitirles entonces acceder a las redes exteriores.  Para es necesario implementar en él las siguientes modificaciones de configuración.

Activar el envío de paquetes del kernel.

Esto se puede implementar de manera temporal, es decir, esta modificación no perdurará al reinicio del sistema, mediante la ejecución del siguiente comando.

# echo 1 > /proc/sys/net/ipv4/ip_forward

O puede implementarse de manera permanente mediante la edición de los parámetros del kernel de la siguiente manera.

# vi /etc/sysctl.conf

net.ipv4.ip_forward = 1

Esta último método puede verifcarse mediante la ejecución del siguiente comando en el shell.

# sysctl -p | grep ipv4

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1

Establecer la regla de filtrado.

# iptables -t nat -A POSTROUTING -o eth0 -s 192.168.56.0/24 -j MASQUERADE

Esta instrucción le indica al nodo principal que permita el paso de los paquetes que vienen desde la red de los nodos trabajadores (192.168.56.0/24) hacía la otra red, en este caso la LAN (192.168.1.0), que se accede a través de la interfaz de red eth0.

Esta modificación desde la línea de comando no es persistente, por lo cual se deberá configurar en alguno de los archivos que se ejecutan al inicio.  Probablemente el mejor sitio sea en /etc/sysconfig/iptables, sin embargo debe tenerse cuidado si se utiliza system-config-securitylevel para administrar el firewall ya que este puede sobreescribir el archivo y olvidar los cambios.

Permitir el acceso al servicio DNS.

Este paso es opcional, pero probablemente si no se lleva a cabo el enrrutamiento sea exitoso si se utilizan direcciones IP directamente mas no si se intenta acceder utilizando nombres FQDN ya que los intentos de acceso al DNS son filtrados por el nodo principal.

Para permitir el acceso al servicio DNS es necesario permitir el paso de paquetes UDP cuyo destino sea el puerto 53 de la siguiente manera.

# iptables -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT

Igual que en el paso anterior, para hacer persistente esta modificación es necesario incluírla en un archivo como /etc/sysconfig/iptables o realizarla con el system-config-securitylevel si se utiliza.

Configuración de los nodos trabajadores.

Es necesario finalmente indicarle a los nodos trabajadores que el nodo principal del cluster será a partir de ahora su nueva puerta de enlace.  Para hacer esto es necesario modificar el siguiente parámetro de su configuración con la dirección IP del servidor principal configurado anteriormente.

GATEWAY = 192.168.56.100

Esta modificación puede realizarse uno de los siguientes puntos de configuración de los nodos trabajadores.

1. El archivo /etc/sysconfig/network.
2. El archivo /etc/sysconfig/network-scripts/ifcfg-eth0.

Si el cambio se aplica en el primero de ellos, la modificación tiene un alcance global sobre todas las interfaces de red.  Si se aplica sobre el segundo archivo, la modificación será específica para la interfaz de red eth0.  En el caso de los nodos trabajadores, estos sólo tienen una única interfaz de red así que ambas opciones tienen igual implicación.

Finalmente es necesario reiniciar el servicio de red para garantizar que los cambios realizados tengan efecto.

# /etc/init.d/network restart

echo 1 > /proc/sys/net/ipv4/ip_forward

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

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/

Haciendo -muchas- pruebas con la configuración de red de las máquinas virtuales utilizando KVM empecé a tener un extraño problema.  La interfaz de red habitual, eth0, empezó a desaparecerse de la máquina virtual en la que estaba haciendo las pruebas.  Después de una inspección rápida a los mensajes del sistema encontré que había sido renombrada la interfaz a eth2.

$ dmesg | grep eth0

udev: renamed network interface eth0 to eth2

El problema.

En las pruebas que había hecho varias veces había cambiado la configuración de red de la máquina virtual, cambiando también la dirección MAC de la tarjeta de red virtual que KVM le asignaba al dominio provocando que al parecer, el sistema operativo se confundiera pensando que tenía todas esas tarjetas y sólo al inicio cuando verificaba las interfaces se daba cuenta cual era la tarjeta activa.

La solución.

$ vi /etc/udev/rules.d/70-persistent-net.rules

Remueva o comente las líneas correspondientes a las tarjetas de red con que ya no cuenta el servidor dejando únicamente la correspondiente a la MAC en uso.

Reinicie el servicio de red, el servidor o máquina virtual si es posible.

Enlaces.

• WTH: eth0 got renamed to eth2 after an upgrade.
  http://tadek.pietraszek.org/blog/2008/03/04/wth-eth0-got-renamed-to-eth2-after-an-upgrade/

Algunas veces esta caracteristica es util, sobre todo cuando estamos instalando la maquina virtual en un equipo con conexion a Internet, pero es tan lenta que al momento de actualizar los paquetes durante la instalacion esto demora mucho tiempo. Lo mejor no es deshabilitar totalmente la interface de red de la maquina virtual, si no configurarla para acceso local y cambiar a NAT o Bridge despues de terminada la instalacion.

Si por alguna razon se deshabilito la red, nos encontraremos que asi cambiemos a NAT o Bridge nuestra maquina virtual no puede acceder a la red, para solucionar este problemas debemos hacer los siguientes pasos :

• Verificar que la maquina virtual si este reconociendo la interface de red,
  ejecutar el siguiente comando y verificar si el dispositivo de red (tipicamente eth0) aparece
  ifconfig -a
• Si el dispositivo de red no aparece verifique la configuración de la maquina virtual

Una vez verifiquemos que la maquina virtual lista la interface de red, se debe habilitar y asignar una ip dinamica o estatica y realizar las actualizacion de la lista de paquetes para realizar posteriores instalaciones :

• Editar el archivo de interfaces de red
  sudo vi /etc/network/interfaces
• Verificar que no aparezca el nombre de nuestra interface (tipicamente eth0) y adicionar las siguientes lineas :
  • Para DHCP :
    auto eth0
    iface eth0 inet dhcp
  • Para IP estatica (cambiar las direcciones a las de su red) :
    auto eth0
    iface eth0 inet static
    address 192.168.2.1
    netmask 255.255.255.0
    network 192.168.2.0
    broadcast 192.168.2.255
• Guardar y reiniciar el servicio de red
  sudo /etc/init.d/networking restart
• Listar de nuevo las interfaces y verificar que se le haya asignado IP
  ifconfig -a
• Actualizar la lista de paquetes para posteriores instalaciones
  sudo apt-get update

Pasos :

• Abrir una consola
• Editar el archivo de declaración de interfaces
  sudo vi /etc/network/interfaces
• Modificar la interface que queremos volver bridge como manual
• Adicionar definición de la nueva interface

El archivo de interfaces debe lucir como (modificar los valores ip de acuerdo a la configuración de la red y el nombre de la interface eth0 por la interface a cambiar) :

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
        address 192.168.0.100
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

Enlaces :

• Virtualization with KVM on Ubuntu 8.10
  http://www.howtoforge.com/virtualization-with-kvm-on-ubuntu-8.10