Diseño de una arquitectura de túneles IP simultáneos multi-protocolo

Transcripción

1 Diseño de una arquitectura de túneles IP simultáneos multi-protocolo Gustavo Chaín Dumit 1, Rodrigo Ahumada Montenegro 2, José Miguel Rubio L. 3 Pontificia Universidad Católica de Valparaíso, Facultad de Ingeniería gchain@gmail.com 1, rodahummont@yahoo.com.ar 2, jose.rubio.l@ucv.cl 3 Resumen: Las implementaciones actuales de Túneles IP presentan limitaciones desde el punto de vista de la conectividad. Por una parte el rendimiento de un túnel se podría optimizar estableciendo más de uno de manera simultánea con distintos host, aprovechando eventualmente de manera más eficiente el ancho de banda. Paralelamente es posible utilizar protocolos de alto nivel para establecer varios canales de comunicación. El presente texto describe una arquitectura necesaria para desarrollar una aplicación de creación de túneles más eficientes y flexibles, utilizando estas técnicas.

2 1. Introducción En la actualidad muchas redes corporativas y públicas establecen estrictas políticas de control para el acceso a Internet, utilizando como criterio de bloqueo no sólo puertos de comunicación y protocolos si no también el contenido de la transmisión. Una de las soluciones a esta limitante es establecer un Túnel IP con una máquina externa libre de estas restricciones. Con esta técnica, se concentra el tráfico encapsulado hacia una máquina externa, la cual puede convertirse en cuello de botella y punto crítico, en caso que posea poco ancho de banda o tenga problemas de conexión. Este artículo propone una arquitectura que describe los elementos necesarios para desarrollar un sistema que establezca túneles IP considerando dos características principales, la primera, considera la utilización de varias máquinas capaces de darnos acceso a la red a la que pertenecen, la segunda propone la creación de canales de transporte utilizando diversos protocolos, que pueden eximirse de las políticas de control. Aunque no es una arquitectura completamente terminada, se ha desarrollado un pequeño prototipo funcional utilizado como prueba de varios conceptos experimentales. Se espera que este evolucione en conjunto con el desarrollo de la arquitectura. 2. Estado del Arte 2.1. Encapsulamiento La tecnología de túneles IP es una técnica que permite la unión de dos redes por medio de un canal virtual, abstrayendo la capa de red a un protocolo común para ambas (por lo general, Internet). Este proceso es conocido como encapsulación de paquetes, de este modo todo el tráfico entre ambas redes viaja protegido del medio. Esta técnica es usada para dar solución a problemas de conectividad y disponibilidad de acceso a servicios de red, a hosts que están ubicados dentro de redes que poseen sistemas como cortafuegos, proxies de red o analizadores de tráfico en tiempo real. También es usado para permitir interconexión mediante protocolos nuevos y no soportados ampliamente, como es el caso del protocolo IPv6[Deering and Hinden, 1998].

3 Figura 1: Encapsulamiento de TCP sobre UDP 2.2. Túneles en espacio usuario Dentro de las implementaciones para montar un túnel podemos encontrar las implementaciones en a) el protocolo de red donde el mecanismo para establecer el túnel forma parte de la propia especificación del protocolo 1 y b) implementaciones en espacio usuario, donde por medio de una interfaz de red virtual el kernel permite que los datos transmitidos el supuesto medio 2 sea accesible por una aplicación en espacio usuario. Figura 2: Interacción Kernel y aplicación en espacio usuario por medio de la interfaz virtual 2.3. Implementaciones OpenVPN 3 :es un software de creación y administración de VPN en espacio usuario creado por James Yonan. Su desarrollo a utilizado los estándares industriales de en- 1 Un ejemplo de esta implementación es IPSec[Srisuresh and Egevang, 2001a], protocolo que contempla en uno de sus métodos de funcionamiento el uso de un túnel 2 Capa 1 en modelo TCP 3

