Ruteo dinámico con OLSR

La idea de este artículo, es explicar un poco cómo es la comunicación entre los nodos utilizando para esto rutas estáticas, y cómo se simplifica todo esto utilizando ruteo dinámico, para así llegar a lo que utilizamos en la red de BAL: el olsrd.

Contents

Ruteo dinámico con OLSR

Ruteo estático entre nodos

Mediante este método, le "enseñamos" a cada nodo o host, que camino debe utilizar para llegar a un host remoto.

Para esto imaginemos que tenemos 3 nodos: (Para simplificar las cosas suponemos que las subredes tienen mascara 255.255.255.0)

La subred del Nodo 1 es 10.4.1.x mascara 255.255.255.0
La subred del Nodo 2 es 10.4.2.x mascara 255.255.255.0
La subred del Nodo 3 es 10.4.3.x mascara 255.255.255.0

Supongamos también que existen los siguientes enlaces entre nodos:

Del Primero al Segundo por la subred 172.16.1.x
Del Segundo al Tercero por la subred 172.16.2.x

Diagrama de la red en este ejemplo

Nodo 1		Nodo 2		Nodo 3
Eth0 10.4.1.1		Eth0 10.4.2.1
Eth1 172.16.1.1	<- - ->	Eth1 172.16.1.2 (prestada por el Nodo 1)		Eth0 10.4.3.1 \|
		Eth2 172.16.2.2	<- - ->	Eth1 172.16.2.3 (prestada por el Nodo2)

Para que estos Nodos se puedan comunicar entre sí, deberemos realizar estos pasos. Primero se aplicarán caminos fijos (rutas estáticas) y luego veremos el mismo ejemplo aplicando ruteo dinámico, así veremos como nos ahorramos muchos dolores de cabeza

Generamos las rutas para comunicación entre los Nodos 1 y 2

A.1) En el primer nodo deberíamos agregar a la tabla de rutas la siguiente ruta estatica:

route add -net 10.4.2.0 netmask 255.255.255.0 gw 172.16.1.2

De esta forma, el Nodo 1 sabría como llegar a la red del Nodo 2.

A.2) En el segundo nodo deberíamos agregar la ruta:

route add -net 10.4.1.0 netmask 255.255.255.0 gw 172.16.1.1

Agregadas estas rutas, ya deberíamos estar en condiciones de poder pinguear a cualquier equipo conectado al Segundo Nodo desde el Primer Nodo, o viceversa.

Agregando rutas para el Tercer Nodo

B.1) Primero le enseñamos al Primer Nodo como llegar a la red del Tercer Nodo:

Route add -net 10.4.3.0 netmask 255.255.255.0 gw 172.16.1.2

Con esto el Primer Nodo sabe la forma de llegar al Tercer nodo.

B.2) Hacer lo mismo con el Segundo Nodo:

route add -net 10.4.3.0 netmask 255.255.255.0 gw 172.16.2.3

B.3) A su vez, el Tercer Nodo, debe conocer las demas redes:

route add -net 10.4.2.x netmask 255.255.255.0 gw 172.16.2.2

Con esto, el Tercer Nodo puede llegar a la red del Segundo Nodo.

B.4) Y también el Tercer Nodo deberia conocer como llegar a la red del Primer Nodo:

route add -net 10.4.1.0 netmask 255.255.255.0 gw 172.16.2.2

De este forma, tenemos resuelta la comunicación entre todos los nodos

¿Y... un nodo más?

Con los pasos realizados anteriormente, la configuración de la comunicación entre los nodos está hecha. Pero.. imaginen como sería esto si conectáramos un nodo más!

Listemos los pasos:

Informarle al Primer Nodo como llegar al "Cuarto" Nodo.
Informarle al Segundo Nodo como llegar al "Cuarto" Nodo.
Informarle al Tercer Nodo como llegar al "Cuarto" Nodo.
Informarle al "Cuarto" Nodo como llegar a las redes del Primer, Segundo y Tercer Nodo.

... y así -cada-vez-que-se-agrega- un Nuevo Nodo.

Agregando clientes a los nodos

