SERVAL: software libre para la gesti n de VLANs en Internet o

Alejandro Garca Castro1 , Francisco Javier Mor n R a1 , and Juan Jos S nchez Penas2 a u e a
Igalia. Ingeniera en inform tica y software libre a Gutenberg, 34B 2o , Polgono de A Grela 15008 A Corunha acastro,jmoran@igalia.com 2 Universidade da Coru a, Departamento de Computaci n n o Campus de Elvi a 15071 A Coru a n n juanjo@dc.fi.udc.es
1

Resumen En ocasiones es muy interesante tener la posibilidad de introducir una m quina en una Red de area a local diferente de aquellas a las que est fsicamente conectada; algunas aplicaciones requieren que el ordenaa dor en el que se ejecutan sea miembro de una Red virtual de area local remota. En este artculo se describe el proyecto SERVAL 3 , en el que se desarrolla una arquitectura software que emula el funcionamiento de un switch, y que permite la creaci n de Redes virtuales de area local entre m quinas conectadas de forma heterog nea o a e a Internet. Hay soluciones similares, pero todas plantean limitaciones o problemas que SERVAL intenta solucionar. El proyecto est siendo desarrollado en Erlang/OTP, usando una arquitectura cliente/servidor, y se a integra con el sistema operativo utilizando interfaces de red virtuales. Las caractersticas de Erlang se adaptan muy bien a los principales requisitos del sistema: alto rendimiento y tolerancia a fallos. Los primeros tests de rendimiento y funcionalidad han dado resultados muy satisfactorios. El presente artculo explica los resultados obtenidos y plantea las lneas principales para el trabajo futuro.

1. Introducci n o
SERVAL es un proyecto de I+D que tiene como objetivo analizar la viabilidad de un sistema que permita crear Redes virtuales de area local (VLANs) usando un servidor software que emule el funcionamiento de un switch hardware. Este software permite la creaci n de VLANs entre ordenadores, independientemente de su localizaci n o o o del tipo de conexi n que utilicen para acceder a la red. o El sistema operativo del lado cliente no usa un interfaz de red cl sico, sino un programa especial que funciona a como interfaz virtual y que realmente se est comunicando con el servidor SERVAL utilizando un protocolo a interno. Una interfaz de administraci n permite gestionar la entrada y salida de los clientes en las distintas VLANs o denidas en el servidor, que funciona como un switch software reencaminando mensajes entre los clientes que est n en la misma VLAN. a El sistema est siendo desarrollado y publicado como software libre. Existe un repositorio de CVS p blico, a u listas de discusi n, y herramientas de integraci n y trabajo en grupo, as como una p gina4 p blica del proyecto. o o a u La estructura del artculo es la siguiente: en la secci n 2 se explican las diferencias entre SERVAL y las o alternativas existentes, y se exponen las motivaciones del proyecto. La secci n 3 expone los principales requisitos o del proyecto. La arquitectura propuesta, basada en dichos requisitos, es explicada en la secci n 4. El uso de Erlang o como plataforma de desarrollo se motiva y explica en la secci n 5. La secci n 6 aporta algunos datos m s sobre o o a el estado actual del proyecto. Finalmente, exponemos las principales conclusiones del proyecto y las lneas de trabajo abiertas para el futuro pr ximo. o

2. Estado del arte y motivaci n o

Existen tecnologas que permiten la conexi n a LANs remotas, pero como hemos comentado, no proporcionan o funcionalidades que son interesantes en algunos entornos reales. Una opci n para la creaci n de una conexi n virtual entre dos LANs que se comunican a trav s de redes o o o e inseguras, son las Redes privadas virtuales (VPNs). Esta tecnologa permite congurar dos redes lejanas emulando dos redes locales que est n fsicamente conectadas por un router. La principal limitaci n, a mayores de la necesidad a o de congurar un router en ambos extremos de la conexi n, es que dos m quinas de esas dos redes no podran o a intercambiar tr co no enrutado, por lo que los protocolos de area local no podran ser utilizados entre ellas. a Un ejemplo de este tipo de software es FreeS/Wan [1], que implementa IPSec [2], un protocolo est ndar para a encriptar tr co IP entre dos redes que est n conectadas a dos pasarelas IPSec. a a
3 4

