Low-cost High Availability Internet Service Architecture

Estoy trabajando desde hace unas semanas en un proyecto para proveer a Pymes de una infraestructura que permita alta disponibilidad para sus firewalls y sus enlaces a internet.

En otras palabras, permitir contar con dos enlaces a internet, provistos por dos ISP diferentes, los cuales llegan a un clusters de firewalls Linux. Si uno de los nodos falla, el segundo nodo del cluster pasara a modo activo sincronizando todas las conexiones, de manera lo mas transparente posible para el usuario.

La premisa es proveer una infraestructura de seguridad y acceso, tolerante a fallas tanto de los enlaces, como del hardware.

Comencé a trabajar en este proyecto hace un par de semanas, y hoy ya tengo un laboratorio virtual funcionando, basado en un trabajo del Dr. Michael Schwartzkop, llamado "HOWTO Con gure a High Available Firewall Cluster with
fwbuilder ".

Actualmente el proyecto se encuentra avanzado en un 50%, esto significa que el cluster esta funcionando, manteniendo las tablas de conexiones sincronizadas.
El siguiente 50% del trabajo es lograr que esta infraestructura, pueda utilizar dos enlaces a internet y brindar alta disponibilidad en caso de falla de uno de ellos.

El objetivo final ( quitando la redundancia de los switches, para comodidad del gráfico ) seria el siguiente esquema :


El cluster

Wikipedia nos da una definicion del termino cluster, aplicado a la alta disponibilidad.

Un cluster de alta disponibilidad es un conjunto de dos o más máquinas que se caracterizan por mantener una serie de servicios compartidos y por estar constantemente monitorizándose entre sí. Podemos dividirlo en dos clases:

Alta disponibilidad de infraestructura: Si se produce un fallo de hardware en alguna de las máquinas del cluster, el software de alta disponibilidad es capaz de arrancar automáticamente los servicios en cualquiera de las otras máquinas del cluster (failover). Y cuando la máquina que ha fallado se recupera, los servicios son nuevamente migrados a la máquina original (failback). Esta capacidad de recuperación automática de servicios nos garantiza la alta disponibilidad de los servicios ofrecidos por el cluster, minimizando así la percepción del fallo por parte de los usuarios.

El open source cuenta con un proyecto llamado HA-Linux que deribo en el proyecto Pacemaker, cuyo fin es contar con una solucion de clustering que promueva la confiabilidad, disponibilidad y los servicios necesarios para brindar soporte a este tipo de soluciones.

El interior de un cluster

Si bien anteriormente habia trabajado con clusters, siempre fue desde el lado del usuario, separado por una capa lo suficientemente inteligente como para ignorar el intrincado mecanismo que mantiene a estos dispositivos funcionando.

Si pudiéramos tomarle una radiografia a nuestro cluster de firewalls, seguramente veriamos el siguiente esquema.

OPENAIS es un servicio que provee comunicacion entre los nodos de un cluster, de manera de conocer cuando estos equipos estan presentes o no.

PACEMAKER es la capa que se encarga de manejar los recursos de un cluster, tambien conocido como CRM ( Cluster Resource Manager ), es quien se encarga de arrancar y parar los servicios de un cluster ( Webserver, Firewall, Base de Datos ).

La interaccion entre estas dos capas permite que PACEMAKER active los servicios en un nodo PASIVO, al momento de OPENAIS detectar que el nodo ACTIVO desaparecio.

CONNTRACK no forma parte de la inteligencia del cluster, pero es quien mantiene sincronizados las tablas de conexion de dos firewalls de manera que si uno cae, el PASIVO mantiene las conexiones que tenia el ACTIVO.

Configuración Básica

Mi trabajo tiene minimas diferencias con el realizado por Mr Schwartzkop, el utilizo Debian y Hearbeat para la mensajeria entre Pacemaker y los Nodos,
yo realice la instalación con OpenSUSE 11 y OpenAIS.

