Debate técnico - Nodo en LaOtrared

Este tema es para debatir y definir las características técnicas de un nodo y como debeŕia conectarse a LaOtraRed, necesitamos colocar más propuestas aquí :sunglasses:

Propuesta anuncios de bloques de IPs

Bloque público

En este modelo hay un enrutador que tiene asignado un bloque de direcciones IPv4 públicas, los equipos conectados a este bloque son públicos o visibles en toda la red.

Como se ve el enrutador usa Babel para anunciar a otros nodos todo el bloque que le pertenece, en esta propuesta el enrutador (nodo) no anuncia IPs individuales (/32) sino bloques enteros por ejemplo 10.64.3.64/27.

Así cuando otro enrutador en la red requiere por ejemplo comunicarse al servidor 10.64.3.69, tendrá que hacerlo a través del nodo que anuncia 10.64.3.64/27 por que la IP 10.64.3.69 está dentro el rango o dominio 10.64.3.63/27. Así todos los nodos se encargan de anunciar bloques enteros y los demás nodos de la red llegan a sus servidores a través de estos.

Bloque privado

Un nodo también puede tener un bloque de IPs para que dispositivos clientes como celulares o computadores se conecten a la red y consuman servicios. Seguramente habrá que hacer por ejemplo mediante NAT que se traduzcan direcciones IP.

Por ejemplo para un nodo con bloque privado 172.24.5.1 / 27 y bloque público 10.64.3.64/27, cuando un equipo en el bloque de direcciones privadas requiera conectarse a por ejemplo el equipo 10.64.9.21 / 26, tendrá que salir a través del enrtuador y hacer conexión a 10.64.9.1 (que es la IP del enrutador que representa el bloque 10.64.9.1 /26).

Pendientes: Mencionar maneras de evitar NAT.

Siguiendo el modelo del post anterior propuesto donde cada nodo tiene un enrutador que anuncia bloques de direcciones IP o subredes (con CIDR /28 /27 /26 /25)enteras en lugar de solamente IPs únicas (/32)

caso cuando un nodo requiere varias antenas

Este caso se da cuando un nodo requiere más de un enrutador principal, por ejemplo a continuación:

Por ejemplo el Nodo X se compone de dos enrutadores; el principal que anuncia el bloque 10.64.3.64 /27 , y otro enrutador que se conecta al principal y anuncia una ruta hacia la única dirección IP 10.64.3.80 /32.

El enrutador 10.64.3.80 puede por ejemplo ser un enrutador con una antena direccional para enlaces de larga distancia que extiende la conexión del Nodo X. En este caso se conecta al Nodo Z – Lo importante es que el enrutador secundario anuncia una ruta dentro del segmento de red 10.64.3.64 /27 que maneja el router principal y se conectan por un enlace privado (por ejemplo cable ethernet) y así no generan tráfico extra en el resto de LaOtraRed.

Así cada nodo puede tener varios otros enrutadores que anuncian rutas de IP única (/32) pero que están dentro el segmento de red del router principal y así son parte del Nodo y del segmento de red que anuncia el router principal.

Como es típico si hay servidores públicos estos están dentro el segmento de red que anuncia el router principal de cada nodo.

Para evitar NAT y permitir la comunicación directa se tendría que anunciar también las redes privadas en Babel. De otra forma el servidor 10.64.9.21 no tendrá forma de responder al 172.24.5.30.

172.24.5.30 (PC) <-> 172.24.5.1 AP local (Router Nodo 1) MESH 10.64.3.65 <-> La Otra Red <-> 10.64.9.1 MESH (Router Nodo X) <-> 10.64.9.21.

Al responder, 10.64.9.21 envia un mensaje con Destino 172.24.5.30 que llega a su router Nodo X. Este router necesita tener rutas hacia la red 172.24/16 o los paquetes se descartarian.

Esto tambien permitiria simplificar las comunicaciones entre clientes en distintas redes privadas pero introduce el tema de seguridad que se buscaba evitar al segmentar las redes. Esto es en base a redes OSPF/EIGRP con routers tradicionales y conexiones cableadas, posiblemente existen otras consideraciones en MESH/Babel que aún desconozco.