Proyecto parcialmente nanciado por la Xunta de Galicia, PGIDITSIN0313E P gina del proyecto SERVAL: http://serval.igalia.com a

Otra opci n sera la utilizaci n de Redes virtuales de area local (VLANs) de bajo nivel para la conexi n o o o de LANs que est n separadas fsicamente, permitiendo de este modo tr co no enrutado (posibilitando el uso e a de aplicaciones o protocolos como Rendezvous o SMB). Las VLANs se implementan normalmente usando el protocolo 802.1Q [3], que enva tr co de nivel de enlace con informaci n sobre las VLANs entre los puertos de a o diferentes switches. La mayor limitaci n de este tipo de soluciones se deriva de que hoy en da s lo se pueden o o implantar si tenemos control sobre todos los switches colocados entre las m quinas que queremos conectar, y todos a ellos tienen la funcionalidad de crear VLANs. Adem s, los cambios de conguraci n en este tipo de arquitecturas a o son complejos y costosos. El sistema que proponemos puede emular este comportamiento VLANs con una conguraci n m s simple, o a dando lugar a un switch software escalable, distribuido, y tolerante a fallos. La soluci n toma algunas ideas de las o dos alternativas existentes, eliminando las limitaciones funcionales de las VPNs y la complejidad y coste de las soluciones de tipo VLANs. Adem s, para la soluci n, se est n analizando y utilizando tecnologas y est ndares ampliamente aceptados a o a a como tecnologas LAN (Ethernet, Token ring, etc.), tecnologas VLAN (802.1Q [3], 802.1D [4]), protocolos de transporte TCP/IP (UDP y TCP), protocolos de nivel de aplicaci n y sus sistemas de encriptaci n (SSL y TLS o o [5]), o sistemas para la emulaci n de interfaces de red. o Existen numerosas aplicaciones que motivan el inter s del sistema. Algunos ejemplos han sido discutidos con e la empresa de telecomunicaciones R, Cable e Telecomunicaci ns de Galicia, S.A., para aprender m s sobre posio a bles casos de uso e incrementar el conocimiento sobre los requisitos. Algunas de las aplicaciones m s interesantes a son: las LANs corporativas virtuales que conectan distintas redes fsicas en una compa a de una forma exible n y f cilmente congurable; los sistemas para la compartici n de cheros basados en VLANs usando protocolos a o est ndar de area local; o los juegos a trav s de Internet que s lo podan ser utilizados con anterioridad en un a e o entorno de LANs.

3. Objetivos
Como hemos explicado, el principal objetivo del proyecto es analizar la viabilidad del desarrollo de una soluci n para gestionar VLANs a trav s de Internet. Los principales requisitos funcionales para el proyecto se explican o e a continuaci n: o Arquitectura cliente/servidor: adem s de por su exibilidad, se necesita esta arquitectura para los casos en a los que los clientes acceden desde direcciones IP locales, que causaran problemas en t cnicas peer-to-peer e (se considerar n, en cualquier caso, estas t cnias de conexi n directa para para despliegues con necesidades a e o especiales especiales). Soporte de distintos sistemas operativos: como objetivo inicial planteamos la necesidad de integrar con la capa de enlace de Microsoft Windows y GNU/Linux. En entornos GNU/Linux se puede utilizar el controlador Ethernet virtual TAP, pero en entornos cerrados la b squeda de la soluci n es m s compleja. u o a Rendimiento: al estar emulando entornos de redes de area local, la latencia del sistema es un requisito crtico, incluso en condiciones de carga alta. La cantidad de operaciones gestionadas (throughput) debe ser tambi n e optimizada. Tolerancia a fallos: el sistema, que se podr desplegar en un entorno distribuido, debe ser capaz de seguir a funcionando en presencia de fallos software o hardware. El dise o de procesos y protocolos debera tener en n cuenta esta necesidad. Seguridad: una de las caractersticas m s importantes, debido al funcionamiento en entornos inseguros. En al a gunas condiciones se puede asumir que el rendimiento se vea penalizado por la inclusi n de mayor seguridad. o Se deben incluir funcionalidades de autenticaci n, autorizaci n y encriptaci n. o o o Encapsulaci n de protocolos LAN heterog neos: deben ser soportados al menos Rendezvous y Server Meso e sage Block, pero el objetivo nal es soportar el mayor n mero de protocolos posible. La soluci n optima es u o emular de forma totalmente transparente un controlador Ethernet est ndar. a