Vale aclarar que los firewalls no sufrieron ningun hardening, por lo tanto no estan en este momento preparados para entrar en produccion.


Los paquetes instalados en los nodos :

OpenSUSE 11.2
pacemaker - 1.0.1.20-3
pacemaker-1.4-15.1
openais - 0.80.3 - 20.2
libopenais - 0.80.3 - 20.2
conntrack-tools - 0.9.13-1.1
fwbuilder 3.0

Luego de instalar ambos equipos se configuraran las interfaces :

Las IP del cluster no deben configurarse a nivel Sistema Operativo, se definiran en el CRM.

Por el momento no habilite una DMZ.

Para este laboratorio las interfaces de red en VirtualBox estn configuradas de la siguiente manera :

La interfaz externa esta en modo bridge, de manera de poder tener una IP publica y las demas interfaces en modo de red interna.

Es recomendable, luego de aplicar las actualizaciones, desconectar los equipos de internet y deshabilitar el firewall que trae OpenSUSE.

Configurar la resolucion de nombres estatica mediante el archivo /etc/hosts, en cada uno de los nodos.

Probar que hay conectividad entre las interfaces de los equipos mediante un ping.


El siguiente paso es configurar OPENAIS, el layer de mensajeria entre los nodos y el CRM.

La configuracion de OpenAIS esta dada por dos pasos.

Generacion de claves en cada nodo :

FW1:~ # ais-keygen

FW2:~ # ais-keygen

Configuracion del archivo /etc/ais/openais.conf

aisexec {
user:   root
group:  root
}
service {
name: pacemaker
ver:  0
}
totem {
version: 2
token:          1000
hold: 180
token_retransmits_before_loss_const: 20
join:           60
consensus:      4800
vsftype:        none
max_messages:   20
clear_node_high_bit: yes
secauth: off
threads: 0
interface {
    ringnumber: 0
    bindnetaddr: 10.1.1.0
    mcastaddr: 226.94.1.1
    mcastport: 4000
}
}
logging {
debug: off
fileline: off
to_syslog: yes
to_stderr: no
syslog_facility: daemon
timestamp: on
}
amf {
mode: disabled
}

Este archivo es idéntico en ambos equipos y podemos copiarlo desde uno de los FW al siguiente nodo.


Configuracion de Pacemaker

El siguiente paso es configurar en el CRM los recursos que manejara el Cluster, es decir aquellos que activara en caso de ser informado por OPENAIS que uno de los nodos activos, dejo de funcionar.


En nuestro caso tendremos tres recursos definidos ( en el futuro se pueden agregar mas )

- IPexterna
- IPinterna
- Firewall

Los recursos que maneja el Cluster aparecen en la siguiente imagen :


La definición de los recursos se puede hacer por medio de una interfaz gráfica, o por modo texto. A los efectos del laboratorio opte una interfaz gráfica, pero en producción, un FW nunca debería tener X Windows instalado. Esto solo lo haríamos en una consola de administración remota.

Previo a la configuración de los recursos, ingresamos la password al usuario que se encarga de manejar el cluster.

FW1# passwd hacluster
FW2# passwd hacluster


Luego ingresamos el comando para acceder a la interfaz grafica :

FW1# crm_gui

Luego creamos los recursos, en la siguiente imagen vemos los atributos para el recurso resIPext.

repetimos los pasos en ambos nodos.

El recurso firewall, en verdad es un script del tipo LSB que colocaremos en el directorio de arranque de servicios. /etc/init.d/firewall.
Los recursos basados en Linux Standards Base (LSB) Scripts, deben cumplir con las especificaciones LSB. Por ejemplo debeb tener varias acciones implementadas : al menos start, stop, restart, reload, force-reload, y status Tal como estan excplicadas en http://www.linuxbase.org/spec/refspecs/LSB_3.0.0/LSB-Core- generic/LSB-Core-generic/iniscrptact.html.