Saludos!

1 me gusta

Si, la idea es evitar el NAT por completo dentro de LaOtraRed (ya que, al contrario que Internet, no sufrimos de escasez ni en IPv4 ni en IPv6). Además, por ahí he visto que Babel es bastante similar a EIGRP respecto a la configuración y el comportamiento de las rutas, etc.

Para mitigar el tema de la seguridad, la idea es agregar reglas al firewall en la configuración por defecto, para que en el router principal de los nodos, se bloqueen los puertos de entrada de los aparatos dentro de una red privada, en TCP y UDP. Así se estorbarían los escaneos de servicios en rangos privados.
(ahora que lo pienso, quizás habría que abrir por defecto algunos rangos altos de puertos UDP para que VoIP no tenga problemas)

Para mitigar el tema de la seguridad, la idea es agregar reglas al firewall en la configuración por defecto, para que en el router principal de los nodos, se bloqueen los puertos de entrada de los aparatos dentro de una red privada, en TCP y UDP

Eso parece lo mejor, debemos tener esas configuraciones de firewall o si no un cliente dentro de la red privada (172.24.x.x) estaría expuesto a toda la red.

de acuerdo, me parece ideal realizar la segmentacion en el firewall. también podríamos pensar en montar servicios STUN/ICE para el tema de abrir puertos multimedia dinámicamente, para esto requiero más investigación.

Suena interesante, volviendo al tema del firewall hace tiempo hice un ensayo de cómo deberían funcionar las reglas del firewall https://wiki.lapaz.laotrared.net/redlibre/politica_de_asignacion_de_ips#por_que_dos_bloques_para_cada_nodo

Intenté algo básico en /etc/config/firewall siguiendo algo de la wiki de LEDE pero no pude lograrlo, no volví a intentar eso desde inicios del año pasado. La pregunta es si es algo factible o deberíamos usar otra idea.

Definitivamente es factible. Recomiendo usar iptables directamente en un inicio, es bueno para aprender y no requiere de mucha configuracion extra. No conozco LEDE pero luego se puede migrar a eso, otra opcion es Shorewall que permite tambien configurar zonas de acceso facilmente.

Ejemplo para permitir VozIP desde clientes hacia un servidor Freeswitch en modo proxy:

iptables -F  -borra reglas por defecto del sistema

Permite loopback interno para fs_cli
-A INPUT -i lo -j ACCEPT 
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

Permite conexiones ya establecidas (TCP)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Admin ssh desde subred permitida
iptables -A INPUT -s 10.64.X.0/24 -p tcp --dport 22 -j ACCEPT

Permite SIP entrante de todos
iptables -A INPUT -p udp --dport 5060 -j ACCEPT

Permite audio RTP entrante
iptables -A INPUT -p udp --dport 16384:32767 -j ACCEPT

Botar lo demas
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

guardar la config
iptables-save > /etc/iptables/rules.v4

para auto-cargar las reglas al reiniciar el servidor
apt install iptables-persistent

ver las reglas
iptables -L

El ejemplo anterior es para un servidor, para un router la logica es mas compleja pues hace forwarding pero quizas en principio seria suficiente esto:

DROP por defecto en cadena FORWARD

Bloquear paquetes nuevos desde subred publica hacia privada
iptables -A FORWARD -o $<interface red privada> -m state --state NEW -j REJECT

Permitir de red privada hacia afuera
iptables -A FORWARD -i $<interface privada> -j ACCEPT

Permitir respuestas hacia red privada
iptables -A FORWARD -o $<interface privada> -m state ! --state NEW -j ACCEPT
1 me gusta

Muy bien, voy a revisar un poco :+1:

El día sábado Luis hizo unas configuraciones desde el panel Luci del router rechazar conexiones desde la red pública (10.64.x.x/15) hacia la red privada (172.24.x.x) de cada nodo.

Algo básico imitando a la WAN.