4. Arquitectura software y hardware

A la hora de seleccionar una arquitectura se barajaron varias opciones. Las opciones evaluadas fueron: peer-to-peer, uni n de dos clientes de forma independiente, aunque es atractivo para algunos casos tiene el o gran problema que no resuelve las comunicaciones entre m quinas enmascaradas. a

Estructura de bus, permitira unir m s de dos clientes usando a los usuarios adem s de como puntos nales a a como puntos de uni n en la red. Tiene el mismo problema que el peer-to-peer a la hora de conectar ordeo nadores en redes enmascaradas. Adem s el rendimiento sera variable y difcil de controlar en funci n de la a o topologa que pudiese llegar a tener el bus. La gesti n de VLANs sera extremadamente compleja. o Cliente/servidor, que incluye un servidor accesible en una m quina en Internet y una serie de clientes especa cos para acceder a ese servidor. Este servidor esperara conexiones de clientes que se conectaran a las VLANs que hubiese dadas de alta en ese momento. Los clientes funcionaran como drivers de tarjetas que se conec tara al switch, el servidor de SERVAL, que dara la conectividad necesaria a nivel de red para comunicar a los clientes. El sistema operativo cliente vera su interfaz con SERVAL como una tarjeta y a los otros clientes en la misma VLAN como m quinas en la misma red local. a Con esta ultima aproximaci n se resuelven los problemas planteados. La comunicaci n entre cliente y servidor o o se realiza con un protocolo especco similar a los que puede haber en cualquier protocolo de capa de enlace. La arquitectura elegida permite plantear soluciones a los problemas de tolerancia a fallos y escalabilidad. Para ello, en la arquitectura nal, propusimos el uso de un cl ster de m quinas como servidor SERVAL. Estos nodos u a colaboran en el funcionamiento, detectan el fallo de otros nodos y aceptan el cambio de sus clientes a otros nodos del grupo.

5. Implementaci n del sistema utilizando Erlang o

Tal y como explicamos en la secci n anterior se han desarrollado dos partes: o Servidor SERVAL , es el programa que se encarga de emular el switch. Debe ejecutarse en una IP p blica u accesible por todos los clientes. Gestiona todas las operaciones relacionadas con las VLANs y la gesti n de o clientes. Por ejemplo, se encarga de aceptar conexiones entrantes de clientes, crear VLANs, enrutar mensajes, etc. Se desarrolla en Erlang. Cliente SERVAL , dividimos el cliente en dos partes diferenciadas: Programa de usuario, es el programa que se encarga de recibir las tramas Ethernet del controlador virtual y las convierte en mensajes del protocolo que enva al servidor SERVAL. Se desarrolla en Erlang. Controlador Ethernet virtual, es el que se encarga de emular la tarjeta de red. Controla las comunicaciones entre el interfaz del kernel y el programa de usuario. Se desarrolla en C utilizando interfaces virtuales TAP del kernel. Adicionalmente se ha elaborado un programa de usuario, que hemos denominado shell SERVAL, que permite a los usuarios conectados a SERVAL administrar su conexi n virtual con el. A trav s de esta utilidad el usuario o e puede solicitar todas las operaciones soportadas por el servidor: Crear/borrar VLANs. Unirse/salir de VLANs. Activar/desactivar modo promiscuo. Autenticarse en el servidor. Preguntar por los clientes conectados a una VLAN. Solicitar el listado de VLANs Conectar/desconectar a SERVAL. Este shell de usuario establece comunicaci n con el nodo Erlang y, a su trav s, solicita todos los comandos o e que quiere ejecutar y recibe, a su vez, las respuestas que el servidor da a las peticiones. Est hecho en Erlang y la a interfaz que proporciona al usuario es una lnea de comandos. La estructura del cliente est reejada en la Figura 1. a En la Figura 2, por su parte, se puede ver la relaci n entre el agente cliente y el interfaz virtual Ethernet. o En la imagen se aprecia como una aplicaci n de usuario, ejecut ndose en un ordenador conectado al servidor o a SERVAL, utilizara el cliente y la torre de protocolos para mantener la comunicaci n. Los mensajes enviados por o el programa de nivel de aplicaci n est n encapsulados dentro de un protocolo de nivel de transporte. Este, a su vez, o a se encapsula en un protocolo de red y se convierte en tramas Ethernet, que se envan a trav s del interfaz virtual. e El interfaz virtual reparte las tramas al programa de usuario que nalmente las convierte en mensajes del protocolo de SERVAL que van al servidor. Estos mensajes se vuelven a encapsular para ser enviados por un interfaz real de red. En el lado opuesto se sigue el camino contrario, ascendiendo la torre de protocolos. Se incluyen en este punto los detalles de implementaci n del servidor, del cliente y del shell de usuario. o