Supongamos ahora queremos agregar un cliente al primer nodo.

Imaginemos que a este cliente le asignamos la ip 10.4.1.2

Una forma sencilla de que ese cliente llegue a toda la red seria definir un default gateway 10.4.1.1 con lo cual todo el trafico que salga de ese cliente a cualquier ip tenga que salir por la 10.4.1.1
```
route add default gw 10.4.1.1
```

Otra forma, y muy utilizada cuando el cliente está conectado a dos redes... por ejemplo BAL e INTERNET, seria agregar dos rutas a este cliente de la siguiente forma:

En un cliente Linux:

route add -net 10.4.0.0 netmask 255.255.0.0 gw 10.4.1.1
route add -net 172.16.0.0 netmask 255.255.0.0 gw 10.4.1.1

Si queremos dejar las rutas en forma permanente, editamos el archivo /etc/network/interfaces agregando las siguientes lineas:
```
up route add -net 10.4.0.0 netmask 255.255.0.0 gw 10.4.1.1
up route add -net 172.16.0.0 netmask 255.255.0.0 gw 10.4.1.1
```

En un cliente Windows:

route add 10.4.0.0 mask 255.255.0.0 10.4.1.1
route add 172.16.0.0 mask 255.255.0.0 10.4.1.1

Si queremos dejar las rutas en forma permanente (se graban en el registro de windows):

route add -p 10.4.0.0 mask 255.255.0.0 10.4.1.1
route add -p 172.16.0.0 mask 255.255.0.0 10.4.1.1

Con estas dos instrucciones le hemos dicho al cliente que todo el tráfico dirigido a las redes 10.4.x.x y 172.16.x.x lo debe hacer través de la 10.4.1.1, que es la IP del Nodo al cual conectó, Nodo Primero en nuestro ejemplo.

Este paso se debe hacer siempre, todo depende de como esté conectado el Cliente a la red de BAL, por eso se utiliza la forma 1 o 2, pero estos pasos no se pueden obviar. Esto sigue valiendo si empleamos ruteo dinámico en los nodos. No necesitamos tener olsrd en los clientes.

Ahora, y si ponemos algo que configure estas rutas automágicamente?

Con ustedes....

Ruteo Dinámico | olsrd

El OLSR es un protocolo para ruteo dinámico que traza las rutas en forma automática basándose en el estado del enlace. El olsrd es la implementación más popular de ese protocolo en linux.

Solo tenemos que decirle al olsrd, por qué interfaces de red debe escuchar las notificaciones de rutas, para que estas se propaguen por toda la red.

Para que esto suceda, en cada nodo debemos:

Configurar el olsrd del Primer Nodo para que escuche peticiones de ruteo por la eth0 y la eth1 (esto se hace en la linea que dice "interfaces" en el olsrd.conf) e informamos cual es la red del Nodo.
```
Interface "eth0" "eth1"
{
    Ip4Broadcast                255.255.255.255
}

Hna4
{
   10.4.1.0 255.255.255.0
}
```
Configurar el olsrd del Segundo Nodo para que escuche peticiones de ruteo por la eth0, eth1 y eth2. Y también no olvidarse de decir cual es su red (10.4.2.0 en este caso)
```
Interface "eth0" "eth1" "eth2"
{
    Ip4Broadcast                255.255.255.255
}

Hna4
{
   10.4.2.0 255.255.255.0
}
```

Configuramos el olsrd del Tercer Nodo para que escuche peticiones de ruteo por la eth0 y eth1. Y que su red es la 10.4.3.0

Interface "eth0" "eth1"
{
    Ip4Broadcast                255.255.255.255
}

Hna4
{
   10.4.3.0 255.255.255.0
}

¿Qué hace el olsrd?

Éste encuentra que hay una ip 172.16.1.2 y le avisa al segundo nodo que tiene que:

generar una ruta para poder llegar del segundo nodo a la ip 10.4.1.1 (esto por la linea "Interfaces" de la configuración del olsrd.conf)
generar una ruta para poder llegar del segundo nodo a toda la red 10.4.1.x (esto por el "HNA4" de la configuración del osrd.conf)