Tendríamos que ajustar un poco para incluir una red o zona para servidores públicos y ver como se comporta.

Configuraciones de Nodo en LaOtraRed con uno o varios enrutadores usando Babel

Estuve probando configuraciones para un nodo con 2 routers y he conseguido conectar los nodos de esta forma:

nodo_simple_extension1

Como esta prueba ha funcionado, pondré las configuraciones de cada enrutador como referencia aquí, cosa que cualquiera pueda probarlo en un enrutador con LEDE o derivados de openwrt.

NODO A

El nodo A consta de dos enrutadores, un principal y un auxiliar para extender la conexión.

router principal

Como se ve en el dibujo este tiene 2 direcciones IP donde 80.0.3.1 es su IP dentro del bloque publico, el enrutador usa Babel para anunciar el bloque 80.0.3.1/24. También este enrutador anuncia su bloque de direcciones IP privadas 172.24.3.1/24 de la misma forma.

/etc/config/network

Archivo principal de configuración de las interfaces de red.
# configs por defecto (interfaz loopback)
# ..

# una red lan privada
config interface 'lan'
	option proto 'static'
	option type 'bridge'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
# red privada del nodo , se usa para que los clientes de este nodo
# se conecten a otros nodos en LaOtraRed)
config interface 'lor-clientes'
	option proto 'static'
	option ipaddr '172.24.3.1'
	option netmask '255.255.255.0'
# interfaz mesh con IP publica se conecta al resto de LaOtraRed 
config interface 'mesh'
	option proto 'static'
	option ipaddr '80.0.3.1'
	option netmask '255.255.255.0'
	option ip6addr 'fc01:1934:fffe::0303/128'
	option ifname 'eth0'  # sale a traves de conexion cableada

/etc/config/wireless

Archivo de configuración para el WIFI.
config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/ar933x_wmac'
	option htmode 'HT20'
	option channel '7'   # canal wifi compartido
	option country 'BO'
	option txpower '19'
	option disabled '0'
# una red para conectarse al nodo en modo cliente
config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'NODO A'
	option encryption 'none'

Como se ve en el dibujo este nodo, no usa el wifi para unirse a LaOtraRed, sino lo hace mediante ethernet conectándose al router auxiliar.

/etc/config/babeld

Archivo de configuración del protocolo Babel, para que se encargue del enrutamiento en LaOtraRed
config general
	option 'random_id' 'true'
	option 'ipv6_subtrees' 'true'
# se usara la interfaz cableada
config interface
	option 'ifname' 'eth0'
# permitir anuncios de otros vecinos en red publica
config filter
	option type 'in'
	option ip '80.0.0.0/22'
	option action 'allow'
# permitir anuncios de otros vecinos en red bloque de privada
config filter
	option type 'in'
	option ip '172.24.0.0/15'
	option action 'allow'
config filter
	option type 'in'
	option ip 'fc01:1934::/32'
	option 'allow'
# redistribuir anuncios de este nodo
config filter
	option type 'redistribute'
	option ip '80.0.3.1/24'
	option action 'allow'
# redistribuir anuncios de red privada propia.
config filter
	option type 'redistribute'
	option ip '172.24.3.1/24'
	option action 'allow'

config filter
	option type 'in'
	option action 'deny'
config filter
	option type 'redistribute'
	option local 'true'
	option action 'deny'

Pruebas:

root@nodoA:/# ip r 
80.0.2.0/24 via 80.0.3.127 dev eth0 onlink 
80.0.3.0/24 dev eth0  src 80.0.3.1 
172.24.3.0/24 dev br-lan  src 172.24.3.1 
172.24.2.0/24 via 80.0.3.127 dev eth0 onlink 

root@nodoA:/etc/config# traceroute 80.0.2.1
traceroute to 80.0.2.1 (80.0.2.1), 30 hops max, 38 byte packets
 1  80.0.3.127 (80.0.3.127)  0.184 ms  1.476 ms  0.057 ms
 2  80.0.2.1 (80.0.2.1)  1.909 ms  3.373 ms  1.858 ms

