En unos firewalls con Linux hay infinitas maneras de intentar conseguir alta disponibilidad de salida a Internet, aunque todas tienen sus inconvenientes. Voy a contar un ejemplo combinando Conntrack, Iptables, Corosync, Pacemaker y un script inspirado en la solución de amperis.

Una de las soluciones que primero se vienen a la cabeza es utilizar un algoritmo de pesos con ip route según la relación de velocidad de los proveedores contratados o nuestras preferencias, configurando una ruta por defecto multicamino. Pero esto pronto empezará a dar problemas en según qué conexiones o aplicaciones al encontrarse que según qué paquetes les llegan por distintas IP públicas, como las páginas de los bancos. Y aunque la lógica de dividir el tráfico entre proveedores también puede hacerse con iptables y el módulo statistic, no se evita el problema del multicamino.

Justo acabo de mencionar a iptables, que si se usa también con marcado de paquetes podría dar una solución más fiable . Sin embargo esto no serviría en caso de que uno de los proveedores falle, porque eso a iptables le da igual y marcaría para un proveedor paquetes que no van a llegar, así que además se perderían. Y lo mismo ocurriría con la solución de ip route. Por lo tanto hace falta también una manera de controlar qué rutas funcionan correctamente para que sólo estas sean tenidas en cuenta.

Así pues, mi ejemplo se limita a utilizar realmente un único proveedor de salida, pero teniendo al resto siempre listos para coger el relevo y aceptando conexiones entrantes. De manera que entre que el proveedor preferido falla y el sistema es capaz de preferir temporalmente a uno de los otros pueden pasar unos segundos o minutos, según los umbrales de tolerancia de un script que monitorice los proveedores y modifique las rutas. Y para aumentar la disponibilidad se considera un cluster de dos firewalls (fw1 y fw2) con sus propias IP y otras que usarán en alta disponibilidad (HA).

Parto de un cluster debidamente configurado con estos dos proveedores:

• ISP1:
  • Interfaz: isp1
  • Red pública: 85.56.0.0/29
    • Puerta de enlace: 85.56.0.1
    • IP fw1: 85.56.0.2
    • IP fw2: 85.56.0.3
    • IP fw HA: 85.56.0.4
• ISP2:
  • Interfaz: isp1
  • Red privada: 192.168.1.0/24
    • Puerta de enlace: 192.168.1.1
    • IP fw1: 192.168.1.11
    • IP fw2: 192.168.1.12
    • IP fw HA: 192.168.1.10

Veamos las distintas partes:

Corosync – Pacemaker

No son obligatorios, pero con ellos se puede gestionar la disponibilidad de los dos firewalls y el uso de las IP de HA para los distintos proveedores con el agente IPaddr2.

Rutas

Se crean varias rutas por defecto pero de métricas distintas, tal que:

• La de menor métrica es una ruta que varía según el proveedor preferido (o estable en ese instante) y que sólo la manipula el script monitor de rutas. Por ejemplo 300.
• El resto, estáticas, con una métrica siempre superior a la dinámica que acabo de describir, pero con unos valores consecutivos y ordenados según la preferencia de proveedores. Por ejemplo 301, 302, 303,.. Estas rutas sólo se añaden y se quitan cuando se levanta o baja la interfaz correspondiente. Nunca se modifican.

default via 85.56.0.1 dev isp1 metric 300
default via 85.56.0.1 dev isp1 metric 301
default via 192.168.1.1 dev isp2 metric 302

Reglas y tablas

Para que el tráfico que venga por cada interfaz vuelva también por ella y el sistema de marcas:

# cat route-isp1
 default via 85.56.0.1 table isp1
 default via 85.56.0.1 dev isp1 metric 301
 85.56.0.0/29 dev isp1 src 85.56.0.2 table isp1

# cat rule-isp1
 fwmark 1 table isp1
 from 85.56.0.0/29 lookup isp1

# cat route-isp2
 default via 192.168.1.1 dev isp2 table isp2
 default via 192.168.1.1 dev isp2 metric 302
 192.168.1.0/24 dev isp1 src 192.168.1.11 table isp2

#cat rule-isp2
 fwmark 2 table isp2
 from 192.168.1.0/24 lookup isp2

Ojo con las IP de los campos src, que en cada firewall son distintas, puesto que son sentencias que estarán tanto si el firewall tiene o no las IP de HA.

Un script para monitorizar las rutas

Tal que:

• Haga ping a una lista de IP y en base a si funciona bien o mal considere estable o no cada proveedor.
• Tenga un proveedor preferido que siempre que funcione bien utilizará para la ruta por defecto de menor métrica.
  • Lea el proveedor preferido de un fichero que modifica otro script.
• Limpie las marcas cuando considere un proveedor como caído, para forzar a que las conexiones se restablezcan por el otro proveedor y se queden empanadas.

…continuará.