Así, sucesivamente se agregan automáticamente las rutas en cada uno de los Nodos, hasta que todos conocen como llegar a cualquier lado y sin necesidad de hacer ninguna configuración manual cada vez que se agrega un nuevo Nodo.

En el caso anterior hemos supuesto que todo se hacía con placas de red (alámbricas o inalámbricas).

Es importante aclarar que a través de la línea "Interface" las unicas ips que se van a rutear (publicar) son las de las interfaces (ips de las eths de la linea "Interface") y que la unica línea que publica subredes es la linea "HNA4" (donde también, si quisiéramos, podemos publicar una única ip), por lo cual si ponemos un acces point en modo bridge (seria como poner un switch), entre dos interfaces y queremos ver el equipo (al access point) desde otra subred, salvo que haya un "HNA4" que publique la ruta al mismo, el access point no va a poder ser alcanzado, salvo que se hagan rutas estáticas para llegar a él o se active un olsrd en el access point. Salvo cuando hay que acceder al equipo para reconfigurarlo, esto no es ningún problema en cuanto al funcionamiento de la red y se explica mas abajo.

Vayamos ahora a casos donde usemos APs y PCs. Veremos las diferencias entre APs en Modo Router y Bridge.

Usando un AP en modo bridge como medio de interconexión

Supongamos ahora que tenemos un AP en Modo Bridge (sin olsrd) en el Nodo 1 :

Nodo 1		Nodo 2		Nodo 3
Eth0 10.4.1.1		Eth0 10.4.2.1
Eth1 172.16.1.1	<-AP Bridge
	IP 172.16.1.3 ->	Eth1 172.16.1.2 (de Nodo1)		Eth0 10.4.3.1
		Eth2 172.16.2.2	<- - ->	Eth1 172.16.2.3 (de Nodo2)

Puesto que el AP está en Modo Bridge, todo lo que hemos visto anteriormente se sigue cumpliendo y no hay que agregar nada.

Acceder al ap desde una pc conectada a mi nodo

El único problema seria llegar al AP ya que este no tiene olsrd y no traza las rutas al mismo (ya sea para reconfigurar al AP, escanear, etc); desde un equipo que no este en la subred 172.16.1.x Imaginemos como primer caso que tenemos una PC cliente o un servidor conectada al Nodo 1 que utiliza una ip 10.4.1.2 y que hemos adoptado alguna de las soluciones explicadas en "Agregando clientes a los nodos". En este caso, agregaremos una ruta estática en la pc (route add -host 172.16.1.3 gw 10.4.1.1) y en el AP pondremos como gateway la ip 172.16.1.1.

¿Y si quisiéramos llegar a ese ap desde cualquier punto de la red?

Pues en ese caso podemos activar el olsrd del AP, para que este pueda aprender como llegar a las demás redes de todos los Nodos.

Otra manera es editar la linea hna4 del Nodo 1 poniéndola de la siguiente forma:

Hna4
{
   10.4.1.0 255.255.255.0 172.16.1.3 255.255.255.255
}

y en el AP pondremos como gateway la ip 172.16.1.1

Usando un AP en modo router como medio de interconexión

Ahora como nuevo caso supondremos que tenemos un ap en Modo Router, y siendo cliente del Segundo Nodo:

Nodo1		Nodo2		Nodo3
	AP Router
eth0 10.4.1.1	<-IP Nodo1 10.4.1.2
	IP Nodo2 10.4.2.2->	eth0 10.4.2.1
		eth1 (172.16.1.2 No la necesita mas)		eth0 10.4.3.1
		eth2 172.16.2.2	<- - ->	eth1 172.16.2.3 (de nodo2)

En este nuevo caso, suponemos que nos enlazamos a la omni del Segundo Nodo. En una configuración asi, con un AP en Modo Router, es obligatorio que el AP en Modo Router tenga activado el olsrd, sino el Primer Nodo nunca conocería las redes de los demás Nodos, ya que no tiene forma de aprenderlos, a no ser que el AP Router las haya aprendido antes gracias al olsrd instalado en los demás nodos.