root@nodoA:/etc/config# traceroute 172.24.2.1
traceroute to 172.24.2.1 (172.24.2.1), 30 hops max, 38 byte packets
 1  80.0.3.127 (80.0.3.127)  0.457 ms  0.991 ms  0.584 ms
 2  172.24.2.1 (172.24.2.1)  1.640 ms  5.040 ms  1.880 ms

Coo se ve, el nodo A puede llegar al nodo B pasando a través del router Auxliar al que está conectado mediante cable ethernet en eth0

Router auxiliar del nodo A

Es como un puente, por que permite que el router principal A conectado por ethernet se conecte con el nodo B que se conecta a este por wifi, además redistribuye las rutas que anuncian el nodo B y el nodo A extendiendo la red distribuida.

/etc/config/network

Interfaces NodoA auxiliar
config interface 'loopback'
	# ...
# una interfaz lan privada
config interface 'lan'
	option type 'bridge'
	option proto 'static'
	option netmask '255.255.255.0''
	option ipaddr '192.168.1.10'
# interfaz mesh cableada 
config interface 'wiredmesh'
	option proto 'static'
	option ipaddr '80.0.3.127'
	option netmask '255.255.255.255'
	option ip6addr 'fc01:1934:fffe::0316/128'
        # sale a traves de ethernet
	option ifname 'eth0'       
# interfaz mesh para salir por wifi
config interface 'mesh'
	option proto 'static'
	option ipaddr '80.0.3.127'
	option netmask '255.255.255.255'
	option ip6addr 'fc01:1934:fffe::0317/128'

/etc/config/wireless

Wifi nodo A Auxliar
config wifi-device 'radio0'
	# similar al nodo A
# wifi para clientes 
config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'nodo a1'
	option encryption 'none'
	option disabled '0'
# wifi para conectarse a los demas nodos de LaOtraRed
config wifi-iface
	option device 'radio0'
	option network 'mesh'
	option mode 'adhoc'
	option ssid 'babel.pruebas'
	option encryption 'none'
	option bssid 'BA:BE:BA:BE:01:01'

/etc/config/babeld

Configuración del protocolo Babel en el nodo A auxiliar

config general
option ‘random_id’ ‘true’
option ‘ipv6_subtrees’ ‘true’
# Babel actua sobre wifi
config interface
option ‘ifname’ ‘wlan0’
option ‘channel’ ‘7’
# para que tambien actue sobre ethernet
config interface
option ‘ifname’ ‘eth0’
# permitir anuncios de otros nodos en la red publica
config filter
option type ‘in’
option ip ‘80.0.0.0/22’
option action ‘allow’
config filter
option type ‘in’
option ip ‘fc01:1934::/32’
option ‘allow’
# perimitr anuncios de otros nodos en la red privada
config filter
option type ‘in’
option ip ‘172.24.0.0/15’
option ‘allow’
# anunciar ruta de si mismo (una sola IP por eso /32)
config filter
option type ‘redistribute’
option ip ‘80.0.3.127/32’ # esta dentro el rango 80.0.3.1/24
option action ‘allow’

config filter
	option type 'in'
	option action 'deny'
config filter
	option type 'redistribute'
	option local 'true'
	option action 'deny'

Luego reiniciando babel con /etc/init.d/babeld restart las pruebas:

root@nodoAAuxiliar:/etc/config# ip r
80.0.2.0/24 via 80.0.2.1 dev wlan0  proto babel onlink 
80.0.3.0/24 via 80.0.3.1 dev eth0  proto babel onlink 
172.24.3.0/24 via 80.0.3.1 dev eth0  proto babel onlink 
172.24.2.0/24 via 80.0.2.1 dev wlan0  proto babel onlink 
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.10 

NODO B

Similar al Nodo A sólo que tiene un sólo enrutador que se conecta por wifi al resto de LaOtraRed y este mismo anuncia el bloque público y privado.

/etc/config/network