Figura 1. Arquitectura del cliente

Figura 2. Relaci n entre el cliente y el controlador Ethernet o

Figura 3. Diagrama de procesos del nodo Erlang del cliente

La estructura de procesos del nodo Erlang del cliente se pueden observar en la Figura 3 y los del servidor en la Figura 4. En los diagramas se representan los principales procesos del servidor, y las relaciones existentes entre ellos (cuando un proceso intercambia mensajes con otro, o cuando un proceso supervisa y recibe, por lo tanto, las se ales de otro, siguiendo la losofa habitual de programaci n de Erlang). n o Con respecto a la arquitectura del cliente shell, el diagrama de procesos que lo describe es el que se aprecia en la Figura 5. El almacenamiento del estado de las conexiones y VLANs se realiza utilizando la base de datos Mnesia. Utilizamos sus caractersticas de replicaci n para acceder a todos los datos de cualquier nodo y as conseguir o tolerancia fallos y escalabilidad de forma sencilla. Para las comunicaciones de red utilizamos encapsulaci n ASN1, deni ndose el protocolo con el uso de su o e lenguaje de descripci n. Empleamos, adem s, el compilador Erlang de ASN1 para convertir los mensajes de su o a forma binaria a estructuras Erlang.

6. Estado actual
Actualmente contamos con una primera versi n del servidor, del cliente SERVAL y del shell completamente o funcionales. No obstante, esta no es de momento una versi n destinada a entornos de producci n debido a que es o o necesario mejorar aspectos de estabilidad y tolerancia a fallos, adem s de incluir algunas caractersticas deseables a en un entorno real. 6.1. Caractersticas implementadas Las principales caractersticas implementadas en SERVAL son: Opci n de utilizaci n de TCP o UDP como protocolo de transporte en las conexiones cliente-servidor. o o Soporte multinodo. Protocolo de comunicaciones SERVAL denido en ASN1. Uso de la base de datos Mnesia como m todo de sincronizaci n entre nodos. e o Sistema de log. Encriptaci n SSL. Se ha a adido la posibilidad de utilizar una capa de enlace encriptada en SERVAL debido o n a que el contexto al que est dirigido el proyecto son los entornos WAN. Las comunicaciones con SSL utilizan a encubiertamente TCP como capa de transporte y para su utilizaci n es necesario que el servidor poseaa un o certicado SSL.

Figura 4. Diagrama de procesos del servidor

Figura 5. Diagrama de procesos del shell cliente