4 criptación SSL/TLS, y permite varios métodos de autenticación, certificados, llaves públicas y contraseñas. Al ser un proyecto de código abierto, ha tenido un crecimiento asombroso (el proyecto empezó el 2001), y está disponible para Solaris, Linux, OpenBSD, FreeBSD, NetBSD, Mac OS X, y Windows 2000/XP. VTUN 4 :otro proyecto de VPN en espacio usuario, y es la implementación de túnel de referencia contenida en el código fuente de Linux. Aunque más simple que OpenVPN y ofrece muchas menos características, soporta varios tipos de medios para implementación de túnel (IP, ethernet, puerto serial y tuberías POSIX), y aplica encriptación, compresión de los datos y control de caudal. Está portado para sistemas operativos Linux, Solaris, FreeBSD, OpenBSD y NetBSD. Con respecto a mecanismos de encapsulación en alto nivel, existe un proyecto llamado OXG 5 [Ciarlante, 2005]. Éste actúa como gateway para transportar paquetes OpenVPN, a través de la red Jabber 6. Cada paquete generado por OpenVPN se vuelve a encapsular dentro de un mensaje Jabber (específicamente, el protocolo XMPP[P. Saint-Andre, 2004]). Si bien el tráfico total es menor (se agrega una cabecera nueva) y la latencia aumenta (ya que hay que atravesar la red jabber), permite establecer un túnel punto a punto a 2 hosts que estén limitados por un NAT[Srisuresh and Egevang, 2001b]. 3. Arquitectura propuesta 3.1. Funciones del sistema Para este sistema, se ha pensado en una arquitectura cliente-servidor, en la cual un cliente utilizar varios servidores que le den acceso a la red remota, y a su vez, estos servidores atiendan a varios clientes simultáneamente, siendo verdaderos Servidores de Túnel. Estos servidores dan acceso a los clientes a la misma red. Esto permite varias vías que conectan a la red privada 1 con la red privada 2 como se ejemplifica en la figura 3. Las funciones generales del sistema son las siguientes: Inicializar una interfaz de red virtual: utilizando los mecanismos ofrecidos por el sistema operativo. establecimiento de un túnel: creando varios canales para el transporte de los paquetes encapsulados, contra uno o más servidores, utilizando varios protocolos. Utilizar plugins para la implementación de los diferentes protocolos: de modo de poder cargar dinámicamente nuevos canales de comunicación, y también poder desarrollar nuevos canales independientemente del programa principal OpenVPN XMPP Gateway 6

5 Figura 3: esquema de conexión entre dos redes privadas Aplicar opcionalmente encriptación y compresión a los paquetes transportados: aparte de la capacidad de transmisión de datos, opcionalmente algunos canales podrían ofrecer encriptación, lo cual protege la confidencialidad de lo transmitido. Además podrían ofrecer compresión de paquetes, para mejorar la rapidez de transmisión. Monitorizar regularmente el desempeño de los canales: de modo de generar estadísticas y poder clasificarlos según su rapidez de transmisión. Balancear la carga entre los diferentes canales: para optimizar el transporte, priorizando el uso de los canales que presenten mejor desempeño en el momento, o decidir en base a las reglas de ruteo establecidas por el usuario. En el caso de los clientes, esto también se aplica a la selección de cuál servidor utilizar. En el caso de los clientes, reconocer establecimientos de sesiones TCP: de modo que el balanceo de carga a través de diferentes servidores no afecte la mantención de éstas. Tolerancia a fallos del transporte: como es el caso de desconexiones o retrasos prolongados, derivando el tráfico hacia otros canales, siempre que sea posible. Las soluciones actuales de creación de túneles generalmente utilizan un esquema lineal de transporte de paquetes, el cual puede apreciarse en la figura 4. Existe un único servidor remoto y un único canal de transporte utilizado en un momento dado. En el caso de este sistema, al presentarse varias opciones de acceso a la red remota, el cliente debe seleccionar adicionalmente por cual ruta serán transportados los datos (figura 5). Durante el uso del túnel, se transportarán paquetes que necesiten mantenerse asociados a un servidor de salida mientras la conexión persista; conexiones orientadas a sesión (TCP) y paquetes que no estas asociados a una sesión (UDP) ni sujetos a esta restricción. En el primer caso, estos paquetes necesitan que las direcciones IP de origen y destino se mantengan consistentes durante el transcurso de la conexión. Esto implica que

6 el sistema de selección de servidor y canal debe considerar que tipo de paquetes van a ser transportados. Un sistema que quiera implementar esta funcionalidad debe implementar un sistema de reglas que determine la ruta de salida del paquete; concretamente, seleccionar por cual de todos los servidores disponibles será despachado: Reglas predefinidas : son reglas de enrutamiento definidas por el usuario se aplican de manera estática y tienen prioridad sobre otros métodos de ruteo. Los criterios de selección de rutas pueden basarse en direcciones y puertos de destino. Esta información es extraída de las cabeceras IP, UDP, TCP u otras del paquete encapsulado. Reglas generadas en tiempo real : estas reglas priorizan el uso de los canales y servidores, basándose en información obtenida de los monitoreos aplicados, para conseguir el mejor desempeño de transporte. Para el sistema de reglas generadas en tiempo real, es necesario implementar un Registro de Sesiones, el cual guardará la información de cada sesión TCP iniciada, y por cual servidor fue dirigida. De esta manera, un paquete perteneciente a esta sesión, puede ser comparado contra este registro, y determinar si cumple con el concepto de sticky-address, es decir, si debe ser despachado por el mismo servidor que sus antecesores. El esquema de ruteo puede verse en la figura 6. Figura 4: esquema convencional de implementación de túnel IP

