Linux como router: configuraciones básicas

Para poder configurar un firewall en Linux, primero es necesario convertirlo en un router. Hoy aprenderemos cómo hacerlo!

Hace tiempo vengo trabajando en un nuevo curso de redes, sobre firewalls, esta vez con nftables en GNU/Linux, y estoy realizando las simulaciones de red con GNS3.

Ahora bien, para poder configurar un sistema Linux como firewall, por ejemplo, separando una red LAN de Internet, es necesario que ese sistema actúe como si fuera un router de red.

Eso no es una tarea que realice Linux de manera predeterminada, por lo que deberemos tocar algunos parámetros de configuración básicos.

¿Querés saber más de Redes TCP/IP y protocolos de Internet?
Sumate a nuestro curso 📚!

Para tomar el curso de firewall y realizar las práctica, ya sea en esquemas de red virtualizados o en redes reales, será necesario llevar a cabo estos simples pasos para que nuestro sistema GNU/Linux se convierta en un router potente y altamente configurable.

Un router típico – Direccionamiento de la red

Para esta práctica vamos a suponer el siguiente esquema de red:

Tenemos una red LAN, identificada por un solo nodo para el caso del ejemplo, con su direccionamiento:

• Dirección IP: 192.168.30.123/24
• Puerta de enlace predeterminada: 192.168.30.1/24

A su vez, tenemos nuestro router Linux con dos interfaces de red:

• Una que conecta a la LAN:
  • Interfaz: enp2s0
  • Dirección IP: 192.168.30.1/24
• Una que conecta a Internet:
  • Interfaz: ens1
  • Dirección IP y enrutamiento público.

En el ejemplo el router está conectado a Internet directamente al proveedor de servicio.

En mi caso particular, al tratarse de una simulación de red en GNS3, el direccionamiento público es, en realidad, una IP de mi red LAN local, privada, que a su vez está conectada a Internet. En otras palabras, mi red LAN hace las veces de ISP de este router virtual.

A fines prácticos no hay diferencia con una configuración de un router Linux físico.

¿Qué hace un Linux como router? – Enrutamiento

El esquema de red es simple:

• Los equipos de la LAN usan como puerta de enlace predeterminada al router Linux. Eso obviamente se configura en cada equipo, ya sea manualmente, o mediante DHCP (esa es historia para otro post, si les interesa me avisan!).
• El router Linux accede a los equipos de la LAN por estar conectados localmente al mismo segmento físico (por ejemplo, utilizando un switch).
• El router usa como puerta de enlace predeterminada al router del ISP, su siguiente hop en la red.

Vamos a suponer que el direccionamiento y el enrutamiento de los equipos ya está configurado, para no extendernos mucho en el post. Si les interesa saber cómo configurarlo, me avisan y hacemos algo! 🙂

Reenvío de tráfico entre interfaces

El siguiente paso es habilitar el reenvío de tráfico entre interfaces de red en Linux.

Para ello debemos modificar un parámetro de configuración del núcleo Linux.

Tenemos dos formas de hacerlo:

• Volátil/Temporal, cambiando el parámetro en tiempo de ejecución, de modo que su valor se perderá con el reinicio del sistema.
• Persistente, guardando el valor del parámetro en archivos de configuración, de modo que mantendremos su valor al reiniciar. Esta opción es la más adecuada (salvo que estemos probando cosas y jugando con configuraciones).

Reenvío de tráfico volátil

Para configurar el reenvío de tráfico en las interfaces de red, debemos habilitar un flag o bandera del núcleo Linux, el archivo /proc/sys/net/ipv4/ip_forward.

Eso podemos hacerlo de la siguiente manera:

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

A partir de este momento el reenvío de tráfico estará habilitado en Linux.

Por supuesto, el valor se perderá al reiniciar, dado que el sistema de archivos /proc es virtual y se re-genera al inicio del sistema operativo.

Otra forma de realizar este cambio de manera volátil es utilizando el comando sysctl:

$ sudo sysctl net.ipv4.ip_forward=1

En cualquiera de los dos casos, podremos ver si se ha cargado el parámetro de esta forma:

$ sudo sysctl -a  | grep net.ipv4.ip_forward

Reenvío de tráfico persistente

La forma más elegante de hacerlo es modificar el valor del parámetro dentro del archivo /etc/sysctl.conf:

net.ipv4.ip_forward=1

Esto podemos modificarlo, o añadir la línea en cuestión, dentro del archivo /etc/sysctl.conf.

Al reiniciar el sistema se activará el flag /proc/sys/net/ipv4/ip_forward de manera automática.

Si hemos modificado el archivo y no queremos reiniciar el sistema, podemos recargar los parámetros del núcleo de esta forma:

$ sudo sysctl -p

Al igual que en el caso de la modificación volátil, podemos usar este comando para verificar que el valor se ha cargado correctamente:

$ sudo sysctl -a  | grep net.ipv4.ip_forward

¿Y si nuestro Linux como router usa IPv6?

El procedimiento es exactamente igual al de IPv4, lo único que cambia es el parámetro que activa el reenvío en IPv6:

net.ipv6.conf.all.forwarding=1

NAT / Masquerading

Finalmente, un detalle importante: el NAT, o Network Address Translation (Traducción de dirección de red).

En una red local usamos direccionamiento IP privado, por ejemplo, direcciones del rango 192.168.0.0/16. Estos rangos de direcciones privadas no son enrutables en Internet, es decir, si un paquete de un equipo de la LAN, que tiene su dirección IP origen en el rango privado, sale a Internet, su respuesta no podrá llegar.

El paquete podrá viajar por Internet desde el cliente hasta el servidor remoto, pero el servidor remoto intentará responderlo a la dirección IP de origen que figura en el paquete, y dicha respuesta no llegará, ya que seguramente el servidor no estará conectado al rango de direcciones IP locales a la que pertenece el cliente.

Y si indicamos en la consulta que nuestra IP es de un tercero, ¿el servidor enviará la respuesta a este otro host? Y si la consulta es una inundación o ataque? 🤔
Si querés aprender más de Redes TCP/IP sumate a nuestro curso!

Para ello existe el NAT en modo sNAT (Source NAT), o MASQUERADE.

El NAT le permite al router cambiar la IP de origen de los paquetes saliente, por su propia IP pública que le ha asignado el ISP (dinámica o estática).

De este modo, el tráfico que envíen los clientes con destino un servicio en Internet, lo recibirá dicho servidor como si viniera desde la IP pública del router. El servidor lo responderá, la respuesta llegará al router, y el router, que sabe que esa conexión la inició un cliente desde una IP privada, cambiará la IP destino del paquete que recibió por la IP del cliente, y se lo hará llegar.

¿Y esto cómo se hace?

De varias formas… pero como nos gusta estar actualizados en Linux, vamos a hacerlo usando nftables 😉

En primer lugar debemos crear, en nuestro nftables, una tabla para nat, y una chain de postrouting, y finalmente cargaremos la regla de sNAT en dicha chain. Todos los pasos acá:

#/usr/bin/bash

# Creamos la tabla NAT, en este caso, la llamé nat_juncotic
nft add table nat_juncotic

# Creamos la chain de postrouting, en este ejemplo, postruteo
nft 'add chain nat_juncotic postruteo { type nat hook postrouting priority 100 ; }'

# Añadimos una regla para aplicar NAT a todo el tráfico que provenga de la LAN y salga a Internet desde la interfaz ens1 (ver diagrama)
nft 'add rule nat_juncotic postruteo ip saddr 192.168.10.0/24 oif ens1 snat to 192.168.100.30'

¿Y si no sabemos la IP pública de nuestro router?

No hay problema, en lugar de especificarlo con snat, podemos aplicar la IP pública que tenga el router en ese momento usando masquerading.

En el script anterior solo basta cambiar la última regla por esta:

nft 'add rule nat_juncotic postruteo ip saddr 192.168.10.0/24 oif ens1 masquerade'

Persistencia en el sNAT

Estas configuraciones de nftables las hice por comandos, por lo que es volátil, y se perderá al reiniciar.

Para lograr la persistencia debemos modificar los archivos de configuración de nftables. Esto a veces depende de la distro, así que voy a configurarlo particularmente para Debian 12, si usan otra distro me comentan.

En Debian el archivo de configuración principal de nftables es /etc/nftables.conf. Allí podemos cargar directamente la configuración de nuestro snat, o podemos crear un directorio /etc/nftables.conf.d/ donde cargar el archivo de configuración, y luego incluirlo en el archivo principal.

Esta segunda opción es más elegante y ordenada, pero para simplificarlo en este ejemplo, voy a hacerlo directamente en /etc/nftables.conf 🙂

Primero, si ya ejecutamos los comandos de creación de tabla, cadena y regla, podemos listar la configuración de esta forma:

$ sudo nft list table nat_juncotic
table ip nat_juncotic {
	chain postruteo {
		type nat hook postrouting priority srcnat; policy accept;
		ip saddr 192.168.10.0/24 oif "ens1" masquerade
	}
}

Aquí se ve el formato en bloque del ruleset de nftables. Copiamos su salida y la añadimos al archivo principal de configuración.

Esto podemos hacerlo en un solo comando de esta forma:

$ sudo su -c "nft list table nat_juncotic >> /etc/nftables.conf "

Verificar que la redirección de salida sea de tipo «Append» >> para no sobreescribir todo el archivo!

Y luego, activamos el servicio para que se corra al siguiente reinicio del sistema:

$ sudo systemctl enable nftables.service

GNU/Linux como router: conclusiones

Con estos pasos:

• Direccionamiento
• Enrutamiento
• Reenvío de tráfico
• sNAT

Ya tendremos nuestro sistema Linux listo para poder utilizarlo como firewall de red!

Una nota adicional respecto de la configuración del firewall: Esto puede realizarse también con iptables, o cualquier frontend de iptables/nftables. Yo he usado nftables por ser la versión más actualizada del framework de filtrado de tráfico del núcleo Linux.

Espero que les sirva!! Cualquier duda ya saben, me comentan! (datos abajo)

Hasta la próxima!