Sistema de autenticaci n. Ha sido a adido un sistema de autenticaci n para autorizar conexiones a SERVAL o n o unicamente a usuarios deseados. El sistema de autenticaci n desarrollado inicialmente utiliza Mnesia y ha o sido dise ado para ser f cilmente reemplazable por otro backend, que utilizara LDAP, una base de datos n a relacional ... En estos momentos estan soportados dos sistemas de autenticaci n: o Autentaci n basada en certicado SSL de cliente. o Autenticaci n por m todo usuario/contrase a. o e n ACLs- Listas de Control de Acceso- para operaciones. Los usuarios deben estar autenticados y pertenecer a ciertos grupos para realizar determinadas operaciones. Asignaci n din mica de MACs. Las direcciones MAC son asignadas por el servidor en el momento de la o a conexi n. o Mecanismo de keep-alive. Con este subsistema el servidor puede monitorizar el estado de conexi n de los o clientes y las cadas de estos pueden ser gestionadas con correcci n. o Opci n de modo promiscou en clientes. o Conguraci n para el establecimiento y el borrado de la interfaz ethernet virtual din mica en tiempo de o a ejecuci n. o 6.2. Despliegues de SERVAL Hemos realizado varias instalaciones de SERVAL en las que hemos comprobado sus caractersticas y poten cialidades. En este subapartado vamos a incluir un ejemplo de utilizaci n del proyecto. o La conguraci n consisti en tener una red de ordenadores, con sus servidores, impresoras y PCs de sobreo o mesa. Adem s, se cont con clientes externos con los que se quera acceder a la red de ordenadores como si a o estuvieran fsicamente unidos a la Red de area local. La red de computadores posea un gateway, que era el punto de entrada a la red. Esta red contaba con un computador, host A, en el que se lanz el servidor SERVAL. El servidor escuchaba en tres puertos diferentes, o uno para conexiones tcp, otro para conexiones udp y un tercero para conexiones ssl. El gateway redireccionaba los puertos reenviando las conexiones a estos puertos a los mismos puertos, pero en el host A. En este despliegue existan 3 clientes:

M quina externa 1. Es un computador que conectaba a SERVAL desde una localizaci n externa a trav s del a o e gateway de la red. M quina externa 2. Es un segundo usuario que conectaba a SERVAL desde el exterior a trav s del gateway. a e M quina interna 3. Es un computador que conectaba a SERVAL desde la intranet, es decir, es un computador a interno a la red.
El diagrama que representa gr camente todo el montaje est recogido en la Figura 6. a a

Cliente SERVAL Cliente SMB maquina externa 1

red corporativa Servidor SERVAL

host A

Redireccion de puertos tcp 5690, tcp 5443 udp 6690 gateway corporativo maquina interna 1

Cliente SERVAL Servidor SMB exportado /tmp

WAN

Cliente SERVAL Cliente SMB maquina externa 2

Figura 6. Ejemplo de despliegue de SERVAL

En este despliegue se le dot a todos los clientes con direcciones de la subred 192.168.30.0/24 y se ensayaron o con exito varias aplicaciones empleando las interfaces virtuales TAP: SSH. Ping. Cliente samba y servidor samba. 6.3. Pruebas de rendimiento Una de las caractersticas principales para probar y evolucionar el sistema es el rendimiento. Adem s, mane a jarlo de forma adecuada cuando la cantidad de clientes es elevada es crucial para el exito del proyecto. Por todo ello, las nuevas caractersticas que a adimos al proyecto se desarrollan teniendo en cuenta siempre en el impacto n que pueden tener sobre el mismo. Para la medici n del rendimiento usamos la latencia de una operaci n, as como el n mero de mensajes o o u procesados por el servidor por unidad de tiempo y contamos para ello, con varios m dulos que representan en o tiempo real estas medidas de forma gr ca. a 6.4. Tolerancia a fallos Esta caracterstica ya la hemos resaltado como esencial en la secci n 3. Hemos usado varias estrategias para o conseguir la tolerancia a fallos del sistema. Las capacidades de concurrencia y distribuci n de Erlang nos han o permitido construir un servidor multinodo. La idea principal es que si un nodo falla exista alg n mecanismo para permitir al resto de nodos seguir funciou nando, y a los clientes reconectar a otro nodo del servidor para continuar de forma transparente el intercambio de mensajes.