Una vez terminado de crear los recursos, debemos crear el script LSB para el firewall.

#! /bin/bash
#PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
NAME=fwbuilder
DESC="Firewall Builder"
DEFAULT=/usr/bin/fwbuilder
IPTABLES=/usr/sbin/iptables
#test -f $DEFAULT || exit 0
#grep -s -q 'START_FWBUILDER=yes' $DEFAULT || exit 0
# SCRIPT_DIR=$(grep -s "^[[:space:]]*FWBSCRIPT_DIR" $DEFAULT | cut -d "=" -f 2)
# SCRIPT="$SCRIPT_DIR/$(hostname -s).fw"
SCRIPT=/etc/firewall.fw
NAME=fwbuilder
stopfw() {
#Set accept for default tables
# This is definitely NO good policy. DO NOT USE in production environment.
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT
#Flush tables
$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t mangle
$IPTABLES -X
$IPTABLES -X -t nat
$IPTABLES -X -t mangle
}
#test -x $SCRIPT || exit 0 test -x $IPTABLES || exit 0
set -e
case "$1" in
start)
echo -n "Starting $DESC: "
/usr/sbin/conntrackd -c
/usr/sbin/conntrackd -f
/usr/sbin/conntrackd -R
/usr/sbin/conntrackd -B
$SCRIPT 2>/dev/null
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
/usr/sbin/conntrackd -t
/usr/sbin/conntrackd -n
echo "0" > /proc/sys/net/ipv4/ip_forward
stopfw
echo "$NAME."
;;
status)
if [ `cat /proc/sys/net/ipv4/ip_forward` = "1" ]
then
echo "$NAME forwarding"
exit 0
else
echo "$NAME not forwarding"
exit 3
fi
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|restart|status}" >&2
exit 1
;;
esac
exit 0

Creamos un script similar para Conntrackd, el servicio que mantendra sincronizado a IPTABLES.

La configuracion de conntrack se realiza mediante el archivo /etc/conntrackd/conntrackd.conf

Sync {
Mode FTFW {
}
Multicast {
IPv4_address 225.0.0.50
Group 3780
IPv4_interface 10.1.1.1
Interface eth1
}
}
General {
Nice -1
HashSize 8192
HashLimit 65535
LogFile on
Syslog on
LockFile /var/lock/conntrack.lock
UNIX {
Path /var/run/conntrackd.ctl
Backlog 20
}
NetlinkBufferSize 262142
NetlinkBufferSizeMaxGrowth 655355
Filter {
Protocol Accept {
TCP
}
Address Ignore {
IPv4_address 127.0.0.1 # loopback
}
}
}

Conntrackd mantiene dos tablas de conexiones, la interna y la externa.
La interna, contiene las conexiones pertenecientes al equipo donde se ejecuta conntrackd, la externa contiene las conexiones que recibe del equipo gemelo.
Si el nodo externo care, el puede recuperar las conexiones, apartir de esta ultima tabla.




Ya tenemos el CLUSTER de Firewalls al que solo resta agregar las reglas de filtrado.


Las reglas son generadas mediante FWBuilder una excelente herramienta para manejo de IPTABLES.
Una vez generadas las reglas se deben aplicar a ambos equipos.
En la siguiente imagen vemos la policy, para el FW1.

En la primer linea tenemos la regla 0 de antispoofing, aquella que deniega el acceso de paquetes con direccion fuente igual a cualquiera de nuestras redes internas.
La regla 3 permite la comunicacion entre las interfaces de syncronizacion de los firewalls.

La regla 4 evita la conexion al FW

La regla 5 es en donde definimos los permisos de acceso para la red interna y denegamos todo lo no permitido.


Por ultimo un pequeño vídeo mostrando como funciona el cluster. ( disculpen la calidad, pero es mi primer intento !!! ). Tengan paciencia, que demora en cargar.









Ahora resta, trabajar sobre la alta disponibilidad de los enlaces, espero pronto tener un post al respecto.