Source Routing con CheckPoint SPLAT

El Source Routing o PBR (Policy Based Routing) es una funcionalidad muy interesante cuando se dispone de más de una línea de Internet y nos interesa separar el tráfico, usando ambas líneas simultáneamente. El routing estático no nos soluciona la papeleta, pues tenemos que estar añadiendo rutas para cada IP pública que queramos enrutar por la línea que no es el default gateway. Aquí es donde entra en juego el Policy Based Routing, una funcionalidad que nos permite seleccionar un gateway en función del tráfico: origen, destino y puerto. Muchos firewalls los soportan de serie, por ejemplo Fortigate, sin embargo CheckPoint no ha sido hasta su versión más reciente de sus sistema operativo Gaia que no lo ha soportado.

Si tienes CheckPoint sobre SecurePlatform y te encuentras en esta tesitura, habrás visto que no está soportado y que la opción ISP Redundancy que ofrece CheckPoint, deja mucho que desear. No te preocupes, hay una forma de hacerlo, no está soportada oficialmente por CheckPoint, pero funciona perfectamente y la tengo operativa en producción.

Esta funcionalidad la proporciona iproute2, se trata de un conjunto de instrucciones implementadas en el núcleo de Linux a partir de la versión 2.2 que permiten gestionar el tráfico. Secure Platform de Checkpoint, está basado en Red Hat, con lo que se puede hacer uso de esta funcionalidad aunque no lo soporte el fabricante.

La clave del funcionamiento es la siguiente: iproute2 soporta múltiples tablas de enrutado, y permite asociar un determinado tráfico que cumpla con la política definida, hacia una de las tablas. En esa nueva tabla, el default gateway es diferente al de la principal, con lo que tendremos que ese tráfico saldrá por una línea diferente.

Hay que tener las siguientes cosas en cuenta:

1. Se tiene que crear una tabla por cada política, y esta tabla es independiente de la tabla del sistema
2. Una vez el tráfico se envía a la nueva tabla, ahí se tomará la decisión de por donde enviarlo. Por tanto, esa tabla a parte del default gateway, tiene que tener todas las rutas estáticas que se encuentran en la tabla del sistema, incluida las redes localmente conectadas en los interfaces.
3. Los comandos de ip route, no son persistentes al reinicio. Cuando se valide el funcionamiento correcto, se debe hacer un script de arranque que los ejecute cada vez que se reinicie el firewall.

Para entender mejor la configuración, se explicará mediante un ejemplo. Supongamos que tenemos la siguiente red.

La salida por defecto es el router 1.1.1.1, y recientemente nuestra empresa ha adquirido una nueva línea,  para separar el tráfico de navegación de los usuarios, del tráfico productivo de nuestros servidores. Como tenemos un CheckPoint sobre SecurePlatform, no podemos hacer esto con rutas estáticas. Para solucionarlo, usaremos iproute2 y crearemos una nueva tabla de enrutado en la que sacaremos el tráfico de los servidores por el nuevo router 2.2.2.1

Los pasos que a continuación voy a describir, requieren acceso expert al equipo.

1. Crearemos la segunda tabla de enrutado, simplemente añadiendola al fichero /etc/iproute2/rt_tables asignándole un identificador. La tabla del sistema es la 255, con lo que cualquier tabla con ID inferior será procesada anteriormente. Vamos a crear la tabla SRV

[Expert@fw]#echo "10 SRV" >> /etc/iproute2/rt_tables

2. Definiremos el tráfico que queremos que utilice esta nueva tabla de rutas. En nuestro ejemplo, sería todo el tráfico con origen la red de servidores.

[Expert@fw]#ip rule add from 192.168.10.0/24 table SRV

3.  Añadimos el default route a la nueva tabla.

[Expert@fw]#ip route add default via 2.2.2.1 dev eth3 table SRV

4. Añadir las rutas estáticas que fuesen necesarias. Por ejemplo, hay una serie de VPNs montadas por el router 1.1.1.1 y queremos que los servidores lleguen.

[Expert@fw]#ip route add 10.213.106.0/24 via 1.1.1.1 dev eth2 table SRV
[Expert@fw]#ip route add 10.11.12.0/24 via 1.1.1.1 dev eth2 table SRV
[Expert@fw]#ip route add 192.168.86.0/24 via 1.1.1.1 dev eth2 table SRV


5. Añadir las redes locales conectadas al firewall.

[Expert@fw]#ip route add 192.168.1.0/24 dev eth0 table SRV
[Expert@fw]#ip route add 192.168.10.0/24 dev eth1 table SRV
[Expert@fw]#ip route add 1.1.1.0/24 dev eth2 table SRV
[Expert@fw]#ip route add 2.2.2.0/24 dev eth3 table SRV


6. Hacer flush de la cache de rutas, para que empiece a estar operativa

[Expert@fw]#ip route flush cache

Y ya podemos probar. Si hacemos un traceroute desde un servidor hacia una IP pública, deberíamos ver como se va por el router 2.2.2.2. Además, comprobaremos que los servidores llegarán a todas las redes. Si a alguna no llegase, es porque os faltan definir todas las redes directamente conectadas en cada interfaz.

Si tras las pruebas, validáis el correcto funcionamiento, ya sólo queda hacerlo persistente. La forma de hacerlo es crear un script de arranque que ejecute todos los comandos anteriormente mencionados, por ejemplo crearemos el script /etc/rc3.d/S99SourceRouting con el siguiente contenido:

# Script para crear Policy Routing

# Tráfico que se va a enrutar por la nueva tabla
ip rule add from 192.168.10.0/24 table SRV

# Ruta por defecto
ip route add default via 2.2.2.1 dev eth3 table SRV

# Rutas estáticas
ip route add 10.213.106.0/24 via 1.1.1.1 dev eth2 table SRV
ip route add 10.11.12.0/24 via 1.1.1.1 dev eth2 table SRV
ip route add 192.168.86.0/24 via 1.1.1.1 dev eth2 table SRV

# Redes Locales

ip route add 192.168.1.0/24 dev eth0 table SRV
ip route add 192.168.10.0/24 dev eth1 table SRV
ip route add 1.1.1.0/24 dev eth2 table SRV
ip route add 2.2.2.0/24 dev eth3 table SRV

# Flush de cache
ip route flush cache

Hay que hacer el script ejecutable, con el comando:

[Expert@fw]#chmod +x /etc/rc3.d/S99SourceRouting

Y con esto ya tenemos el PBR o Source Routing con CheckPoint SPLAT implementado.