HSMM: Tunel IP con OpenSSH

 

Uno de los temas técnicos a resolver en el despliegue de una red HSMM es como conectar entre si diferentes LAN (Local Area Network) aislados para formar un MAN (Metropolitan Area Network) y estos a su vez agregarlos en un WAN (Wide Area Network).
El despliegue de nodos wireless en frecuencias de 2 a 5 GHz tiene, asumiendo antenas adecuadas, un radio de acción desde algunos centenares de metros hasta algunos pocos kilómetros.
Los nodos pueden desplegarse en configuración de Access Point (AP) y a su vez extender su alcance en configuración Routed Client (Client); pero como en todas las cuestiones técnicas existe un equilibrio, y este consiste en que cada vez que se "estira" un enlace con este mecanismo se reduce el ancho de banda a la mitad. Para conectar LAN que estén ubicados a, digamos, mas de 10 Km es necesario preveer alguna forma de conexión alternativa. Existen muchas posibilidades para rutear tráfico bajo los protocolos TCP/IP, pero la configuración del dominio ampr.org limita las opciones. En efecto, este dominio Amateur Packet Radio (ampr) , tiene la caracteristica técnica que es "no ruteado" o al menos es "generalmente no ruteado". El DNS del dominio se resuelve en un controlador ubicado en ucsd.edu donde también reside el amprgate, todos los requerimientos sobre el dominio ampr.org son ruteados a este gate quien intenta resolverlos a su destino final. Pero por años, y hasta el presente, el gateway impone a los LAN que se le conectan condiciones muy dificiles de satisfacer (IP fija, ruteo de un grupo significativo de nodos, etc) por lo que las redes efectivamente conectadas son muy pocas. Esto está en vias de cambiar para adecuarse a los requerimientos y demandas de la nueva tecnología HSMM pero no lo ha hecho aún.
Debido a ello si uno quiere acceder a mi nodo (lu7hz.ampr.org) verá que el host se resuelve en cualquier máquina conectada a Internet correctamente (probar con "ping lu7hz.ampr.org" y se verá que se intenta alcanzar la dirección IP 44.153.84.14); sin embargo la conexión no se materializa porque la unica forma que lo sería consistiría en que fuera visible al amprgate y no lo está.
Poder establecer un tunel que permita conectar por Internet distintos LAN es entonces una función importante para asegurar la escalabilidad de la red y su conexión.
Hay muchas formas de implementar este tipo de conexión, he estado experimentando con una que se basa en el paquete OpenSSH y por lo tanto está disponible en una cantidad de plataformas muy significativa; entre ellas la plataforma OpenWrt con lo cual es concebible implementar esta arquitectura de conectividad mediante routers embebidos, o sea en el access point wireless mismo. Este esquema lo vi referenciado en el sitio técnico de Buenos Aires Libre aunque en ese caso se utiliza con el propósito de servir para activar enlaces de backup entre nodos.
El esquema muestra como conectar dos LAN remotos, el subnet C 44.153.81.0/24 y el subnet 44.153.84.0/24; cabe destacar que mientras el primero corresponde a un subnet clase C cor.ampr.org definido formalmente como tal el segundo no lo es y solo tengo asignada una dirección en ese subnet (44.153.84.14). Sin embargo es una prueba local para evaluar el concepto que no molestaría a los reales responsables del resto de los nodos de esa subnet (suponiendo que estuvieran activos, que no lo están).
Es importante observar como el tunel se implementa mediante un subnet virtual, el mismo tiene solo asignadas las direcciones de los extremos, para no gastar direcciones IP del espacio de la LAN se pueden utilizar como en este caso direcciones del subnet clase A no ruteable 10.0.0.0 (a modo de convención se utiliza un subnet clase C correspondiente al número IP del LAN que origina la conexión).
Uno de los lados se define arbitrariamente como el cliente (en este caso el 44.153.84.0/24) y el otro como servidor. El primero tiene que tener instalado el paquete openssh-client (con opkg install) y el segundo el paquete openssh-server. En el caso del lado que opera como servidor es necesario reemplazar el servidor sshd default del OpenWrt que es dropbear y no sirve para esta prueba por el provisto por OpenSSH.
Luego de seguir los pasos de instalación tanto del cliente como del servidor de SSH.
Hay que asegurar las siguientes condiciones en el archivo de configuración de sshd (/etc/ssh/sshd_config)

PermitRootLogin yes
PermitTunnel yes
TCPKeepAlive yes
Strictmodes yes
RSAAuthentication yes
PublickeyAuthorization yes
AllowTcpForwarding yes

Luego de modificar el archivo hay que relanzar el server sshd. La conexión en la configuración de la figura ocurre con los siguientes comandos

(cliente, red 44.153.81.0/24)

ssh -w any:any 200.0.0.1 -l root

Si la conexión es exitosa pedirá la password de root del host 200.0.0.1, que es la interface a Internet de la red a conectar. Una vez completada la conexión existe un tunel (usualmente tun0, o tunx en general) en ambos lados de la conexión que tiene que ser configurado.

(server, red 44.153.84.0/24 a traves de la conexión recién abierta)

ifconfig tun0 10.0.81.2 netmask 255.255.255.0
ifconfig tun0 up
route add -net 10.0.81.0 netmask 255.255.255.0 gw 10.0.81.2 tun0

En otra sesión SSH se configura del lado del cliente (red 44.153.81.0/24)

ifconfig tun0 10.0.81.1 netmark 255.255.255.0
ifconfig tun0 up
route add -net 10.0.81.0 netmask 255.255.255.0 gw 10.0.81.1 tun0

Al finalizar esta configuración ambos lados pueden rutearse utilizando los respectivos extremos del tunel.
El tunel, y la configuración de los extremos, dura mientras dure la conexión SSH que le dio el origen.
Las ventajas son varias. Los paquetes involucrados son livianos y entran aun en dispositivos muy pequeños, la conexión es encriptada, aunque solo durante el transporte por Internet, no en el aire con el ruteo convencional de la red ampr.org; y por cierto totalmente encapsulada. Puede ser, finalmente, transportada con cualquier conexión Internet sin demasiados problemas.
La desventaja es que requiere de ciertos conocimientos de redes para realmente hacerlo andar y por sobre todo para hacer el debug de los problemas que pueden ir apareciendo (en particular con el firewall).
La prueba de concepto tiene que automatizarse con una serie de scripts que establezcan automáticamente el tunel y su configuración, tengan en cuenta los cambios de dirección IP en los extremos en caso de ser direcciones dinámicas y en general tener en cuenta la configuración de ruteos.
Hay otros esquemas para establecer configuraciones de tunel que transportan puertos específicos (por ejemplo el puerto 80 para acceder a un server Web), pero el ruteo a nivel de capa 3 es el mas general posible.