7 Figura 5: esquema general de la implementación del túnel multiservidormultiprotocolo Figura 6: algoritmo general de ruteo de paquetes dentro del túnel (cliente)

8 3.2. Componentes del sistema Figura 7: componentes del túnel, servidor y cliente Los componentes de esta arquitectura, mostrados en la figura 7, son los siguientes: Interfaz de red virtual (cliente y servidor) : este componente se encarga de la administración de la interfaz de red creada por el módulo TUN/TAP. Cargador de plugins (cliente y servidor) : encargado de cargar dinámicamente el código que implementa los canales de comunicación, a partir de bibliotecas compartidas. Notificador de eventos de red (cliente y servidor) : sistema que recibe los eventos de entrada y salida de sockets, y despacha estas notificaciones a los diversos canales. Servicio de autentificación (servidor) : componente encargado de filtrar las nuevas conexiones recibidas por los canales, y solo aceptar las provenientes de clientes registrados en el registro de clientes. Servicio de autentificación (cliente) : componente encargado de iniciar el proceso de autentificación contra el servidor. Registro de clientes (servidor) : mantiene la lista de los clientes que puede hacer uso del servidor y están autentificados. Administrador de servidores (cliente) : componente encargado de mantener un administrador de canales por cada servidor que el cliente hace uso. Administrador de canales (cliente y servidor) componente encargado de mantener los canales que comunican con un servidor en particular, y aplicarles monitoreos de desempeño. Canales (cliente y servidor) : es el componente encargado del transporte y es la abstracción de la capa de red de esta red virtual. Existen varias instancias de este componente, uno por cada conexión establecida.

9 El método de autentificación y el sistema de seguridad puede ser implementado de varias maneras, desde simples claves compartidas, hasta uso de claves asimétricas. Además de esto, algunos protocolos de alto nivel pueden ofrecer mecanismos de seguridad como encriptación. El sistema de autentificación no es el objetivo principal que contempla esta arquitectura, por lo cual se plantea diseñarlo con un sistema simple de autentificación mediante claves compartidas, y delegar la responsabilidad de la confidencialidad a los plugins. 4. Prototipo Se desarrolló un prototipo funcional que implementó un subconjunto modesto de la arquitectura completa. Sus características fueron: sólo se implementó la característica de múĺtiples protocolos, pero no múltiples servidores. arquitectura simétrica, es decir, los programas fueron iguales en ambos hosts y formaron una conexión punto a punto, en vez de ser cliente-servidor. se implementó el monitoreo de canales en la forma de test de latencia, pero la selección de canales fue en forma manual a petición del usuario. no hubo autentificación. se implementaron tres tipo de plugins: UDP, TCP y Jabber, los cuales fueron muestras de protocolos de bajo, medio y alto nivel respectivamente Pruebas efectuadas al prototipo Escenario Se realizaron 4 tipos de test diferentes ejecutados de manera directa (sin uso del túnel) y sobre cada uno de los plugins, (UDP, TCP, Jabber/XMPP). Los test fueron realizados desde 2 host en distintos lugares de la quinta región provisto cada uno con una conexión a internet doméstica. Para realizar los tests se utilizaron las herramientas ping 7, GNUNetcat y MD5 para transferir y comprobar respectivamente los archivos Tests realizados ping normal: Un extremo envió 50 pings al otro punto del túnel ping flood: Se envían 50 pings sin esperar una respuesta por cada ECHO REQUEST. transferencia UDP: Se envió un archivo de 1MB mediante UDP. transferencia TCP: Se envió un archivo de 1MB mediante TCP. 7 incluida en el paquete IPUtils,