archivo principal de configuración de las interfaces de red.
config interface 'lan'
	option type 'bridge'
	option proto 'static'
	option ipaddr '172.24.2.1'
	option netmask '255.255.255.0'

config interface 'mesh'
	option proto 'static'
	option ipaddr '80.0.2.1'
	option netmask '255.255.255.0'
	option ip6addr 'fc01:1934:fffe::0201/128'

/etc/config/wireless

Archivo de configuración del wifi.
config wifi-device 'radio0'
	# ...

config wifi-iface
	option ssid 'cliente del nodo B'
	# similar al nodo  A 
    # ...
# se define wifi en modo adhoc para conectarse a otros nodos de la red, usando la interfaz mesh
config wifi-iface
	option device 'radio0'
	option ssid 'babel.pruebas'
	option mode 'adhoc'
	option encryption 'none'
	option network 'mesh'                    # red mesh definida
	option bssid 'BA:BE:BA:BE:01:01'  # bssid de pruebas

/etc/config/babeld

Configuraciones para que el protocolo Babel ayude en el enrutamiento automático
package babeld

config general
	option 'random_id' 'true'
	option 'ipv6_subtrees' 'true'

config interface
	option 'ifname' 'wlan0'
	option 'channel' '7'

config filter
	option type 'in'
	option ip '80.0.0.0/22'
	option action 'allow'
config filter
	option type 'in'
	option ip 'fc01:1934::/32'
	option 'allow'
config filter
	option type 'in'
	option ip '172.24.0.0/16'
	option 'allow'

# Anunciando el bloque de IPs publicas
config filter
	option type 'redistribute'
	option ip '80.0.2.1/24'
	option action 'allow'
# bloque de IPs privadas
config filter
	option type 'redistribute'
	option ip '172.24.2.1/24'
	option action 'allow'
config filter
	option type 'in'
	option action 'deny'
config filter
	option type 'redistribute'
	option local 'true'
	option action 'deny'

Luego haciendo pruebas:

root@NodoB:/etc/config# traceroute 80.0.3.1
traceroute to 80.0.3.1 (80.0.3.1), 30 hops max, 38 byte packets
 1  80.0.3.127 (80.0.3.127)  0.061 ms  1.386 ms  1.993 ms
 2  80.0.3.1 (80.0.3.1)  1.879 ms  5.048 ms  1.789 ms

Lo que prueba que hay conexión hacia el nodo A pasando a través del enrutador auxiliar del nodo A.

Conclusiones

Con estas configuraciones comprobamos que se pueden agregar varios enrutadores para un solo nodo, en el caso del enrutador Auxiliar del nodo A, este puede tranquilamente ser una antena direccional de larga distancia que se conecta a otros nodos de la red.

Nodo usando el protocolo bmx7

Ya que hemos estado probando el protocolo bmx7 y que el enrutamiento directo funciona sobre ipv6 solamente, se me ha ocurrido esta infraestructura para cada nodo:

En esta propuesta, cada nodo utiliza bmx7 para anunciar un bloque de direcciones IPv6 fijo aprovechando los UHNA que aseguran rutas seguras.

  • Cada nodo tiene su propio bloque fc01:cafe:bebe:<numero_nodo>00::/56 donde
  • Cada nodo puede poner servidores empezando por ejemplo fc01:cafe:bebe:<numero_nodo><numero_servidor>::
  • Cada nodo puede asignar direcciones dinámicas a sus dispositivos cliente en fc01:cafe:bebe::<numero_nodo>00::/64

Así los servidores pueden mantener direcciones IP fijas y bmx7 los anunciará vía UHNAs. En el caso de IPv4, los servidores y dispositivos cliente aún pueden utilizarlo usando el espacio 10.64.x.x/15 para servidores y 172.24.x.x/15 para clientes, donde los otros nodos llegarán a través de túneles creados por bmx7.

Así LaOtraRed se convierte en una red IPv6 en la capa de enrutamiento y en servidores, pero mantiene la flexibilidad y permite conexiones no optimizadas para nodos que sigan utilizando IPv4.

1 me gusta