Si un nodo falla el mecanismo de recuperaci n se encuentra en el cliente, y le permite conocer otros nodos a o los que conectarse cuando se da cuenta de los problemas de su nodo servidor. En el caso de fallo de un cliente se ha incorporado un sistema de keep-alive, que permite al servidor saber si el cliente est respondiendo para poder desconectarlo de una VLANs y dejar de mandarle mensajes. Hay un tiempo a entre el fallo y la detecci n en la que los mensajes enviados se pierden. Podramos solucionarlo con un sistema o de mensajes de aceptaci n (acks), aunque pensando en que los protocolos de capas superiores incorporan ya el o control de conexi n, parece preferible dejar la responsabilidad en ellos y no cargar el protocolo pensando en la o eciencia.

7. Conclusiones y lneas de trabajo futuras

En el presente artculo, hemos explicado las motivaciones y los objetivos del proyecto SERVAL, la soluci n o dise ada para alcanzarlos, as como los resultados obtenidos y el trabajo que se est realizando en la actualidad. n a Se ha argumentado por qu pensamos que Erlang es una tecnologa adecuada para un proyecto en el que las e comunicaciones, el rendimiento y la tolerancia a fallos son aspectos crticos. Pensamos que la idea detr s del proyecto es interesante, y que este es aplicable a numerosos escenarios reales, a en los que la emulaci n de VLANs a trav s de Internet es una soluci n optima. La exibilidad de gesti n de o e o o SERVAL permite dise ar topologas de red de una forma m s simple. n a Los resultados obtenidos en la actualidad son satisfactorios, y auguran un futuro prometedor para el proyecto. En la actualidad tenemos una funcionalidad b sica implementada que permite conectar clientes entre s a trav s a e del servidor, y en el futuro pr ximo esperamos estar en condiciones de tener un prototipo completo funcionando, o que sea f cilmente instalable. a A pesar de la juventud del proyecto, la utilizaci n en todo momento de metodologas iterativas, asociadas a la o publicaci n del software bajo licencia GPL y al desarrollo abierto, han permitido incorporar f cilmente a nuevos o a miembros al desarrollo del proyecto, y creemos que permitir incrementar en el futuro pr ximo la comunidad de a o inter s. e El trabajo futuro en el que se est trabajando actualmente es: a Protocolo de control de congesti n, el sistema puede controlar su propia carga y mejorar su eciencia bas ndoo a se en ese control. Listas de control de acceso, es una caracterstica interesante para el control de los permisos de los diferentes clientes en el sistema. Seguridad en las comunicaciones, en muchos entornos es un requisito importante la posibilidad de asegurar las transmisiones ante posibles intrusos.

8. Agradecimientos
Los autores quieren agradecer a Alberto Garca Gonz lez, Jos Juan Gonz lez alonso, Iago Toral Quiroga, a e a Adri n Otero Vila y Angel Vidal, y en general a toda la empresa Igalia, por su colaboraci n en el desarrollo del a o proyecto SERVAL.

Referencias
1. The FreeS/WAN Project. Ipsec gnu/linux implementation, 2004. http://www.freeswan.org/. 2. The Internet Engineering Task Force (IETF). Ip security protocol (ipsec), 2004. http://www.ietf.org/html.charters/ipseccharter.html. 3. IEEE Project 802.2 Working Group. IEEE standard for local and metropolitan area networks: Virtual bridged local area networks. Technical report, Institute of Electrical and Electronics Engineers, 3 Park Avenue, New York, NY 10016-5997, 1998. 4. IEEE Project 802.2 Working Group. IEEE standard for information technologytelecommunications and information exchange between systemsieee standard for local and metropolitan area networkscommon specicationsmedia access control (mac) bridges. Technical Report ISO/IEC 15802-3:1998, Institute of Electrical and Electronics Engineers, 3 Park Avenue, New York, NY 10016-5997, 1998. 5. T. Dierks and C. Allen. The tls protocol version 1.0. RFC 2246, IETF - (Internet Engineering Task Force), January 1999.