10 Resultados ping normal: conexión min (msec) promedio (msec) max (msec) paquetes perdidos directa % plugin udp % plugin tcp % plugin jabber % Tanto en la conexión directa como en el plugin UDP los resultados son muy similares, tiempos bajos y menos de 25 % de paquetes perdidos. En los 2 protocolos restantes la cantidad de paquetes perdidos es 0 %, esto debido a que ambos protocolos son orientados a sesión e implementan comprobación de estado y datos. Por último se advierte un notable incremento en los tiempos de respuesta del protocolo JABBER, a diferencia de las 3 conexiones anteriores, debido a las distancias que tienen que recorrer para llegar a los servidores de la red JABBER (fuera del territorio nacional). ping flood: conexión min (msec) promedio (msec) max (msec) paquetes perdidos directa % plugin UDP % plugin TCP % plugin JABBER % Los tiempos son prácticamente iguales que los de la tabla anterior, y la cantidad de paquetes perdidos en los 2 primeros tipos de conexión también, en cambio se nota un incremento enorme en el porcentaje de paquetes perdidos, debido a timeouts y reenvíos fallidos. transferencia UDP: conexión directa plugin UDP plugin TCP plugin JABBER MD5 OK OK ERR ERR transferencia TCP: conexión directa plugin UDP plugin TCP plugin JABBER MD5 OK OK ERR ERR

11 En ambos tipos de transferencias, los errores suceden en los protocolos de alto nivel, se barajan algunas posibilidades que aún no han sido comprobadas completamente. Los posibles fallos pueden suceder por: El código de los plugines no hace comprobación de cabeceras. No viaja el contenido completo de los buffers por un problema de tamaños, sólo viaja una parte de éste. Al disminuir el MTU 8 del dispositivo virtual TUN, se lograron en algunas ocasiones transferencias correctas sobre el plugin TCP. Suponemos que la fragmentación que sucede en los router por los que viajan los paquetes puede afectar en la recepción de datos. Un interesante artículo [Titz, 2001] explica los inconvenientes de encapsular TCP sobre TCP. 5. Conclusiones y direcciones futuras Una de las características más atractivas que esta arquitectura propone es la capacidad de interactuar con más de un servidor de manera simultánea, ofreciendo no sólo una medida efectiva contra posibles fallos, si no que también un uso más completo del ancho de banda total, rompiendo el esquema tradicional que hasta hoy han seguido las anteriores implementaciones de túneles, las cuales sólo operan con un host. Desde el punto de vista de la encapsulación de datos y transporte, es siempre deseable realizarla en protocolos no muy elaborados o de alto nivel como el caso de la mensajería instantánea. Debido a que estos agregan mucho overhead y suelen aumentar la latencia (servidores intermedios), es por esto que se sugiere utilizar estos protocolos sólo como mecanismos de transporte donde las políticas de red sean muy restrictivas y dicho protocolo sea el único medio posible para comunicarse con el exterior. Siempre será recomendable establecer comunicación sobre protocolos donde el overhead sea el menor posible y no incluyan mecanismos de control, el mejor ejemplo de esto, es el protocolo UDP[Postel, 1980]. Con respecto al diseño de la arquitectura, hay algunos puntos donde no se ha entrado en mayores detalles, principalmente en el sistema de autentificación, el comportamiento general de los plugins (métodos y propiedades), y el formato de los paquetes encapsuladores (cabeceras exclusivas de la aplicación). Estos pretenden ser evaluados una vez que se tenga un prototipo más elaborado y posteriormente implementados Debe mencionarse que si bien se desarrollará el sistema como una implementación independiente de túneles IP, en el futuro se plantea ir adaptando esta arquitectura en algún proyecto de túneles de código abierto existente, ya que permitiría aprovechar código ampliamente probado y depurado para cubrir las funciones indispensables de una tecnología de túneles, y mas aún, redes privadas virtuales. 8 Maximum transmission unit

12 Referencias [Ciarlante, 2005] Ciarlante, J. J. (2005). VPN sobre Mensajería Instantánea. [Deering and Hinden, 1998] Deering, S. and Hinden, R. (1998). Protocolo Internet, Versión 6 (IPv6). RFC 2460 (Draft Standard). [P. Saint-Andre, 2004] P. Saint-Andre, Ed, J. S. F. (2004). Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. [Postel, 1980] Postel, J. (1980). User Datagram Protocol. [Srisuresh and Egevang, 2001a] Srisuresh, P. and Egevang, K. (2001a). Documento de guía para IPSec. RFC 3022 (Informational). [Srisuresh and Egevang, 2001b] Srisuresh, P. and Egevang, K. (2001b). Traditional IP Network Address Translator (Traditional NAT). RFC 3022 (Informational). [Titz, 2001] Titz, O. (2001). Why TCP Over TCP Is A Bad Idea.