Ejemplo de archivo /etc/olsrd.conf (para NodoVillar)

DebugLevel              0
ClearScreen             yes
UseHysteresis           no
LinkQualityLevel        2
LinkQualityWinSize      10
Pollrate                0.05
IpVersion               4

Hna4 { 10.4.12.160 255.255.255.224 }
#Si quiere publicar mas de una subred puede hacer por ej:
#Hna4 { 10.4.12.160 255.255.255.224 10.4.18.192 255.255.255.224 }

IpcConnect
{
     MaxConnections  0
}


#Ver version de olsrd_nameservice y ubicacion del mismo. Esto puede variar.
#El osrlr_nameservice proviene del paquete olsrd-plugin o del olsrd-plugins
#dependiendo este paquete de la version del osrd.
LoadPlugin "/usr/lib64/olsrd_nameservice.so.0.2"
{
    PlParam     "name"          "villar.villar.bal"
    PlParam     "dns-server"    ""
    PlParam     "hosts-file"    "/var/run/hosts.olsr"
    PlParam     "resolv-file"   "/var/run/resolv.conf.olsr"
    PlParam     "interval"      "120"
    PlParam     "timeout"       "3600"
}
Interface "eth1" "eth0" "ath2" "ath1" "ath0" "ra0"
{
    Ip4Broadcast                255.255.255.255

}

Ejemplo de archivo /etc/dnsmasq.conf (para NodoVillar)

interface=eth1
#Interface: en la que damos dhcpd
domain=villar.bal
dhcp-range=10.4.12.170,10.4.12.190,6h
#dhcp-range: Rango de ips que les vamos a dar a los clientes del nodo.
dhcp-leasefile=/var/tmp/dnsmasq.leases
addn-hosts=/var/run/hosts.olsr

Ejemplo de archivo /etc/hosts (para NodoVillar)

127.0.0.1       localhost.localdomain   localhost
10.4.12.161     villar.villar.bal       villar

Espero que con este breve pantallazo, puedan interpretar un poco mejor como se realizan las comunicaciones entre los todos los nodos... para nuestro caso en BuenosAiresLibre.

Atte,
MartinSeeber
MiguelAngelArgañaraz

Conflicto de IPs con proveedor de internet conectado al router con OLSR

Problema

Ultimamente han aparecido casos donde al hacer ping o traceroute a alguna ip de BAL que el router desconoce, contesta con algo que está en internet. Veamos un ejemplo:

root@y04:~# traceroute 10.4.10.3
traceroute to 10.4.10.3 (10.4.10.3), 30 hops max, 40 byte packets
 1  10.10.10.1 (10.10.10.1)  29.21 ms  75.125 ms  25.643 ms
 2  * * 190.49.3.200.telecom.net.ar (200.3.49.190)  11.426 ms
 3  * rab-hornos1-pc22.prima.net.ar (200.42.42.106)  65.981 ms  57.576 ms
 4  200-42-42-70.dup.prima.net.ar (200.42.42.70)  12.87 ms  12.083 ms  12.378 ms
 5  * * *
 6  10.100.1.26 (10.100.1.26)  32.786 ms  11.927 ms  12.666 ms
 7  10.101.4.78 (10.101.4.78)  11.217 ms  11.933 ms  11.993 ms
 8  10.4.10.3 (10.4.10.3)  23.239 ms  21.933 ms  21.489 ms

Si miramos las rutas y las interfaces en el router, vemos que están bien, o sea que efectivamente es una respuesta desde internet. Al no saber por donde salir a buscar una IP que no es de su subred, sale por el default, en este caso un modem ADSL en el puerto wan (Iface ppp0)

      root@y04:~# route -n
      Kernel IP routing table
      Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
      10.10.10.1      0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
      172.16.167.99   0.0.0.0         255.255.255.255 UH    1      0        0 vlan4
      10.4.10.97      172.16.167.99   255.255.255.255 UGH   1      0        0 vlan4
      172.16.167.96   0.0.0.0         255.255.255.240 U     0      0        0 vlan4
      10.4.11.32      0.0.0.0         255.255.255.224 U     0      0        0 br0
      10.4.10.96      172.16.167.99   255.255.255.224 UG    1      0        0 vlan4
      0.0.0.0         10.10.10.1      0.0.0.0         UG    0      0        0 ppp0

root@y04:~# ifconfig

br0       Link encap:Ethernet  HWaddr 00:13:10:36:39:B5
          inet addr:10.4.11.33  Bcast:10.4.11.63  Mask:255.255.255.224

vlan4     Link encap:Ethernet  HWaddr 00:13:10:36:39:B5
          inet addr:172.16.167.100  Bcast:172.16.167.111  Mask:255.255.255.240

ppp0      Link encap:Point-Point Protocol
          inet addr:200.55.87.56  P-t-P:10.10.10.1  Mask:255.255.255.255

Solución

Entonces ¿cómo hacemos para que no enrute los IPs desconocidos del rango de BAL por el default GW de internet?

root@y04:~# route add -net 10.4.0.0 netmask 255.255.0.0 gw 172.16.167.99

Contribuído por YairAdi gracias a MartinSeeber

Conflictos entre firewall y OLSR

Problema

OLSR necesita del puerto 698 para transmitir mensajes de estado entre nodos, si dicho puerto se encuentra cerrado por la configuración del firewall, OLSR no va a generar las rutas. Es normal que si el server se encuentra en una DMZ, queramos bloquear las conexiones entrantes, y hagamos un drop de dicho puerto sin darnos cuenta:

Configuración típica de un firewall:

        iptables -A INPUT -i lo -j ACCEPT # permitimos conexiones desde la misma pc (loopback)
        iptables -A INPUT -p tcp --dport 22 -j ACCEPT # permitimos conexiones entrantes al puerto 22 (ssh)
        iptables -A INPUT -p tcp --dport 80 -j ACCEPT # permitimos conexiones entrantes al puerto 80 (apache)
        iptables -A INPUT -p tcp --dport 1:1024 -j DROP # dropeamos conexiones entrantes a puertos comunes (entre 1 y 1024) tcp
        iptables -A INPUT -p udp --dport 1:1024 -j DROP # dropeamos conexiones entrantes a puertos comunes (entre 1 y 1024) udp
        iptables -A INPUT -p tcp --dport 3306 -j DROP # dropeamos acceso a mysql

Si hacemos un route, veremos que van a desaparecer las rutas a otros nodos:

alaslibres:/etc/init.d# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.4.21.224     *               255.255.255.224 U     0      0        0 eth2
10.4.18.128     *               255.255.255.224 U     0      0        0 eth3
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
default         Router          0.0.0.0         UG    0      0        0 eth0

Solución

Hacemos una pequeña modificación al script del firewall, permitiendo las conexiones entrantes al puerto 698:

        iptables -A INPUT -i lo -j ACCEPT
        iptables -A INPUT -p tcp --dport 80 -j ACCEPT
        iptables -A INPUT -p udp --dport 698 -j ACCEPT  # Permitimos conexiones entrantes al puerto 698 udp, antes de dropearlo
        iptables -A INPUT -p tcp --dport 1:1024 -j DROP
        iptables -A INPUT -p udp --dport 1:1024 -j DROP
        iptables -A INPUT -p tcp --dport 3306 -j DROP

Y finalmente verificamos que se vean las nuevas rutas:

alaslibres:/etc/init.d# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.4.21.225     *               255.255.255.255 UH    2      0        0 eth2
10.4.22.1       10.4.21.225     255.255.255.255 UGH   2      0        0 eth2
10.4.21.224     *               255.255.255.224 U     0      0        0 eth2
10.4.21.224     10.4.21.225     255.255.255.224 UG    2      0        0 eth2
10.4.22.0       10.4.21.225     255.255.255.224 UG    2      0        0 eth2
10.4.18.128     *               255.255.255.224 U     0      0        0 eth3
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
default         Router          0.0.0.0         UG    0      0        0 eth0

Contribuído por ArielCamino gracias a NicoEchaniz -- CategoryDocuments