Cuadernos de Tecnología en Redes de Computadoras
Anuncio
Universidad Nacional de Luján Departamento de Ciencias Básicas División Estadística y Sistemas Asignatura Teleinformática y Redes Cuadernos de Tecnología en Redes de Computadoras Número 1 Editor: Lic. Fernando R. A. Bordignon Profesor Adjunto Departamento de Ciencias Básicas [email protected] Cuadernos de Tecnología en Redes de Computadoras/Universidad Nacional de Luján, n. 1, (2001), Luján:UNLu, 2001. Publicación oficial del Departamento de Ciencias Básicas de la Universidad Nacional de Luján, aprobada en el Concurso Anual de Publicaciones DCB 2002. Agosto 2001 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB La presente obra es propiedad intelectual del autor. Prohibida su reproducción parcial o total por cualquier medio, sin permiso por escrito de su editor. 2 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Prólogo La presente colección, que comienza con este número, tiene por finalidad servir de apoyo a estudiantes de la asignatura Teleinformática y Redes en la Carrera Licenciatura en Sistemas de Información de la Universidad Nacional de Luján, como así también de instrumento de actualización a graduados en carreras afines a la informática. Se espera que estos cuadernos sean de utilidad como elemento de actualización permanente en esta área del conocimiento de evolución continua. Con esta publicación será posible promover y difundir la tecnología de redes de datos cumpliendo con el objetivo de informar, compartiendo conocimientos e intercambiando ideas. Se hace una cordial invitación a profesores y alumnos que deseen participar con artículos, relatos de experiencias, etc., relacionados con la tecnología de redes de datos. Toda contribución debe llegar al editor por medio de correo electrónico a la cuenta [email protected]. 3 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 4 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB INDICE Artículos Técnicas de NAT Gabriel Tolosa Fernando Lorge Fernando Bordignon Acceso a Servicios de Red Vía Protocolo PPPoE Fernando Bordignon Gabriel Tolosa Gnutella: Sistema Distribuido para Almacenamiento y Búsqueda de Información. Descripción del Modelo Fernando Bordignon Gabriel Tolosa Caracterización del Protocolo SOCKS, Versión 5. Gabriel Tolosa Fernando Bordignon 5 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 6 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB TECNICAS DE NAT Gabriel Tolosa, Fernando Lorge y Fernando Bordignon Universidad Nacional de Luján División Estadística y Sistemas, Luján, Argentina {tolosoft,florge,bordi}@unlu.edu.ar Introducción El intenso crecimiento de Internet hace que miles de usuarios nuevos se conecten cada día. Este crecimiento ha causado considerables problemas, debido al hecho que la infraestructura de Internet y sus protocolos básicos fueron desarrollados hace décadas atrás, cuando sólo unos miles de equipos se conectaban bajo el juego de protocolos TCP/IP. Por consiguiente, el protocolo de red IP, no está diseñado para proporcionar suficientes direcciones únicas para todos los equipos que operan sobre Internet. Una solución efectiva, a futuro, está dada por la nueva versión de protocolo IP (versión 6). Y se basa en expandir el dominio de direcciones de equipos sobre Internet. Pero la transición a IPv6 es lenta y demorará un par de años en alcanzar al conjunto de equipos que conforman la red. Soluciones transitorias al problema antedicho han sido propuestas, y se hallan ampliamente difundidas. Una de tales soluciones está dada en el caso de que una organización utilice un esquema de direcciones asignadas a sus equipos, y su acceso a Internet sea a través de servidores apoderados ó proxies, de tal manera que solo se necesitará un conjunto mínimo de direcciones públicas para asignar a las interfaces de sus ruteadores y equipos intermediarios. Otra posible solución, de la cual trata este documento, es asignar a la organización un esquema de direcciones privadas pero con la condición de que se transformen en públicas cuando los datagramas necesiten salir a Internet. Dado que no todos los quipos se conectan siempre concurrentemente a Internet solo bastará poseer un conjunto reducido de direcciones públicas. La ventaja de esta técnica, denominada NAT (Network Address Translation), es que su operación es transparente e independiente de las aplicaciones que soportan. [1] 7 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Red Pública, a ISP Modem 141.33.22.11 Frontera de red 192.168.0.3 PC Router Solución 1 PC router opera como servidor Proxy Solución 2 PC router opera como router NAT Repetidor Red Privada 192.168.0.2 192.168.0.3 192.168.0.4 NAT, Network Address Translation La traducción de direcciones de red (NAT), definida originalmente en el RFC 1631 [2], es un conjunto de técnicas que posibilitan que un conjunto de direcciones IP sean mapeadas desde un dominio de direcciones a otro, proporcionando encaminamiento transparente a los equipos finales [4]. Existen muchas variantes de traducción de direcciones destinadas a distintas aplicaciones. Sin embargo, todos las variantes de dispositivos NAT deberían compartir las siguientes características: a) Asignación transparente de direcciones. b) Encaminamiento transparente mediante la traducción de direcciones (aquí el encaminamiento se refiere al reenvío de paquetes, no al intercambio de información de encaminamiento). c) Traducción de la carga útil de los paquetes de error ICMP. A continuación se muestra un diagrama que ilustra un escenario donde se habilita NAT en un ruteador de frontera de una organización, conectado a Internet a través de un ruteador regional de un proveedor de servicios. 8 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Proveedor de servicios Ruteador Regional Enlace WAN Frontera LAN Ruteador de frontera con capacidad de NAT Red Privada Tradicionalmente, la técnica NAT se ha utilizado para conectar un dominio de direcciones privadas con un dominio externo de direcciones públicas (registradas globalmente). La necesidad de la traducción de direcciones IP aparece cuando las direcciones IP internas de la red no pueden ser usadas fuera de la red, bien porque no son válidas en el exterior, ó porque el direccionamiento interno debe mantenerse separado de la red externa (política de seguridad). La traducción de direcciones permite que las máquinas de una red privada se comuniquen de manera transparente con equipos ubicados en la red externa y viceversa. Los equipos que proveen servicio NAT brindan una solución de encaminamiento transparente a los equipos de una red privada que intentan comunicarse con otros equipos de una red externa. Esto se consigue modificando “on the fly” (al vuelo) las direcciones de red IP de los equipos de la red interna y manteniendo el estado de estos cambios para que los datagramas pertenecientes a una sesión sean ruteados hacia el equipo destino correcto en cualquiera de los dominios. Esta solución sólo funciona cuando las aplicaciones no usan las direcciones IP como parte del propio protocolo de aplicación. NAT no siempre, puede soportar por sí mismo todas las aplicaciones de manera transparente, y por esta razón a menudo debe coexistir con "Pasarelas de Nivel de Aplicación", Application Level Gateways. 9 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB El siguiente gráfico muestra los componentes de un sistema NAT. Dominio externo de direcciones N-Ext Host-X Addr-X Addr-Nx Ruteador NAT Addr-Np Dominio privado de direcciones N-Pri Host-A Addr-A La máquina Host-A, con dirección Addr-A, se encuentra en un dominio privado, representado por la red N-Pri. Donde N-Pri está aislada del dominio externo de red mediante un ruteador NAT. La máquina Host-X, con dirección Addr-X, se encuentra en un dominio externo, representado por la red N-Ext. El ruteador NAT con dos interfaces, cada una asignada a uno de los dominios, proporciona encaminamiento transparente entre los dos dominios. La interface hacia el dominio externo tiene asignada una dirección de Addr-Nx y la interface hacia el dominio privado tiene asignada una dirección de Addr-Np. Además, se puede considerar que las direcciones Addr-A y Addr-Np corresponden a la red N-Pri y que las direcciones Addr-X y Addr-Nx corresponden a la red N-Ext. Existen diversas variantes de traducción de direcciones, cada una de las cuales es una solución a diferentes situaciones. Una lista de variantes de NAT está definida en el documento RFC 2663 denominado “IP Network Address Translator (NAT) Terminology and Considerations” [4]. La traducción de direcciones puede realizarse estática ó dinámicamente. En el modo estático, un número fijo de direcciones de red privada es mapeado a un mismo número de direcciones de red pública. En la técnica de traducción dinámica la asociación entre una dirección de red privada y una pública no es fija, sino que depende de muchos factores. Es decir que a una misma dirección de red privada, a 10 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB lo largo de una sesión de trabajo, pueden corresponderle varías direcciones de red publica. Las letras m y n representan el número de direcciones IP que necesitan ser traducidas y el número de direcciones IP disponibles para la traducción respectivamente. Traducción estática (Static NAT) Donde m,n > 1 y m = n, es decir que se tienen el mismo número de direcciones públicas y privadas. La operación de traducción no requiere información adicional, más allá de una simple tabla ó regla de transformación que determine cúal es la dirección IP pública que le corresponde a cada dirección IP privada. Con solo inspeccionar la cabecera de cada datagrama IP alcanza para realizar la operación antedicha. Suponga que se aplica la siguiente regla: Traduzca todas las direcciones de la red privada 192.168.1.0/24 a direcciones de la red pública 170.210.10.0/24. Es decir que a la dirección 192.168.1.22 siempre le corresponderá la dirección 170.210.10.22. 192.168.1.10 192.168.1.9 --- 170.210.10.9 192.168.1.10 --- 170.210.10.10 192.168.1.11 --- 170.210.10.11 Internet Router NAT 208.222.14.9 1 Origen Destino 192.168.1.10 208.222.14.9 2 Origen Destino 208.222.14.9 192.168.1.10 4 11 Origen Destino 170.210.10.10 208.222.14.9 Origen Destino 208.222.14.9 170.210.10.10 3 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Traducción dinámica (Dynamic NAT) Donde m>=1 y m >= n. En este modelo el número de direcciones IP privadas son mayores o iguales que el número de direcciones públicas disponibles. Como se vió no existe una asignación previa entre los dos dominios de direcciones, siendo una vinculación temporal solamente a los efectos de requerir un servicio de red externo. En el momento en que todas las direcciones públicas están siendo utilizadas no se tienen recursos para nuevos pedidos de traducción, por lo que cualquier nuevo pedido será rechazado por el ruteador. La información acerca de las vinculaciones entre direcciones IP privadas y públicas se mantiene en una tabla sita en el ruteador NAT. Cada entrada es una asociación entre una dirección IP pública y una privada; una vinculación posee tiempo máximo de permanencia en tabla, luego del cual es eliminada. Un ejemplo de regla de traducción es el siguiente: ♦ Traduzca todas las direcciones IP de la clase B privada 172.16.0.0 a direcciones públicas en el dominio de la clase C 200.1.2.0 ♦ Por cada nuevo pedido de conexión desde una dirección IP de la red privada hacía la red pública, el ruteador NAT consultará sus tablas a los efectos de determinar si existe una entrada (vinculación previa). En caso de existir, traducirá los datagramas correspondientes con tal dirección. De lo contrario (no existe la entrada en tabla), en caso de existir direcciones IP públicas disponibles, creará una nueva entrada en la tabla y saldrá con la nueva dirección IP pública asignada. En caso de no haber direcciones públicas libres rechazará el pedido de traducción. 12 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 192.168.1.9 192.168.1.9 --- 170.210.10.9 192.168.1.10 --- 170.210.10.10 192.168.1.10 Internet 192.168.1.1 Router 170.210.10.1 NAT 208.222.14.9 192.168.1.15 1 Origen Destino 192.162.1.15 208.222.14.9 Origen Destino 192.168.1.1 192.168.1.15 2 Error: No hay direcciiones de red públicas disponibles IP Masquerade (NAPT) Donde m>=1 y n=1. Es una forma de traducción de direcciones de red privada a red pública, donde un equipo que ofrece un servicio IP-Masquerade tomará cada paquete entrante ó saliente, lo analizará y modificará su dirección de red y puerto destino ú origen en base a reglas de sustitución. De este manera las aplicaciones que estan en una red privada, de forma transparente, podrán conectarse con equipos en Internet a través de la utilización de una sola dirección IP pública. [1,2] Ventajas • Se necesita solo una dirección IP pública para que n equipos accedan a Internet. • Es transparente a las aplicaciones • Esconde una red interna 13 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Desventajas • El tráfico entrante solo puede acceder a la red interna en caso de que un equipo de la organización haya requerido un servicio. Pocas versiones de IP Masquerade soportan Port forwarding, para habilitación de servicios internos. 192.168.1.10 192.168.1.15 Internet 192.168.1.15 Router 170.210.10.1 NAT 208.222.14.9 192.168.1.10:1250 --- 170.210.10.1:6001 192.168.1.15:1500 --- 170.210.10.1:6002 1 Origen Destino 192.168.1.10:1250 208.222.14.9:110 2 Origen Destino 170.210.10.1:6001 208.222.14.9:110 Origen Destino 208.222.14.9:110 170.210.10.1:6001 Origen Destino 208.222.14.9:110 192.168.1.10:1250 3 4 IP Masquerade está implementado en dispositivos de interconexión (ruteadores, LAN modems, modems ADSL, etc) como así tambien en distribuciones del sistema Operativo UNIX. En el caso particular del sistema operativo Linux, a partir de la versión de kernel 2.2.x, se encuentra disponible (sin necesidad de recompilar el kernel) para su utilización. Aplicaciones tales como Telnet, FTP, ping, traceroute operan sin ningún inconveniente sobre un esquema de IP-Masquerade subyacente. En cambio para otras aplicaciones, IRC y Real Audio, es necesario anexar módulos auxiliares en el gateway. 14 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 1er rango – clase A 1do rango – clase B 3er rango – clase C De 10.0.0.0 172.16.0.0 192.168.0.0 A 10.255.255.255 172.16.255.255 192.168.255.255 Rangos de clases reservadas para redes IP privadas RFC 1918, "Address Allocation for Private Internets" Un ejemplo (extraído del documento “IP Masquerade FAQ” mantenido por Ken Eves) demuestra como opera la técnica IP masquerade: A ISP PPP/SLIP PPP - SLIP Modem 1 111.222.121.212 Modem 2 Modem 3 Linux #1 Anybox 192.168.0.100 La capacidad de IP masquerade ha sido instalada y configurada en el equipo 1, el cual está conectado a Internet por la interface 111.222.121.212 (vía modem #1 con protocolo de enlace SLIP ó PPP). Además posee un modem #2 que detecta conexiones entrantes (vía protocolos de enlace PPP ó SLIP). Un equipo –anyboxestablece una comunicación con Linux #1, y se le asigna (dinámicamente ó de forma estática) una dirección de red probada 192.168.0.100. Al operar IP masquerade en Linux #1 anybox puede acceder a Internet como si tuviera una dirección IP pública y Linux #1 fuera solamente un ruteador. Veamos como opera la técnica: • Cuando un datagrama, con destino un equipo de Internet, llega a linux #1 proveniente de anybox, este le asignará un nuevo puerto TCP origen y reemplazará la dirección IP origen con la propia (su dirección pública), los datos originales son almacenados en una tabla. Luego, Linux #1, enviará el datagrama modificado por la interface de salida a Internet. • Cuando un datagrama arriba de Internet, Linux #1 examina si el número de puerto TCP destino coincide con alguno de los que él instanció previamente (revisa su tabla). En caso de coincidir con alguno reemplazará la dirección IP y puerto TCP destino con los correspondientes de la red interna, y finalmente entregará el datagrama al equipo anybox. 15 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Ni Anybox, ni el equipo de Internet sabrán algo acerca del equipo Linux #1, es decir que el objetivo de transparencia se ha logrado. Mapeo de puertos (Port mapping) Es una técnica que permite que equipos pertenecientes a la red privada, y que ofrezcan servicios de aplicación (por ejemplo un servidor POP3 ó un servidor HTTP), puedan ser accedidos desde equipos pertenecientes a una red externa. Cada datagrama que se recibe del exterior es analizado en base a una tabla de servicios internos ofrecidos, donde si coincide con alguno de los listados, la PDU es modificada cambiando la dirección IP y puerto destino pertenecientes al equipo de la red interna. IP 201.203.203.204 IP 192.168.1.1 Servidor HTTP 192.168.1.2:80 Internet Ruteador NAT con Port Mapping Cliente web, POP3 y Telnet Reglas de Mapeo de Puertos Paquetes al puerto 80=>192.168.1.2 Paquetes al puerto 110=>192.168.1.3 Paquetes al puerto 23=>192.168.1.4 Servidor POP3 192.168.1.3:110 Servidor Telnet 192.168.1.4:23 Ejemplo de IP-Masquerade en Linux Las principales distribuciones de Linux vienen con su kernel adecuado para utilizar IP-Masquerading. Un script de automatización de la configuración de IPMasquerading es necesario (ver scritp). Se lo instala en el camino /etc/rc.d/init.d/ bajo el nombre rc.firewall. Los permisos deben ser 755 (chmod 755). El script asume que se ha utilizado la dirección IP 192.168.0.1 en la interface que conecta la red interna (ifconfig eth0 192.168.0.1 netmask 255.255.255.0). #!/bin/sh echo "Configurando IP masquerading ..." # # Soporte masquerade para FTP. /sbin/modprobe ip_masq_ftp # # Soporte masquerade para RealAudio sobre UDP. 16 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB #/sbin/modprobe ip_masq_raudio # # Soporte masquerade para transferencia de ficheros IRC DCC #/sbin/modprobe ip_masq_irc # # Soporte masquerade para Quake I / QuakeWorld (ports 26000 and 27000) #/sbin/modprobe ip_masq_quake # # Soporte masqueradepara software de video conferencia CuSeeme #/sbin/modprobe ip_masq_cuseeme # # Soporte masquerade para software de video conferencia VDO-live #/sbin/modprobe ip_masq_vdolive # # Habilita IP forwarding. Esta deshabilitado por defecto. Echo "1" > /proc/sys/net/ipv4/ip_forward # # NOTA: Esto es un ejemplo para la direccion de red interna # 192.168.0.x La mascara de subred es 255.255.255.0 o "24" bit # Modificar esto si utilizas una direccion interna diferente. # /sbin/ipchains -P forward DENY /sbin/ipchains -A forward -s 192.168.0.0/24 -j MASQ # #--- Línea final El siguiente gráfico muestra la disposición de la red que se está configurando Red Pública, a ISP 141.33.22.11 Red Privada 192.168.0.3 Modem 192.168.0.2 Repetidor PC con IP-Masquerading 192.168.0.3 192.168.0.4 17 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB La dirección de gateway por defecto para los equipos de la red privada es 192.168.0.1. Para comenzar a brindar servicio IP-Masquerade se debe ejecutar, con permisos de root, la script anterior. Ejemplo de captura de datos en un ruteador NATP Topología Red Pública, Red Privada 192.168.0.1 25:e7:55 170.210.102.13 25:e7:54 170.210.102.23 72:ff:e7 PC con IP-Masquerading 192.168.0.23 dc:39:91 El enmascaramiento se activo con la siguiente secuencia de comandos: echo "1" > /proc/sys/net/ipv4/ip_forward /sbin/ipchains -P forward DENY /sbin/ipchains -A forward -s 192.168.0.0/24 -j MASQ Acción: Ejecución del comando ping desde 192.168.0.23 a 170.210.102.23 Ethernet Header(792356671.135747) Hardware source: 52:54:0:dc:39:91 Hardware destination: 0:40:5:25:e7:55 Protocol type: 800H (ip) IP Header Version: 4 Header length: 20 Type of service: 0 Total length: 84 Identification #: 49 Fragmentation offset: 0 (U=0,DF=0,MF=0) Time to live: 64 Protocol: 1 Header checksum: 43215 Source address 192.168.0.23 Destination address 170.210.102.23 ICMP Header Type: 8 (echo request) Code 0 Identifier 177 Sequence number 0 Checksum: 26504 18 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB ================================================================= Ethernet Header(792356671.135747) Hardware source: 0:40:5:25:e7:54 Hardware destination: 0:e0:7d:72:ff:e7 Protocol type: 800H (ip) IP Header Version: 4 Header length: 20 Type of service: 0 Total length: 84 Identification #: 49 Fragmentation offset: 0 Time to live: 63 Protocol: 1 Header checksum: 22959 Source address 170.210.102.13 Destination address 170.210.102.23 ICMP Header Type: 8 (echo request) Code 0 Identifier 18926 Sequence number 0 Checksum: 10815 ================================================================= Ethernet Header(792356671.135747) Hardware source: 0:e0:7d:72:ff:e7 Hardware destination: 0:40:5:25:e7:54 Protocol type: 800H (ip) IP Header Version: 4 Header length: 20 Type of service: 0 Total length: 84 Identification #: 37123 Fragmentation offset: 0 Time to live: 128 Protocol: 1 Header checksum: 34780 Source address 170.210.102.23 Destination address 170.210.102.13 ICMP Header Type: 0 (echo reply) Code 0 Identifier 18926 Sequence number 0 Checksum: 12863 ================================================================= Ethernet Header(792356671.135747) Hardware source: 0:40:5:25:e7:55 Hardware destination: 52:54:0:dc:39:91 Protocol type: 800H (ip) IP Header Version: 4 Header length: 20 Type of service: 0 Total length: 84 19 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Identification #: Fragmentation offset: Time to live: Protocol: Header checksum: Source address Destination address ICMP Header Type: Code Identifier Sequence number Checksum: 37123 0 127 1 55548 170.210.102.23 192.168.0.23 0 (echo reply) 0 177 0 28552 Balanceo de cargas vía NAT Existe un proyecto denominado Linux Virtual Server [6] que consiste en construir un sistema escalable, de alta disponibilidad, para brindar servicios (por ejemplo HTTP); en base a un agrupamiento de servidores reales que corren sistema operativo Linux . La clave del proyecto es utilizar técnicas de NAT para implementar balanceo de cargas. La arquitectura es transparente para los usuarios finales, dado que ellos ven solo un servidor virtual. Servidor Virtual Servidor real Servidor real LAN/WAN privada Internet Host h Balanceador de cargas Servidor real Servidor real En el gráfico anterior se observa la arquitectura del sistema de servidores virtuales. Los servidores reales (real servers) se conectan a una LAN ó WAN de alta velocidad. El equipo que brinda el servicio de vinculación con la red pública se denomina balanceador de cargas (load balancer), y tiene por misión atender 20 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB requerimientos de equipos provenientes de la red externa y derivarlos en forma igualitaria a los servidores reales manteniendo la visión del servicio desde el exterior a través de una única dirección de red IP. La disponibilidad y escabilidad se obtiene agregando o quitando servidores reales de forma transparente. En el proyecto, existen tres métodos de implementación de balanceo de cargas por medio de reenvio de datagramas IP (IP packet forwarding), son: servidor virtual vía NAT, servidor virtual vía túnel IP y servidor virtual vía ruteo directo. En el caso de balanceo de cargas vía NAT se utilizan servidores reales (SR) con un esquema de direcciones de red privadas y bajo cualquier sistema operativo. Solamente el equipo denominado balanceador de cargas (BC) corre el sistema operativo Linux configurado para operar con el software de balanceo de cargas. Dado que es un equipo multihomed, una interface está en la red pública y otra en la red privada. Experiencias prácticas han determinado que la cantidad máxima de SR de un servidor virtual debe ser 20, dado que si se superara tal cifra podrían sufrirse problemas de embotellamiento (esto se ve como una notable desventaja de este modelo) dado que los datagramas entrantes como salientes necesitan ser modificados por el equipo SR. El gráfico siguiente, ilustra la secuencia paso a paso para recuperar un recurso por parte de un host h. 21 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Servidor Virtual 2 -programación y reescritura 4 -procesamiento del requerimiento 1- requerimiento Servidor real Servidor real Internet Bridge Host h Balanceador de cargas Servidor real 4 - reescritura de la respuesta Servidor real En el paso 1, el host h envía un requerimiento al equipo BC direccionado a su interface de red pública. BC inspecciona la dirección IP y puerto TCP destino del datagrama entrante (paso 2), si coincide con la dirección del servidor virtual (se contrasta contra una tabla de reglas de servicios) se selecciona un SR, se modifica la dirección y puerto destino de datagrama y por último se lo reenvía al SR seleccionado. Las conexiones establecidas se almacenan en una tabla a los efectos de poder gerenciar los datagramas entrantes y salientes. Paso 3, al llegar un pedido de conexión a un SR se lo atiende de igual forma que si el servicio de balanceo de cargas no existiera, todas las respuestas a requerimientos serán direccionadas al equipo BC (default gateway), el cual reenviará a host h (paso 4) los datagramas modificando la dirección y puerto origen. Al finalizar la conexión ó vencer un timer, la entrada correspondiente en la tabla de conexiones es eliminada. 22 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Servidor Virtual Servidor real 192.168.1.2 Internet 192.168.1.1 200.1.2.3 Bridge Host h 70.210.21.2 Balanceador de cargas 192.168.1.3 Servidor real La red IP en la cual se estableció el servidor virtual es la 192.168.1.0 y su gateway por defecto es 192.168.1.1. El software ipfwadm se instaló en el equipo BC a los efectos de reenviar los datagramas provenientes de los equipos SR. echo 1 > /proc/sys/net/ipv4/ip_forward (activa ruteo) ipfwadm -F -a m -S 192.168.0.0/24 -D 0.0.0.0/0 Protocolo Dirección pública Port TCP 200.1.2.3 80 TCP 200.1.2.3 21 Dirección IP Servidor real 192.168.1.2 192.168.1.3 192.168.1.3 Port 80 8080 21 Peso 1 2 1 La tabla anterior, que se halla en BC, define las reglas de servicio; donde todo el tráfico destinado a la dirección IP pública 200.2.1.3 puerto 80 es distribuido entre las direcciones internas de SR 192.168.1.2 y 92.168.1.3 puertos 80 y 8080 respectivamente. El tráfico destinado al puerto 21 es reenviado solamente al SR 92.168.1.3 puerto 21. A continuación se muestra un ejemplo de reescritura de datagramas: 23 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 1- Un datagrama entrante destinado a un servicio web: ORIGEN 70.210.21.2:1234 DESTINO 200.1.2.3:80 2- El equipo BC selecciona el SR 192.168.1.3:8080, el datagrama se reescribe y queda de la siguiente forma para ser reenviado al SR ORIGEN 70.210.21.2:1234 DESTINO 192.168.1.3:8080 3- El equipo BC recibe del SR el datagrama respuesta: ORIGEN 192.168.1.3:8080 DESTINO 70.210.21.2:1234 4- El datagrama es reescrito y reenviado al host cliente ORIGEN 200.1.2.3:80 DESTINO 70.210.21.2:1234 Problemas relacionados con NAT La operación de traducciones de red no siempre garantiza el funcionamiento correcto de los protocolos superiores. Algunos protocolos incluyen en sus mensajes sus propias direcciones de red, esto hace que pueda fallar una operación determinada, por ejemplo una transferencia de datos FTP. El modo en que frecuentemente se soluciona esto es que en el ruteador NAT inspeccione y cambie valores de los mensajes correspondientes a protocolos superiores a los de red. Por ejemplo, el comando FTP PORT y la respuesta a PASV envían una dirección IP y un puerto. Para que el protocolo pueda funcionar desde una red de direcciones privadas es necesario convertir los parámetros antedichos a direcciones públicas en el ruteador En el protocolo de control ICMP algunos mensajes, en su carga, incluyen una parte de la cabecera IP del datagrama original que causó tal respuesta. La dirección IP del mensaje necesita ser traducida, y esto debe hacerlo el ruteador NAT. Para el caso particular del servicio de conversión de nombres DNS, se aconseja instalar un servidor de nombres en la frontera de los dominios de direcciones, para satisfacer la demanda de los equipos de la red privada. Otra alternativa, mucho más compleja, es instalar un servicio de traducción de mensajes situado en el ruteador NAT. Bibliografía [1] Hasenstein, M., "Diplomarbeit: IP Network Address Translation", Chemnitz University of Technology, Chemnitz, Germany, 1997. 24 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB [2] Egevang, K. Y Francis, P., “The IP Network Translator (NAT)”, RFC 1631, Mayo 1994. [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, Febrero 1996. [4] Srisuresh y Holdrege, “IP Network Address Translator (NAT) Terminology and Considerations”, RFC 2663, Agosto 1999 [5] Cisco Inc. “How NAT Works”, Tech Notes, http://www.cisco.com/warp/public/556/nat-cisco.shtml [6] Proyecto Linux Virtual Server, http://www.linuxvirtualserver.org 25 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 26 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB ACCESO A SERVICIOS DE RED VÍA PROTOCOLO PPPOE Fernando Bordignon y Gabriel Tolosa Universidad Nacional de Luján División Estadística y Sistemas, Luján, Argentina {bordi,tolosoft}@unlu.edu.ar Resumen El protocolo PPP (Point-to-Point Protocol) [1] ofrece un método estándar para el transporte de PDUs de distintos protocolos de red sobre enlaces punto a punto. En el presente documento, en una primer parte, se describirá como encapsular PDUs PPP sobre tramas Ethernet y en una segunda parte, se caracterizará someramente ADSL, dado que los bridges remotos Ethernet utilizan esta tecnología de enlace para loop de abonado. Introducción PPP provee un protocolo para control de enlace (LCP), un protocolo para control de red (NCP), esquemas de autenticación y encriptación de datos. Estas características fueron pensadas para implementar en enlaces punto a punto y no para operar sobre enlaces multipunto, tal como es el caso de Ethernet. Al implementar PPPoE [2] es posible tener n sesiones PPP sobre un único enlace entre el cliente y el proveedor de servicio. El enlace entre segmentos Ethernet se logra por medio bridges remotos. Se puede implementar más de un bridge remoto en una misma organización, lo que llevaría a obtener mayor capacidad de ancho de banda para atender más sesiones concurrentes. PPPoE proporciona la capacidad de conectar una red de hosts sobre un único dispositivo de acceso (bridge remoto) a un concentrador de acceso remoto. Con este modelo, cada host utiliza su protocolo PPP. El control de acceso, facturación, encriptación y tipo de servicio es hecho por usuario y no sobre el conjunto de hosts que comparten el acceso remoto. Para proporcionar una conexión punto a punto sobre Ethernet, cada sesión PPP debe establecerse sobre un concentrador de acceso remoto. PPPoE define un 27 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB protocolo auxiliar llamado Discovery que permite a un host seleccionar un concentrador de acceso remoto para entablar luego una sesión PPP. Concentrador de Acceso Remoto Ethernet Bridge remoto Concentrador de Acceso Remoto Enlace Punto a Punto (por ej. ADSl) Ethernet Bridge remoto Host usuario Host usuario PPoE tiene dos etapas distintas, la etapa de Discovery (descubrimiento) y la etapa de Sesión PPP. Cuando un host desea iniciar una sesión PPPOE, este primero debe realizar el descubrimiento de un concentrador de acceso remoto que quiera atenderlo. A partir de la aceptación de servicio por parte del concentrador de acceso remoto, el host obtendrá un identificador de sesión (SESSION_ID). Finalizada la fase anterior comienza la sesión PPP, ahora el host negociará con el servidor PPP protocolos de red, facilidades y datos necesarios para levantar el nivel de red. 28 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB La pila de protocolos necesaria para establecer un vínculo TCP/IP sobre PPPoE es la siguiente: IP PPP PPPoE ETHERNET Medio Estructuras de datos Frame Ethernet ♦ Campo DESTINATION_ADDR contiene la dirección MAC del destino donde se envía el mensaje. ♦ Campo SOURCE_ADDR contiene la dirección MAC del host originante del mensaje. ♦ Campo ETHER_TYPE está instanciado con el valor 0x8863 en el estado Discovery y 0x8864 en el estado sesión PPP. DESTINATION_ADDR (6 bytes) SOURCE_ADDR (6 bytes) ETHER_TYPE (2 bytes) Payload (hasta 1500 bytes) CHECKSUM (4 bytes) Frame Ethernet Frame PPPoE 29 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB ♦ Campo VER (4 bits) define la versión de protocolo PPPoE (la actual es 0x1) ♦ Campo TYPE (4 bits) define un subtipo de versión de protocolo PPPoE (la actual es 0x1 ♦ Campo CODE (8 bits) Indica tipo de mensaje ♦ Campo SESSION_ID (16 bits) indica el número de sesión al cual pertenece el mensaje. En caso de que la sesión no este establecida (estado discovery) se instancia en cero. ♦ Campo LENGTH (16 bits) indica el largo de la carga (no incluye el largo de la cabecera Ethernet ni de la cabecera PPPoE. VER (4 bits) TYPE (4 bits) CODE (1 byte) SESSION_ID (2 bytes) LENGTH (2 bytes) Payload Frame PPPoE Protocolo auxiliar Discovery. Modo de operación El protocolo auxiliar Discovery opera en modalidad sin estado. Un host (C) que desee establecer una conexión PPP inicia su operación en esta fase emitiendo un mensaje broadcast tendiente a descubrir concentradores de acceso PPPoE (CA). En esta fase se ejecutan cuatro pasos a saber: Initiation: El host C emite un mensaje ethernet broadcast (PADI - PPPoE Active Discovery Initiation, CODE 0x09 y SESSION_ID 0x0000) solicitando por concentradores de acceso. Offer: Los concentradores de acceso que recibieron el mensaje PADI contestan en modo unicast al host C, mediante un mensaje PADO (PPPoE Active Discovery Offer, CODE 0x07 y SESSION_ID 0x0000). Session Request: Aquí el host C envía un mensaje PADR (PPPoE Active Discovery Request, CODE 0x19 y SESSION_ID 0x0000) dirigido al 30 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB concentrador de acceso seleccionado, indicándole que desea establecer una conexión PPP con él. Confirmation: El concentrador de acceso, al aceptar el pedido de conexión, envía al host C un mensaje PADS (PPPoE Active Discovery Sessionconfirmation , CODE 0x65) donde confirma la aceptación del servicio y le envía un número de sesión (SESSION_ID). De ahora en más y hasta la finalización de la conexión, las direcciones MACs conjuntamente con el número de sesión identificaran unívocamente la conexión PPP. Los mensajes intercambiados, correspondientes a los pasos anteriores, llevan campos adicionales denominados TAGS, utilizados para negociar facilidades de servicio. Un Tag se implementa por medio de 3 campos a saber: TAG_TYPE (2 bytes), TAG_LENGHT (2 bytes) y TAG_VALUE (largo definido en el campo anterior). Un mensaje puede transportar más de un tag. Existe un mensaje de finalización de sesión denominado PADT (PPPoE Active Discovery Terminate) con campo CODE instanciado con 0xA7 y SESSION_ID debe estar instanciado el número de sesión a finalizar. Los mensajes de la fase Discovery tienen instanciado el campo ETHER_TYPE con el valor 0x8863, y en una sesión PPP se le asigna el valor 0x8864. Todos las tramas Ethernet son unicast. El campo CODE se instancia con el valor 0x00. El valor del campo SESSION_ID no debe variar a lo largo de la sesión. La carga útil de todo mensaje PPPoE siempre contendrá un mensaje PPP a lo largo de una sesión. Sesión PPP Una vez finalizada la fase de Discovery comienza una sesión PPP, cuyos mensajes son enviados como en cualquier otro tipo de encapsulamiento. En el proceso de negociación de parámetros del enlace PPP el valor de MRU (Maximum-Receive-Unit) no debe ser negociado por sobre los 1492 bytes. Dado que Ethernet limita la carga máxima a 1500 bytes, el header PPPoE es de 6 bytes y la cabecera de protocolo PPP ocupa 2 bytes. Se recomienda que el concentrador de acceso, periódicamente, envíe mensajes Echo-Request al host para verificar el estado de la sesión. Ejemplos de mensajes Mensaje PADI, inicio de fase discovery 31 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB DESTINATION_ADDR SOURCE_ADDR = 0xffffffffffff = 0x0010DC6F5274 (dirección del host solicitante) ETHER_TYPE = 0x8863 VERSION = 1 TYPE = 1 CODE = 0x09 SESSION_ID = 0x0000 LENGTH = 0x0004 TAG_TYPE = 0x0101 TAG_LEN = 0x0000 Mensaje PADO, respuesta de un concentrador de acceso a un mensaje PADI DESTINATION_ADDR SOURCE_ADDR = 0x0010DC6F5274 = 0x00101A6F5211 (dirección concentrador acceso) ETHER_TYPE = 0x8863 VERSION = 1 TYPE = 1 CODE = 0x07 SESSION_ID = 0x0000 LENGTH = 0x0020 TAG_TYPE = 0x0101 TAG_LEN = 0x0000 TAG_TYPE = 0x0102 TAG_LEN = 0x0018 0x47 0x6f 0x20 0x52 0x65 0x64 0x42 0x61 0x63 0x6b 0x20 0x2d 0x20 0x65 0x73 0x68 0x73 0x68 0x65 0x73 0x68 0x6f 0x6f 0x74 Mensaje LCP PPP (0xc021) desde el host al concentrador de acceso DESTINATION_ADDR SOURCE_ADDR = 0x0010DC6F5274 = 0x00101A6F5211 (dirección concentrador acceso) ETHER_TYPE = 0x8864 VERSION = 1 TYPE = 1 CODE = 0x00 SESSION_ID = 0x1122 LENGTH = 0x???? PPP PROTOCOL= 0xc021 DATOS PPP = (...) 32 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB En el anexo número 1 del presente documento se muestra una captura completa de la fase discovery. Tecnología ADSL XDSL es el acrónimo que genéricamente identifica a un conjunto de tecnologías de enlaces digitales de gran ancho de banda sobre pares de cobre existentes, entre companias telefónicas y abonados. La tecnología XDSL puede proveer velocidades típicas que oscilan entre los 128 Kbps y 9 Mbps. Aunque experimentos han demostrado que es posible operar hasta 50 Mbps. La velocidad de trabajo estará condicionada por la distancia, características del medio conductor y técnica de codificación de la señal. Es posible operar a mayores velocidades, sobre enlaces telefónicos estándares (POTS, Plain Old Telephone Service ), utilizando frecuencias que estén arriba de los 3.400 Hz.. Debido a las características de la voz, el ancho de banda necesario para transmitirla oscila entre 300 y 3400 Hz., es por ello que el sistema telefónico construyó su red de conmutación de circuitos para operar en tal rango de frecuencias. Cuando se decidió transmitir datos digitales sobre líneas analógicas de telefonía, el ancho de banda del sistema telefónico limitó de forma significativa las transmisiones de datos. En la actualidad se ha logrado que la tasa de transferencia sea de sólo 56 Kbps, utilizando varios niveles de codificación. El ingeniero Joseph W. Lechleider, a fines de la década de los 80, propuso la utilización de la línea telefónica común, aprovechando el ancho de banda del cobre que no es usado al transmitir señales de voz. La técnica de transmisión fue llamada DSL (Digital Subscriber Line) ó línea digital de abonado. ADSL (Asymmetric Digital Subscriber Line) es la tecnología más popular de la familia XDSL. El atributo asimétrico deriva de que el ancho de banda asignado al canal de bajada (downstream) es notablemente superior al del canal de subida (upstream). Este modelo de asignación responde al patrón de uso de servicios de red Internet por parte del común de los usuarios hogareños. Velocidades del canal downstream varían entre los 256 Kbps y los 9 Mbps y el canal upstream entre los 64 Kbps y los 1,5 mbps. El siguiente gráfico muestra la asignación de frecuencias para los distintos canales que utiliza ADSL. 33 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB El gráfico anterior muestra la forma que mediante un dispositivo splitter, instalado a la entrada de la casa del abonado, se dividen los canales de telefonía y datos que llegan por el mismo cable. Con la tecnología ADSL se dispone de una conexión permanente a Internet. Por esta razón, no es necesario que el usuario establezca una conexión como sucede en el caso de los sistemas dial-up. Cuando se desea utilizar una aplicación de red, basta con invocarla ya que siempre se tiene acceso a la red. Ventajas y Desventajas de las conexiones ADSL Ventajas Para el usuario: - Conexión permanente - Acceso a alta velocidad Para el proveedor de telefonía: 34 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB - Utilización del sistema de cableado existente - No es necesario modificar las centrales de conmutación telefónica Desventajas - No sobre todas las líneas se puede ofrecer este servicio, se requiere una calidad mínima en su estado. - En el caso del usuario hogareño, el costo mensual por el servicio es sensiblemente más elevado que el sistema tradicional. - Se requiere que la línea telefónica sea utilizada sólo para transmitir voz, por lo que servicios como hilo musical, intercomunicadores, etc. no podrán compartir la misma línea. Bibliografía [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994 [2] Mamakos, L. Et al. “ A Method for Transmitting PPP Over Ethernet (PPPoE)” ,RFC 2516, February 1999 [3] Skoll, D. “ A PPPoE Implementation for Linux” , Proceedings of the 4th Annual Linux Showcase & Conference, Atlanta, October 2000. [4] Ginsburg, D. “ Implementing ADSL” , Addison Wesley, ISBN: 0201657600 [5] Kristoff, J. (compiler). “ comp.dcom.xdsl Frequently Asked Questions” . http://condor.depaul.edu/~jkristof/xdsl-faq.txt 35 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Anexo 1. Captura PPPoE 15:28:22.842 SENT PPPoE Discovery (8863) PADI sess-id 0 length 4 SourceAddr 52:54:00:dc:33:92 DestAddr ff:ff:ff:ff:ff:ff 01 01 00 00 .... 15:28:22.843 RCVD PPPoE Discovery (8863) PADO sess-id 0 length 33 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 01 01 00 00 01 02 00 03 70 63 32 01 04 00 12 52 ........pc2....R 53 50 45 52 54 00 dc 33 92 a0 68 dd b9 cf 09 c1 SPERT..3..h..... 01 . 15:28:22.843 SENT PPPoE Discovery (8863) PADR sess-id 0 length 26 SourceAddr 52:54:00:dc:33:92 DestAddr 00:80:ad:40:4e:62 01 01 00 00 01 04 00 12 52 53 50 45 52 54 00 dc ........RSPERT.. 33 92 a0 68 dd b9 cf 09 c1 01 3..h...... 15:28:22.849 RCVD PPPoE Discovery (8863) PADS sess-id 6 length 4 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 01 01 00 00 .... 15:28:22.861 RCVD PPPoE Session (8864) SESS sess-id 6 length 44 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 01 01 00 2a 03 05 c2 23 80 05 06 00 84 c9 .!...*...#...... 5b 07 02 08 02 11 04 05 dc 13 13 01 a0 ef 4b c1 [.............K. 5b c9 84 00 60 0f 75 c1 8a 0b 00 00 [...`.u..... 15:28:25.864 RCVD PPPoE Session (8864) SESS sess-id 6 length 44 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 01 02 00 2a 03 05 c2 23 80 05 06 00 84 c9 .!...*...#...... 5b 07 02 08 02 11 04 05 dc 13 13 01 a0 ef 4b c1 [.............K. 5b c9 84 00 60 0f 75 c1 8a 0b 00 00 [...`.u..... 15:28:28.863 RCVD PPPoE Session (8864) SESS sess-id 6 length 44 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 01 03 00 2a 03 05 c2 23 80 05 06 00 84 c9 .!...*...#...... 5b 07 02 08 02 11 04 05 dc 13 13 01 a0 ef 4b c1 [.............K. 5b c9 84 00 60 0f 75 c1 8a 0b 00 00 [...`.u..... 15:28:31.863 RCVD PPPoE Session (8864) SESS sess-id 6 length 44 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 01 04 00 2a 03 05 c2 23 80 05 06 00 84 c9 .!...*...#...... 5b 07 02 08 02 11 04 05 dc 13 13 01 a0 ef 4b c1 [.............K. 5b c9 84 00 60 0f 75 c1 8a 0b 00 00 [...`.u..... 15:28:34.862 RCVD PPPoE Session (8864) SESS sess-id 6 length 44 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 01 05 00 2a 03 05 c2 23 80 05 06 00 84 c9 .!...*...#...... 5b 07 02 08 02 11 04 05 dc 13 13 01 a0 ef 4b c1 [.............K. 5b c9 84 00 60 0f 75 c1 8a 0b 00 00 [...`.u..... 15:28:37.862 RCVD PPPoE Session (8864) SESS sess-id 6 length 44 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 01 06 00 2a 03 05 c2 23 80 05 06 00 84 c9 .!...*...#...... 5b 07 02 08 02 11 04 05 dc 13 13 01 a0 ef 4b c1 [.............K. 5b c9 84 00 60 0f 75 c1 8a 0b 00 00 [...`.u..... 15:28:40.861 RCVD PPPoE Session (8864) SESS sess-id 6 length 44 36 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 01 07 00 2a 03 05 c2 23 80 05 06 00 84 c9 .!...*...#...... 5b 07 02 08 02 11 04 05 dc 13 13 01 a0 ef 4b c1 [.............K. 5b c9 84 00 60 0f 75 c1 8a 0b 00 00 [...`.u..... 15:28:42.846 RCVD PPPoE Session (8864) SESS sess-id 6 length 14 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 09 00 00 0c 00 00 00 00 52 53 50 45 .!........RSPE 15:28:43.861 RCVD PPPoE Session (8864) SESS sess-id 6 length 44 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 01 08 00 2a 03 05 c2 23 80 05 06 00 84 c9 .!...*...#...... 5b 07 02 08 02 11 04 05 dc 13 13 01 a0 ef 4b c1 [.............K. 5b c9 84 00 60 0f 75 c1 8a 0b 00 00 [...`.u..... 15:28:46.860 RCVD PPPoE Session (8864) SESS sess-id 6 length 44 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 01 09 00 2a 03 05 c2 23 80 05 06 00 84 c9 .!...*...#...... 5b 07 02 08 02 11 04 05 dc 13 13 01 a0 ef 4b c1 [.............K. 5b c9 84 00 60 0f 75 c1 8a 0b 00 00 [...`.u..... 15:28:49.860 RCVD PPPoE Session (8864) SESS sess-id 6 length 44 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 01 0a 00 2a 03 05 c2 23 80 05 06 00 84 c9 .!...*...#...... 5b 07 02 08 02 11 04 05 dc 13 13 01 a0 ef 4b c1 [.............K. 5b c9 84 00 60 0f 75 c1 8a 0b 00 00 [...`.u..... 15:28:52.844 RCVD PPPoE Session (8864) SESS sess-id 6 length 14 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 c0 21 09 00 00 0c 00 00 00 00 52 53 50 45 .!........RSPE 15:28:52.864 RCVD PPPoE Discovery (8863) PADT sess-id 6 length 0 SourceAddr 00:80:ad:40:4e:62 DestAddr 52:54:00:dc:33:92 37 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 38 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB GNUTELLA: SISTEMA DISTRIBUIDO PARA ALMACENAMIENTO Y BÚSQUEDA DE INFORMACIÓN. DESCRIPCIÓN DEL MODELO Fernando Bordignon y Gabriel Tolosa Universidad Nacional de Luján División Estadística y Sistemas, Luján, Argentina {bordi,tolosoft}@unlu.edu.ar Resumen Este documento tiene por finalidad describir un nuevo protocolo a nivel de aplicación llamado Gnutella, destinado al almacenamiento y búsqueda de información en ambientes distribuidos bajo la modalidad de trabajo compañero a compañero. Dado que Gnutella nació como una aplicación de usuario final sobre la que actualmente no hay especificaciones de protocolo, se pretende formalizar su modo de operación y estructuras de datos utilizadas con vías al desarrollo de aplicaciones basadas en esta modalidad cooperativa de trabajo. Introducción Los servicios ofrecidos en Internet, en su mayoría, están implementados bajo el modelo de procesamiento denominado cliente-servidor. A diferencia de este esquema altamente centralizado, Gnutella define una red a nivel aplicación, bajo la modalidad compañero a compañero (peer to peer), donde todo nodo (en adelante gnodo) realiza al mismo tiempo funciones de cliente y servidor. Conceptualmente, es un sistema distribuido para almacenamiento y búsqueda de información. Para comprender las características y el estado de desarrollo del protocolo, resulta necesario remitirse a sus orígenes. Gnutella surgió como un proyecto independiente de los programadores Justin Frankel y Tom Pepper, fundadores de la empresa Nullsoft, destacada por ser la dueña del producto Winamp, reproductor de archivos de sonido mp3. El día 14 de marzo del año 2000, en el sitio Slashdot (http://www.slashdot.com) se publicó una versión, en fase beta, del programa Gnutella; descripto como “Una herramienta de software para compartir archivos, que puede ser aún más potente que Napster”. Inmediatamente la página fué puesta fuera de servicio, pero ya habían sido descargadas numerosas copias. Nullsoft, ante 39 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB el hecho en cuestión, se reservó el derecho de publicación (acción que no volvió a ser realizada) aduciendo que la alta demanda colapsó el sitio. Actualmente, existe una continuación al proyecto llevada a cabo por una comunidad de programadores. En base a técnicas de ingeniería inversa y análisis de protocolos han logrado decodificar y realizar varias implementaciones (clones) del protocolo Gnutella. El sitio principal de distribución es http://gnutella.wego.com. Es importante destacar dos características fundamentales que hacen a Gnutella merecedor de estudios por parte de grupos de investigación y empresas: su carácter descentralizado y su espíritu cooperativo. A partir de esto, han surgido diversos proyectos basados en el modelo compañero a compañero en redes amplias [CLARKE] [NAPSTER] [SX]. Si bien la versión actual del protocolo es la 0.4, se está trabajando en la nueva generación del mismo, estudiando la posibilidad de optimizaciones a la mecánica de ruteo (propagación de mensajes), recuperación y especificación de consultas. La división Distributed Search Services de la empresa Clip2 (http://dss.clip2.com) llevó a cabo estudios sobre la evolución y condición actual de la red Gnutella [DSS1] y el área Internet Ecologies de la Empresa Xerox realizó un análisis del tráfico en la red, caracterizando el comportamiento de los usuarios [ADAR]. Sistemas Distribuidos Emergentes para Compartir Archivos. Un Sistema Distribuido para Compartir Archivos (SDCA) permite que usuarios remotos que operan en máquinas distribuidas puedan intercambiar archivos. Si en este modelo cada máquina puede ofrecer una porción de su sistema de archivos ó solicitar por un archivo remoto (cada máquina es igual en funcionalidad), el sistema es considerado como compañero a compañero. Esto permite el desarrollo de nuevas aplicaciones y servicios basados en usuarios finales. El avance de las investigaciones en esta línea permitirá un mejor aprovechamiento de los recursos informáticos. Por ejemplo, una empresa que posea un importante número de computadores puede combinarlos para potenciar su disponibilidad de recursos (típicamente espacio de almacenamiento y tiempo de CPU) y llevar a cabo una determinada tarea. Ejemplos de modelos de SDCA son los siguientes: Freenet [CLARKE] es una red compañero a compañero diseñada para permitir la distribución de información sobre la Internet de manera eficiente. 40 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Opera de modo descentralizado y provee un importante grado de anonimato a los usuarios. En Freenet no existen equipos que brinden servicios centralizados y que su caída pueda atentar contra la estabilidad de la red. Utiliza políticas de propagación y de caché más desarrolladas que las de Gnutella, siendo más eficiente y escalable. Implementa estrategias de replicación de archivos frecuentemente accedidos, por lo que permite establecer automáticamente ruteos alternativos hacia réplicas, con el objetivo de regular el tráfico y lograr una transferencia de información más eficiente. Napster [NAPSTER] es un sistema para compartir archivos mp3 con una base de datos centralizada de archivos y usuarios. Un servidor central es el que vincula las peticiones de los clientes con sus posibles resultados. Una vez que un cliente selecciona un archivo para descargar, en base a un listado devuelto por el servidor central, el cliente inicia una conexión con la máquina remota que contiene el archivo. El servidor central de Napster nunca tiene archivos almacenados. Scour Exchange [SX] es un sistema similar a Napster, salvo por que no solamente se limita a operar con archivos mp3. Permite a usuarios consultar y recuperar información que está en unidades de almacenamiento de usuarios remotos. Características de Gnutella Bajo Gnutella se trabaja en un modelo de ambiente distribuido. Un gnodo X ofrece abiertamente los archivos que desee compartir con otros usuarios, mientras que a la vez el usuario dueño del gnodo Y puede estar recuperando, como cliente, archivos de un gnodo X. Normalmente las tareas de servidor y cliente están siempre activas en un nodo Gnutella, pero nada impide que alguna pueda no ser activada. La red gnutella se compone de numerosos gnodos distribuidos a lo largo del mundo. Su topología no indica jerarquía alguna, dado que cada gnodo es igual a los demás en funcionalidad. Debido a que uno de los atributos que caracterizan a un gnodo es su ancho de banda ofrecido para descarga de archivos, el modelo sufre ciertas variaciones. Aquellos gnodos de mayor ancho de banda son preferidos a otros, formando hubs ó anillos centrales de conexión a la red. Cada gnodo de Gnutella sólo sabe acerca de los gnodos con los que se conecta directamente Todos los otros gnodos son invisibles, a menos que ellos se anuncien contestando a un mensaje tipo ping o contestando a una consulta. Esto proporciona un alto grado de anonimato. 41 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB De forma resumida, la red Gnutella opera bajo el modelo conocido como “propagación viral”. Un cliente envía un mensaje a un gnodo, y éste lo reenvía a todos los gnodos a los cuales esté conectado. De esta forma, con solo conocer la dirección de red de un gnodo ya se puede ingresar a la misma. El ingreso a la red se realiza indicando la dirección IP y puerto TCP de cualquier gnodo que ya esté conectado. El gnodo que inicia la conexión anuncia su presencia mediante el envío de un mensaje. El gnodo al cual se conectó reenvía este mensaje a todos los gnodos a los cuales esté conectado directamente y así sucesivamente. Cada uno de estos gnodos, responde a este mensaje indicando cuántos archivos comparte y tamaño total de los mismos. Un ejemplo del alto grado de estabilidad e independencia que presenta el modelo puede verse en el siguiente ejemplo: Suponga que un gnodo-1 se conecta un gnodo-2, todo lo ofrezca gnodo-1 puede ser tomado por gnodo-2 y viceversa. Ahora gnodo-3 se conecta a gnodo-2 y éste le informa a qué gnodos está directamente conectado (los mensajes de gnodo-3 pueden llegar a gnodo-1 dado que los reenviará gnodo-2). A continuación gnodo-2 se pone en estado fuera de servicio. La red sigue funcionando normalmente dado que gnodo-3 posee direcciones alternativas de gnodos pasadas anteriormente por gnodo-2, que le permitirán conectarse a gnodos alternativos para seguir vinculado a la red. En las implementaciones del protocolo Gnutella un parámetro a definir es la cantidad de conexiones simultaneas a la red que siempre un gnodo debe tratar de mantener. Cuanto más conexiones tenga, se logrará un mayor espacio de consulta y se asegurará una alta disponibilidad de la red. Estructura de Mensajes Un mensaje gnutella se transporta sobre protocolo TCP. Su cabecera siempre consta de 23 bytes y consiste de los siguientes campos: identificador de gnodo (16 bytes), función (1 byte), TTL ó tiempo de vida restante (1 byte), Hops ó saltos (1 byte) y largo de la carga en bytes (4 bytes). El valor referenciado en el campo función indica que tipo de acciones deben realizar aquellos gnodos que reciben el mensaje. La cabecera descripta es fija para cualquier tipo de función instanciada, lo que es variable en tamaño es la segunda parte ó carga del mensaje dado que depende directamente de la función. Gnutella para operar necesita cinco funciones [DSS2] que le permitirán mantenerse en la red, consultar por recursos y descargar archivos. 42 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 1. Función Ping ó Init (código 0x00) Se utiliza a los efectos de que gnodos anuncien su presencia en la red. No lleva carga de mensaje, es decir que el campo largo de la carga se instancia en cero. Cada gnodo que reciba un mensaje Ping debe responder generando mensajes Pong (pueden ser n) donde anuncien su presencia ó de gnodos que tengan noticia. Un gnodo generará un Ping, además, para recabar información sobre gnodos vecinos. Ejemplo. mensaje Ping 27 08 3F 71 49 B2 D4 11 88 23 00 80 AD 40 4E 62 00 07 00 00 00 00 00 Mensaje Identificador de gnodo Función TTL Hops Largo de la carga : 27 08 3F 71 49 B2 D4 11 88 23 00 80 AD 40 4E 62 : 00 : 07 : 00 : 00 00 00 00 2. Función Pong ó Init_Response (código 0x01) Un gnodo envía un mensaje Pong como respuesta a un mensaje Ping. La carga de un Pong se compone de los siguientes campos: puerto (2 bytes), dirección IP (4 bytes), cantidad de archivos compartidos (4 bytes) y kbytes compartidos (4 bytes). Es interesante destacar que un gnodo al recibir datos como los descriptos puede abrir nuevas conexiones que le permitan extender su dominio de acción y, a la vez, darle una mayor estabilidad a su presencia en la red Gnutella. Un gnodo puede enviar más de un mensaje Pong como respuesta a un único Ping, dado que informa acerca de otros gnodos que tenga almacenado en su memoria cache. Ejemplo. mensaje Pong 27 08 3F 71 49 B2 D4 11 88 23 00 80 AD 40 4E 62 01 07 00 0E 00 00 00 CA 18 AA D2 62 95 03 00 00 00 00 00 00 00 Mensaje Identificador de gnodo Función TTL Hops Largo de la carga Carga Puerto Dirección IP Cantidad de archivos compartidos : 27 08 3F 71 49 B2 D4 11 88 23 00 80 AD 40 4E 62 : 01 : 07 : 00 : 0E 00 00 00 : CA 18 : AA D2 62 85 : 03 00 00 00 43 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Kbytes compartidos : 00 00 00 00 3. Función Push (código 0x40) Es utilizada por gnodos que acceden a la red atravesando un firewall, y no pueden descargar un recurso situado en un gnodo al otro lado del mismo. El gnodo que requiere el recurso enviará un mensaje Push al gnodo que lo tiene, con los siguientes campos: identificador de gnodo (16 bytes), índice (4 bytes), dirección IP (4 bytes) y puerto (2 bytes). Una vez obtenido el mensaje, el gnodo poseedor del recurso establecerá una conexión con el gnodo peticionante y le enviará, a la dirección IP y puerto informado, el archivo referenciado por el campo índice. Una respuesta a la función Push no está definida, dado que un gnodo puede enviar el recurso ó no hacer caso de la petición. Ejemplo. mensaje Push 27 40 23 00 22 08 07 00 00 3F 00 80 00 71 1A AD AA 49 00 40 12 B2 00 22 62 D4 00 11 AA 11 88 23 00 80 AD 40 4E 62 22 11 3F 71 49 B2 D4 11 88 02 CA Mensaje Identificador de gnodo : 27 08 3F 71 49 B2 D4 11 88 23 00 80 AD 40 4E 62 Función : 40 TTL : 07 Hops : 00 Largo de la carga : 1A 00 00 00 Carga Identificador de gnodo : 22 11 3F 71 49 B2 D4 11 88 23 00 80 AD 40 22 11 Indice : 02 00 00 00 Dirección IP : AA 12 62 AA Puerto : CA 22 4. Función Query (código 0x80) Se utiliza a los efectos de que un gnodo pueda consultar a otros gnodos por un recurso. La carga utilizada por esta función se compone de dos campos, a saber: velocidad mínima requerida para descarga (2 bytes) y un criterio de búsqueda de longitud variable. Un gnodo al recibir un mensaje Query y constatar que no hay coincidencias en su estructura de archivos no generará ningún mensaje de respuesta. Ejemplo. mensaje Query 28 08 3F 71 49 B2 D4 11 88 23 00 80 AD 40 4E 62 80 07 00 06 00 00 00 00 00 2A 2E 61 00 Mensaje 44 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Identificador de gnodo Función TTL Hops Largo de la carga : 28 08 3F 71 49 B2 D4 11 88 23 00 80 AD 40 4E 62 : 80 : 07 : 00 : 06 00 00 00 Velocidad mínima Criterio de búsqueda : 00 00 : 2A 2E 61 00 (*.a + carácter nulo) Carga 5. Función Query_Hit (código 0x81) Se utiliza como respuesta a un mensaje Query. Los campos que componen un Query_Hit son: cantidad de hits ó coincidencias (1 byte), puerto (2 bytes) y dirección IP de descarga (4 bytes), velocidad de operación (4 bytes), resultados (longitud variable) e identificador del gnodo que responde (16 bytes). Los resultados (que pueden ser n) se estructuran como una lista, de la siguiente forma: índice ó número de respuesta (4 bytes), tamaño del archivo (en kbytes) (4 bytes), nombre del archivo (longitud variable) y delimitador de registro (0x0000). El gnodo que responde incluye en la respuesta su identificador a los efectos de que lo pueda utilizar el gnodo peticionante, si decidiera solicitar un recurso mediante un mensaje Push. Ejemplo. mensaje Query_Hit 28 81 00 68 39 00 8D 08 07 00 69 61 00 3D 3F 00 00 2E 72 31 7D 71 57 00 61 63 34 84 49 00 00 00 68 39 D1 B2 00 00 00 69 61 11 D4 00 70 01 2E 72 85 11 03 00 00 62 63 8E 88 CA 00 00 00 68 52 23 18 00 00 00 69 54 00 AA 31 70 02 2E 00 80 D2 34 00 00 6D DC AD 62 39 00 00 00 37 40 95 61 00 00 00 66 4E 1C 72 31 70 A0 Mensaje Identificador de gnodo : 28 08 3F 71 49 B2 D4 11 88 23 00 80 AD 40 4E 62 Función : 81 TTL : 07 Hops : 00 Largo de la carga : 57 00 00 00 Carga Cantidad de hits : 03 Puerto : CA 18 Dirección IP : AA D2 62 95 Velocidad : 1C 00 00 00 Estructura resultados Identificador de gnodo : 3D 8D 3D 7D 84 D1 11 85 8E 52 54 00 DC 37 66 Estructura resultados 1er elemento Indice : 00 00 00 00 Tamaño de archivo : 70 00 00 00 Nombre de archivo : 31 34 39 61 72 63 68 69 2E 61 (149archi.a) Terminador : 00 00 2do elemento Indice : 01 00 00 00 45 62 00 63 34 00 3D Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Tamaño de archivo Nombre de archivo Terminador 3er elemento Indice Tamaño de archivo Nombre de archivo Terminador : 70 00 00 00 : 31 34 39 61 72 63 68 69 2E 62 (149archi.b) : 00 00 : 02 00 00 00 : 70 00 00 00 : 31 34 39 61 72 63 68 69 2E 6D (149archi.m) : 00 00 Función Ping (0x00) No lleva carga solamente la identificación de la función Identificador de gnodo 16 bytes Función Pong (0x01) Función 1 byte Puerto 2 bytes Cantidad de archivos compartidos 4 bytes Dirección IP 4 bytes Kbytes compartidos 4 bytes TTL 1 byte Función Query (0x80) Hops 1 byte Velocidad mínima 2 bytes Largo de la carga 4 bytes Criterio de búsqueda n bytes Función QueryHit (0x81) Cantidad de hits 1 byte Puerto 2 bytes Dirección IP 4 bytes Velocidad 4 bytes Resultados n bytes Terminador, 0x0000 2 bytes Identificador de gnodo 16 bytes Estructura Resultados Indice 4 bytes Tamaño de archivo 4 bytes Nombre de archivo n bytes Indice 4 bytes Dirección IP 4 bytes Puerto 4 bytes Push (0x40) Identificador de gnodo 16 bytes Estructuras de datos de mensajes Gnutella Reglas de Propagación El modelo compañero a compañero implementado en Gnutella requiere que los gnodos tengan la capacidad de propagar los mensajes recibidos (funciones Ping, Pong, Query, Query_Hit y Push) a través de sus conexiones establecidas. A los efectos de hacer eficiente la operación de la red (teniendo en cuenta su topología, la no jerarquía y la existencia de loops) deben implementarse en cada gnodo, una serie de reglas de propagación [DSS2], que a continuación se detallan: Regla a. Un gnodo propagará mensajes tipo Ping y Query a todos sus gnodos conectados directamente, excepto al que entregó dicho mensaje. 46 Cuadernos de Tecnología en Redes de Computadoras, nro.1 Ping Pong UNLu – DCB Gnodo Ping Ping Ping Propagación de Ping Query QueryHit Gnodo Query QueryHit QueryHit Query Gnodo Gnodo Gnodo Propagación de consultas Regla b. Los mensajes tipo Pong, Query_Hit y Push solo deben ser propagados por el mismo camino por el que viajó el mensaje inicial (Ping ó Query) asociado. Esto es posible debido a que antes de propagar un mensaje, los gnodos revisan en tablas internas por aquel que generó tal respuesta, y así obtienen la conexión por donde deben reenviarlos. Regla c. Un gnodo decrementará en 1 el valor del campo TTL de un mensaje e incrementará el valor del campo Hops en 1 antes de propagar dicho mensaje por las conexiones pertinentes. Si al decrementar el valor de TTL el resultado obtenido es cero, debe desechar el mensaje. Regla d. Si un gnodo recibe un mensaje con idéntico identificador de gnodo y mismo valor de función que uno recibido anteriormente (en un período breve de tiempo, no especificado formalmente) debería evitar propagarlo. 47 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB En un instante de tiempo puede haber miles gnodos en la red, pero para un gnodo en particular su dominio de acción estará restringido a la cantidad de conexiones establecidas y al alcance de sus mensajes (antes de que el valor del campo TTL llegue a cero y sea descartado). Debido al dinamismo, la topología y la existencia de usuarios temporales, es posible que las respuestas a una misma consulta varíen en el tiempo. Cada vez que un usuario ingresa en la red puede hacerlo a una parte diferente de la misma, según el estado actual de sus gnodos vecinos. Descarga de Archivos Una vez que un gnodo recibe un resultado (Query_Hit) a una consulta previamente realizada, puede optar por seleccionar un archivo para su descarga desde el gnodo remoto. Los archivos se recuperan directamente, sin intervención de gnodos intermedios y por lo tanto tampoco de la red Gnutella. La descarga se realiza mediante el uso del protocolo HTTP versión 1.0 [BERNERS] Un gnodo al recibir un Query_Hit obtiene los siguientes datos: dirección IP y puerto donde el gnodo que posee el recurso está en modo de apertura pasiva, índice, tamaño y nombre del archivo. A los efectos de iniciar la descarga, el gnodo que requiere el recurso abrirá una conexión TCP contra el gnodo remoto en el puerto anteriormente obtenido y, mediante la primitiva GET del protocolo HTTP, solicitará el recurso seleccionado, indicando índice y nombre de archivo. Ejemplo GET /<índice>/<nombre de archivo>/ Connection: Keep-Alive Range: bytes=0- HTTP/1.0 El gnodo remoto al recibir tal petición y validar que el recurso solicitado está disponible, transmitirá el archivo, previo envío de una cabecera estándar de HTTP con el siguiente formato: HTTP 200 OK Server: Gnutella Content-type: application/binary Content-length: <tamaño del archivo en bytes> Es importante destacar que es posible la inclusión de la funcionalidad resume en la cabecera de la primitiva de protocolo GET, a los efectos de solicitar el reenvío de 48 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB un archivo a partir de una posición determinada y hasta el final. Esto es útil en caso de descargas previas que hayan sido interrumpidas. Funcionamiento de una Red Gnutella A los efectos de describir el comportamiento de una red Gnutella, se realizó una experiencia de laboratorio de la cual se obtuvo una muestra para el análisis del protocolo (En el Anexo 1 se describe someramente cada uno de los mensajes intercambiados). Se utilizaron cuatro equipos corriendo el software Gnutella versión 0.56 (http://gnutella.wego.com), con lo cual cada uno de éstos actuó como gnodo. A continuación se describe cada uno: Dirección IP del gnodo: 170.210.98.2 (en gráfico se hace referencia al último byte) Identificador de gnodo: 4E62 (cuatro últimos bytes) Archivos compartidos: 2archi.a, 2archi.b y 2archi.z Dirección IP del gnodo: 170.210.98.3 Identificador de gnodo: XXXX Archivos compartidos: 3archi.a, 3archi.b y 3archi.i Dirección IP del gnodo: 170.210.98.150 Identificador de gnodo: 4D60 Archivos compartidos: 150archi.a, 150archi.x y 150archi.p Dirección IP del gnodo: 170.210.98.149 Identificador de gnodo: 3760 Archivos compartidos: 149archi.a, 149archi.b y 149archi.m En los gráficos, cada flecha indica el sentido del mensaje, y la identificación de la misma consta de cuatro elementos: # de mensaje, tipo de mensaje, identificación del origen y TTL. La flecha gruesa indica una conexión abierta y su sentido (desde el punto de vista de la apertura). Los tipos de mensaje están codificados de la siguiente manera Cn: Ok: Pi: Po: Qy: Rs: GNUTELLA CONNECT – Apertura de conexión a nivel aplicación GNUTELLA OK – Aceptación de apertura de conexión PING – Ping PONG – Pong QUERY – Consulta QUERY_HIT – Respuesta La secuencia de operaciones fue la siguiente: El primer lugar, se solicitó al gnodo 2 la apertura de comunicación con el gnodo 149 y luego con el gnodo 3. Una vez aceptada la apertura de conexión a nivel aplicación, el gnodo 2 envió un mensaje Ping a cada uno de ellos, obteniendo un mensaje Pong como respuesta. 49 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 2 150 4E62 4D60 1- Cn 8-Po/4E62/7 2-Ok 7- Pi/4E62/7 5- Cn 6-Ok 3- Pi/4E62/7 4-Po/4E62/7 3 149 XXXX 3766 Gráfico 1 A continuación, se solicitó al gnodo 149 la ejecución de un comando de aplicación de actualización de la información de conexiones Gnutella y recursos compartidos, lo que generó el envío de un mensaje Ping por todas sus conexiones abiertas. Como solo tenía conexión con el gnodo 2, le envió el Ping a éste, quien primero lo contestó (con su mensaje Pong) y luego lo propagó por todas sus conexiones abiertas, excepto por donde lo recibió (en este caso con el gnodo 3), decrementando el TTL del mensaje. Gnodo 3 contestó al gnodo 2 al Ping y éste lo redireccionó al gnodo 149, que fue quien originó el requerimiento. 50 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 2 150 4E62 4D60 12-Po/3766/6 10-Po/3766/7 9-Pi/3766/7 11-Pi/3766/6 13-Po/3766/5 3 149 XXXX 3766 Gráfico 2 Al recibir información de la existencia del gnodo 3, el gnodo 149 abrió una conexión con éste y le envió un mensaje Ping . 51 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 2 150 4E62 4D60 14-Cn 3 15-Ok XXXX 149 3766 16-Pi/3766/7 Gráfico 3 Luego, se solicitó al gnodo 150 la apertura de una conexión con el gnodo 149. Finalizada la misma, el gnodo 150 envió un mensaje Ping al gnodo 149, el cual lo contestó (Pong) y luego lo propagó por todas sus conexiones abiertas (con los gnodos 2 y 3, quienes a su vez hicieron lo propio). Las respuestas viajaron por los mismos caminos por donde circuló el mensaje Ping y, finalmente, llegaron al gnodo 150 (con el TTL del mensaje decrementado según los gnodos que se atravesaron en el camino). 52 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 2 150 4E62 4D60 26-Po/4D60/5 23-Pi/4D60/5 25-Po/4D60/6 18-Ok 17-Cn 20-Pi/4D60/6 27-Po/4D60/5 19-Pi/4D60/7 22-Po/4D60/7 3 21-Pi/4D60/6 24-Po/4D60/6 XXXX 149 3766 Gráfico 4 Al recibir información de la existencia del gnodo 3, el gnodo 150 abrió una conexión con éste y le envía un mensaje Ping, el cual fue propagado según el mismo comportamiento anterior. 53 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 2 150 4E62 4D60 29-Ok 37-Pi/4D60/6 28-Cn 31-Pi/4D60/7 32-Pi/4D60/7 30-Po/4D60/5 33-Pi/4D60/7 34-Pi/4D60/6 39-Po/4D60/7 36-Po/4D60/7 3 35-Pi/4D60/6 149 38-Pi/4D60/6 XXXX 3766 Gráfico 5 54 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 2 150 4E62 4D60 41-Pi/4D60/5 40-Po/4D60/6 42-Po/4D60/5 3 149 XXXX 3766 Gráfico 6 En este momento, la red Gnutella constaba de cuatro gnodos, sobre la cual se ejecutaron las siguientes consultas: En el gnodo 2 se solicitó la consulta por el patrón de caracteres “*.a”. Este gnodo envió la consulta por todas sus conexiones abiertas (en este caso con los gnodos 149 y 3). Los gnodos 149 y 3 – a su vez – propagaron la consulta a través de todas sus conexiones (excepto por donde entró). Aquellos gnodos que poseían archivos cuyo nombre correspondía al patrón de búsqueda (en este caso los gnodos 2, 149 y 150) respondieron a la consulta enviando un mensaje por el mismo camino de la misma. Nótese que el comportamiento de los gnodos en cuanto a la propagación de una consulta es similar a la de un mensaje Ping, ocurriendo lo mismo con las respuestas (respecto de los mensajes Pong). 55 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 2 150 4E62 4D60 53-Rs/4E62/5 45-Rs/4E62/7 44-Qy/4E62/7 52-Qy/4E62/5 51-Rs/4E62/6 48-Rs/4E62/7 50-Qy/4E62/6 3 47-Qy/4E62/6 43-Qy/4E62/7 46-Qy/4E62/6 149 49-Qy/4E62/6 XXXX 3766 Gráfico 7 Finalmente, en el gnodo 2, se solicitó la consulta por el patrón de caracteres “i.a”. Este gnodo envió la consulta de la misma forma que la anterior. Los gnodos 149 y 3 propagaron la misma. Ninguno de los gnodos poseía archivos cuyo nombre correspondía al patrón de búsqueda, por lo tanto no la respondieron. 56 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 2 150 4E62 4D60 55-Qy/4E62/7 60-Qy/4E62/5 57-Qy/4E62/6 59-Qy/4E62/6 54-Qy/4E62/7 3 56-Qy/4E62/6 149 58-Qy/4E62/6 XXXX 3766 Gráfico 8 Conclusiones El uso masivo del protocolo en implementaciones sobre diferentes plataformas ha demostrado que Gnutella es un punto de inicio válido para el desarrollo de servicios distribuidos basados en la filosofía compañero a compañero. Debido a su génesis y corta existencia, Gnutella es aún un protocolo inmaduro, sometido a estudios para evaluar mejoras en eficiencia y funcionalidad (para implementar en versiones posteriores). Como característica interesante, presenta la definición de una red a nivel aplicación, orientada al cooperativismo, que brinda elementos para favorecer la heterogeneidad, la estabilidad, la redundancia y la tolerancia a fallas. El modelo de propagación puede servir para generar aplicaciones distribuidas que no solamente se limiten a tareas de compartir archivos. Por ejemplo, se podría utilizar este modelo, con modificaciones menores, con el objetivo de lograr una red de procesamiento distribuido basada en el cooperativismo. 57 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Bibliografía [ADAR] Adar, E. y Huberman, B. Free Riding on Gnutella. Technical Report. Xerox PARC, Agosto 2000. [CLARKE] Clarke, I.; Sandberg, O.; Wiley, B. y Hong, T. Freenet: A Distributed Anonymous Information Storage and Retrieval System. In Proc. of the ICSI Workshop on Design Issues in Anonymity and Unobservability, Berkeley, CA, 2000. [DSS1] Gnutella: To the Bandwidth Barrier and Beyond. Distributed Search Services. http://dss.clip2.com. Noviembre 2000. [DSS2] The Gnutella Protocol Specification v0.4. Distributed Search Services. http://dss.clip2.com. Septiembre 2000. [NAPSTER] Napster, sitio oficial . http://www.napster.com [ORAM] Oram, A., "Gnutella and Freenet Represent True Technological Innovation," The O'Reilly Network, Mayo 2000. http://www.oreillynet.com/lpt/a/208 [BERNERS] Berners-Lee, T.; Fielding, R. y Frystyk, H. RFC 1945. Hypertext Transfer Protocol – HTTP/1.0. Mayo 1996. [SX] Scour Exchange, sitio oficial http://www.scour.com 58 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Anexo 1. Descripción de los mensajes intercambiados Referencias: Cn: Ok: Pi: Po: Qy: Rs: GNUTELLA CONNECT GNUTELLA OK PING PONG QUERY QUERY_HIT # 1 2 3 4 5 6 7 8 9 Origen 2 149 2 149 2 3 2 3 149 Destino Función 149 Cn 2 Ok 149 Pi 2 Po 3 Cn 2 Ok 3 Pi 2 Po 2 Pi TTL 10 11 2 2 149 3 Po Pi 7 6 12 13 3 2 2 149 Po Po 6 5 14 15 16 17 18 19 20 21 22 23 24 149 3 149 150 149 150 149 149 149 3 3 3 149 3 149 150 149 2 3 150 2 149 Cn Ok Pi Cn Ok Pi Pi Pi Po Pi Po 7 7 7 7 7 7 6 6 7 5 6 25 2 149 Po 6 26 27 28 29 30 31 32 33 34 35 2 149 150 3 149 150 150 150 3 3 3 150 3 150 150 3 149 3 2 149 Po Po Cn Ok Po Pi Pi Pi Pi Pi 5 5 7 7 5 7 7 7 6 6 7 7 7 7 7 7 7 7 7 Descripción Gnodo 2 abre conexión con Gnodo 149 Gnodo 149 acepta la conexión Gnodo 2 envía un Ping a 149 Gnodo 149 responde con un Pong Gnodo 2 abre conexión con Gnodo 3 Gnodo 3 acepta la conexión Gnodo 2 envía un Ping a 3 Gnodo 3 responde con un Pong Gnodo 149 envía un Ping (debido a un UPDATE de aplicación) Gnodo 2 responde con un Pong Gnodo 2 propara el Ping a Gnodo 3 (y decrementa el TTL) Gnodo 3 responde al Ping anterior Gnodo 2 envía el Pong recibido a 149 (que originó el pedido) Gnodo 149 abre conexión con Gnodo 3 Gnodo 3 acepta la conexión Gnodo 149 envía un Ping a 3 Gnodo 150 abre conexión con Gnodo 149 Gnodo 149 acepta la conexión Gnodo 149 envía un Ping a 3 Gnodo 149 reenvía el Ping a 2 Gnodo 149 reenvía el Ping a 3 Gnodo 149 responde al Ping de 150 Gnodo 3 reenvía el Ping a 2 Gnodo 3 responde al Ping reenviado por 149 Gnodo 2 responde al Ping reenviado por 149 Gnodo 2 responde al Ping reenviado por 3 Gnodo 149 reenvía el Pong a 150 Gnodo 150 abre conexión con Gnodo 3 Gnodo 3 acepta la conexión Gnodo 149 reenvía el Pong a 150 Gnodo 150 envía un Ping a 3 Gnodo 150 envía un Ping a 149 Gnodo 150 envía un Ping a 3 Gnodo 3 reenvía el Ping a 2 Gnodo 3 reenvía el Ping a 149 59 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 36 37 38 3 149 149 150 2 3 Po Pi Po 39 149 150 Po 40 2 149 Po 41 42 43 44 45 2 149 2 2 149 3 150 149 3 2 Po Po Qy Qy Rs 46 47 149 149 3 150 Qy Qy 48 3 2 Rs 49 50 51 3 3 150 149 150 149 Qy Qy Rs 52 53 150 149 3 2 Qy Rs 54 55 56 57 2 2 149 149 149 3 3 150 Qy Qy Qy Qy 58 59 60 3 3 150 149 150 3 Qy Qy Qy 7 Gnodo 3 responde al Ping de 150 6 Gnodo 149 reenvía el Ping a 2 6 Gnodo 149 responde al Ping reenviado por 3 7 Gnodo 149 responde al Ping enviado por 150 6 Gnodo 2 responde al Ping reenviado por 149 6 Gnodo 2 responde al Ping reenviado por 3 5 Gnodo 149 reenvía el Pong a 150 7 Gnodo 2 envía una consulta a Gnodo 149 7 Gnodo 2 envía una consulta a Gnodo 3 6 Gnodo 149 responde a la consulta de Gnodo 2 6 Gnodo 149 reenvía la consulta a Gnodo 3 6 Gnodo 149 reenvía la consulta a Gnodo 150 7 Gnodo 3 responde a la consulta de Gnodo 2 6 Gnodo 3 reenvía la consulta a Gnodo 149 6 Gnodo 3 reenvía la consulta a Gnodo 150 6 Gnodo 150 responde a la consulta reenviada por Gnodo 149 5 Gnodo 150 reenvía la consulta a Gnodo 3 5 Gnodo 149 reenvía la respuesta recibida a Gnodo 2 7 Gnodo 2 envía una consulta a Gnodo 149 7 Gnodo 2 envía una consulta a Gnodo 3 6 Gnodo 149 reenvía la consulta a Gnodo 3 6 Gnodo 149 reenvía la consulta a Gnodo 150 6 Gnodo 3 reenvía la consulta a Gnodo 149 6 Gnodo 3 reenvía la consulta a Gnodo 150 5 Gnodo 150 reenvía la consulta a Gnodo 3 60 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB CARACTERIZACIÓN DEL PROTOCOLO SOCKS, VERSIÓN 5 Gabriel Tolosa y Fernando Bordignon Universidad Nacional de Luján División Estadística y Sistemas, Luján, Argentina { tolosoft, bordi }@unlu.edu.ar Resumen SOCKS es un protocolo de seguridad que opera bajo la modalidad de servidor proxy genérico en redes basadas en el juego de protocolos TCP/IP. Para su implementación se requiere un servidor SOCKS que se sitúa en la capa de aplicación, y un cliente que opera entre la capa de aplicación y la de transporte. Este documento tiene por finalidad describir el protocolo de seguridad SOCKS en su versión 5. Firewalls Un firewall es un sistema que permite establecer una política de control de acceso entre dos redes, donde todo el tráfico desde el exterior al interior, y viceversa, debe necesariamente pasar por el sistema. El tráfico autorizado, que está definido en la política de seguridad de la organización, solamente pasará de una red a otra. INTERNET FIREWALL RED INTERNA Según un ejemplo presentado por Tanenbaum [1], un firewall funciona análogamente al viejo sistema de seguridad medieval consistente de un foso profundo alrededor de un castillo. Esto obligaba a cualquiera que entrara o saliera del castillo a pasar por un solo puente levadizo, donde podría ser inspeccionado. En las redes, el castillo representa la red interna de la compania (bien a proteger) 61 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB mientras que el puente levadizo se corresponde al enlace con otras redes donde se implementan las políticas de control. Funcionalmente un firewall actúa como elemento separador de redes (determina claramente la frontera entre la red de una organización y el mundo). Estructuralmente se lo puede ver como un conjunto de componentes (ruteadores, computadoras y software apropiado), donde las configuraciones posibles variarán dependiendo de las políticas de seguridad, del presupuesto y de las características de la red a proteger. Firewalls a nivel de red Este tipo de firewalls se basan en el filtrado de paquetes. Esta técnica consiste en el análisis de los valores de ciertos campos de cabecera de protocolo, a los efectos de confrontar con reglas predeterminadas que dictan la validez o no de dicho paquete [2]. Los filtros de paquetes generalmente son manejados por tablas configuradas por el administrador de la red. En dichas tablas se listan los orígenes y destinos aceptables, los orígenes y destinos bloqueados (entiéndase cualquier combinación de dirección y servicio), protocolos permitidos o denegados, y las reglas predeterminadas a tomar con paquetes que llegan, de, o salen a otras máquinas. En definitiva estas tablas y reglas son la implementación directa de las políticas de seguridad de toda organización. A continuación se muestra un ejemplo de una posible tabla de reglas de filtrado: Regla Dirección origen A Cualquiera B Externa C w.x.y.z D Cualquiera Dirección Destino Cualquiera w.x.y.z Cualquiera Cualquiera Protocolo Cualquiera TCP TCP ICMP Puerto Fuente Cualquiera >1023 80 Puerto Destino Cualquiera 80 >1023 Acción Prohibir Permitir Permitir Permitir La regla A define una postura de negación preestablecida, donde lo que no está permitido expresamente (por las reglas siguientes) se considera prohibido. La regla B deja pasar cualquier solicitud de servicio proveniente del exterior, dirigida al host cuya dirección es w.x.y.z en el puerto 80 (típicamente HTTP). La regla C habilita que las respuestas del servidor HTTP puedan llegar a destino (complementa a la regla B). La regla D permite mensajes ICMP (de cualquier tipo) circular en ambos sentidos. Firewalls a nivel de aplicación Las pasarelas de aplicación operan sobre el contenido de cada mensaje entrante ó saliente. Para cada uno, la pasarela decide (en base a reglas predeterminadas) si debe 62 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB transmitirlo o descartarlo, basándose en datos propios del protocolo de aplicación [2]. Estos funcionan como sistemas intermediarios entre un cliente de la organización y un servidor externo a la misma. El cliente entabla una comunicación con el sistema intermedio, éste evalúa la solicitud y, de ser pertinente, establece una segunda comunicación con el servidor externo. De ahí en más el equipo intermediario transmite las solicitudes del cliente al servidor y las respuestas de éste al cliente. Funcionalidades extras pueden agregarse a este modelo, como ser: comunicaciones encriptadas entre el cliente y el equipo intermediario, autenticación de clientes, permisos de acceso basados en horarios, lugares, contenidos, etc. Otro aspecto importante de este tipo servicios es la posibilidad de esconder totalmente una red, dado que para el exterior solamente existe el equipo que actúa como intermediario de las comunicaciones, por lo cual la red interna podría operar con un esquema de direcciones privadas. Este tipo de servicios son efectivos solo cuando se emplean junto con un mecanismo que restringe las comunicaciones directas entre equipos internos y externos. SOCKS versión 5 SOCKS [3] provee un mecanismo de proxy, creando un circuito entre el cliente y el servidor de aplicación, sin interpretar el protocolo superior. Este sistema es una categoría de firewall, dado que permite implementar medidas de protección de redes. El protocolo está descripto en el documento RFC 1928. Arquitectura SOCKS Servidor de Aplicación Conexión TCP Borde de la red Servidor SOCKS Conexión SOCKS Cliente de Aplicación/SOCKS TCP SOCKS brinda un marco en aplicaciones cliente/servidor para utilizar servicios de una red de manera conveniente y segura en dominios de protocolos de transporte 63 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB UDP y TCP. Habilita o permite que hosts de un lado del servidor SOCKS tengan acceso a hosts del otro lado del servidor, sin requerir alcance a nivel IP en forma directa. Esto trabaja redireccionando pedidos de conexión de hosts de uno de los lados a hosts situados del otro lado del servidor SOCKS, el cual autentifica y autoriza los requerimientos, establece una conexión proxy y pasa los datos en ambos sentidos. Su antecesor SOCKS versión 4 provee conexiones inseguras para aplicaciones cliente servidor basadas en TCP (telnet, FTP, HTTP, etc.). SOCKS versión 5 incorpora fuertes esquemas de autenticación, incluye soporte para protocolo UDP y extiende el esquema de direccionamiento para abarcar nombres de dominio y direcciones IP versión 6. Cliente de Aplicación Servidor SOCKS Envio de métodos de autenticación Chequeo de políticas Verif. método autenticación Selección y envío de método elegido Proceso de autenticación Proceso de autenticación Requerimiento de reenvio Procesamiento de solicitud SOCKS V4 Establecimiento de conexión Conexión aceptada Chequeo de estado del requerimiento Envío de estado Protocolo de aplicación Reenvío de datos 64 Servidor de Aplicación SOCKS V5 Protocolo de aplicación Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB El esquema anterior muestra el modelo de control de flujo en SOCKS, quedando claramente detallada la funcionalidad agregada por la versión 5 sobre la 4. Operación bajo protocolo TCP Cuando un cliente TCP quiere establecer una conexión con una aplicación que solamente es alcanzable a través del firewall, debe abrir una conexión con el servidor SOCKS (típicamente utiliza el puerto bien conocido 1080). Si el pedido de conexión es exitoso se negocia un método de autenticación a utilizar. A continuación, se autentifica con el método seleccionado y en caso de validarse el cliente, éste envía una solicitud de relay (mensaje request). Por otro lado el servidor SOCKS evalúa la petición y procede o no. A partir de este punto el servidor SOCKS se conecta al servidor de aplicación en representación del cliente, procediendo a mantener dos conexiones por medio de la técnica de relevamiento, interceptando cada segmento de datos provenientes del cliente y del servidor, y reenviándolos a la otra conexión. (Para el servidor de aplicación el cliente es el servidor SOCKS, lo que demuestra el grado de enmascaramiento alcanzado con esta técnica). Etapas de una conexión SOCKS Etapa de autenticación a) Solicitud de método: El cliente envía un mensaje anunciando su versión de protocolo y una lista de métodos de autenticación soportados. Estructura del mensaje Versión SOCKS (1 byte) Nro. de métodos (1 byte) Códigos de métodos (de 1 a 255 bytes) Códigos de métodos 00 Sin autenticación requerida 01 Autenticación GSSAPI (RFC 1961) 02 Username/Password (RFC 1929) 03-7F Asignados a IANA 80-FE Reservados FF Ningún método aceptado. b) Respuesta a solicitud: El servidor selecciona uno de los métodos ofrecidos y envía un mensaje informándole. Ejemplo 65 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB 05 01 00 Utilizando la versión 5 de SOCKS (05), el cliente informa al servidor que tiene un solo método (01) de autenticación, y corresponde a “sin autenticación requerida” (00). Estructura del mensaje Versión SOCKS (1 byte) Código de método (1 byte) El código de método seleccionado se corresponde a la tabla de solicitud de método Ejemplo 05 00 El servidor utilizando la versión 5 SOCKS (05) informa al cliente el método elegido (00). A partir de aquí se requiere una subnegociación de autenticación específica del método anteriormente seleccionado. Finalizada la misma de manera exitosa el cliente procede con la etapa siguiente. Etapa de solicitud (request/reply) a) Solicitud (request): El cliente envía un mensaje solicitando comunicación con un servidor de aplicación (Si el método seleccionado en la etapa anterior incluye encapsulado por cuestiones de seguridad, esta solicitud será encapsulada según especificaciones). Estructura del mensaje Versión SOCKS (1 byte) Comando Reservado (1 byte) (1 byte) Tipo de Dirección (1 byte) Dirección Destino (variable) Puerto Destino (2 bytes) Códigos de comandos 01 connect 02 bind 03 UDP associate Código de tipo de dirección 01 IPV4 02 Nombre de dominio (mnemónico) 03 IPV6 66 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Ejemplo 05 01 00 01 81 32 04 02 00 50 Utilizando la versión de protocolo 5 (05) se envía un mensaje de connect (01) (el siguiente campo con valor 00 está reservado), con un formato de direccionamiento IPV4 (01) al host 129.50.4.2 (81 32 04 02) al puerto 80 (00 50) b)Respuesta (reply): Luego que el servidor SOCKS intenta establecer una conexión con el servidor de aplicación, indicado por el cliente en el mensaje de solicitud, y basándose en su éxito o fracaso, retorna al cliente un mensaje de respuesta. Estructura del mensaje Versión Respuesta Reservado Tipo de Dirección SOCKS (1 byte) (1 byte) Dirección de salida (1 byte) (1 byte) del servidor SOCKS (variable) Puerto salida del servidor SOCKS (2 bytes) Códigos de respuesta 00 Éxito 01 Falla general del servidor SOCKS 02 Conexión no permitida por reglas 03 Red no alcanzable 04 Host no alcanzable 05 Conexión rechazada 06 TTL expirado 07 Comando no soportado 08 Tipo de dirección no soportada 09-FF No asignado Ejemplo 05 00 00 01 81 32 04 01 04 0E El servidor SOCKS, operando con versión 5 (05), informa del éxito (00) de la solicitud de apertura de conexión con el servidor de aplicación. Luego sigue el campo reservado (00). A continuación informa que se ha conectado a la dirección tipo IPV4 (01) 129.50.4.1 (81 32 04 01), puerto 1038 (04 0E). Nota: A partir de este momento el servidor SOCKS tomará los segmentos provenientes del cliente ó del servidor de aplicación y los reenviará según corresponda, sin agregar información adicional. No existe etapa de cierre a nivel de protocolo SOCKS. La finalización de las conexiones SOCKS ocurre a demanda de las entidades intervinientes en la aplicación. 67 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB El comando bind en un mensaje de solicitud de servicio, se usa para protocolos que requieren que el cliente acepte conexiones entrantes desde el servidor de aplicación. FTP es un ejemplo, dado que de forma normal, el cliente debe abrir una conexión en modo pasivo cuando requiere una transferencia de datos. Si la interacción entre cliente y servidor de aplicación requiere que el cliente acepte conexiones entrantes, se lo indicará al servidor SOCKS a través una conexión secundaria mediante un comando bind (en dicho mensaje informa la dirección y número de puerto donde espera en modo pasivo). El servidor SOCKS deberá habilitar una conexión en modo pasivo para atender al servidor de aplicación. En caso de éxito informará al cliente la dirección y puerto que habilitó para dicha tarea (si fracasó también informará). El cliente, a través de la conexión primaria, indicará al servidor de aplicación la dirección y número de puerto donde aceptará la conexión entrante (que en realidad corresponde al servidor SOCKS). Cuando el servidor SOCKS detecte que el servidor de aplicación se conectó, enviará al cliente de aplicación un segundo mensaje (por la conexión secundaria) informando esta situación. A partir de este momento por la técnica de relevamiento (relay) el servidor SOCKS manejará el intercambio de datos de la conexión entrante. Nota: Cuando un mensaje de respuesta indica una condición de error (código distinto de 00), el servidor SOCKS debe terminar la conexión luego de enviar dicha respuesta. Servicios de retransmisión basados en UDP Un cliente basado en UDP envía sus datagramas de transporte al servidor SOCKS. El cliente UDP utiliza una conexión TCP con el servidor SOCKS, que es iniciada cuando una aplicación realiza la primera llamada a la función sendto(). Por dicha conexión se enviará un comando solicitando servicio de retransmisión e indicando dirección de respuestas. El servidor SOCKS informará al cliente donde debe dirigirle dichos mensajes. A medida que lleguen serán retransmitidos al servidor de aplicación. En caso de que el servidor SOCKS reciba respuestas del servidor de aplicación, las retransmitirá al cliente al puerto indicado en el mensaje de solicitud de servicio. Una sesión de requerimiento de transporte UDP puede ejemplificarse de la siguiente forma: Un cliente C necesita enviar un mensaje UDP a un servidor de aplicación SA, a través de un servidor SOCKS S. 68 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB A establece una conexión TCP (puerto del servidor SOCKS) con S, enviando un mensaje tipo UDP_ASSOCIATE. Como se ve en el siguiente ejemplo 05 03 00 01 00 00 00 00 04 63 Utilizando la versión 5 del protocolo SOCKS (05), C solicita un servicio de transporte UDP (03, UDP_ASSOCIATE). El siguiente campo (00) es reservado. A continuación informa que la dirección de respuesta (para UDP replies) en C es tipo IPV4 (01), no especificada (00 00 00 00), puerto 1123 (04 63). El servidor S contesta al mensaje anterior de la siguiente forma: 05 00 00 01 81 32 03 01 04 02 Utilizando la versión 5 del protocolo SOCKS (05), S informa que la petición ha sido exitosa (00). El siguiente campo (00) es reservado. La dirección a la cual C debe remitir su mensaje UDP es tipo IPV4 (01), IP 129.50.3.1 (81 32 03 01), puerto 1026 (04 02). C envía un mensaje UDP a S al puerto 1026 con la siguiente conformación: 00 00 00 01 81 32 04 02 00 25 Datos_Aplicación Los primeros dos bytes (00 00) están reservados. El byte siguiente indica número de fragmento (00). La dirección a la cual S debe retransmitir el mensaje UDP (Datos_Aplicación) es tipo IPV4 (01), IP 129.50.4.2 (81 32 04 02), puerto 37 (00 25). S retransmite en un nuevo mensaje UDP los datos de aplicación y esperará por respuesta (si la hubiera) en un puerto UDP que habilitará para tal fin. En caso de que la hubiera retransmitirá el mensaje UDP a C, según la información proporcionada con el comando UDP_ASSOCIATE. Ejemplo de operación SOCKS versión 5 eth0 129.50.3.1 CLIENTE HTTP pico 129.50.3.2 eth1 129.50.4.1 SERVIDOR SOCKS router34 - multihomed host 69 SERVIDOR HTTP y DNS bariloche 129.50.4.2 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB El objetivo del ejemplo (ejecutado en la red del diagrama anterior) es brindar un acceso seguro a otras redes por parte de equipos pertenecientes a la red 129.50.3.0. Para lo cual al equipo denominado router34 se le deshabilitó la función del IPForwarding, convirtiéndolo en un multihomed host. Además, se instaló el software con capacidad de servidor SOCKS versión 5 desarrollado por la firma NEC [4]. La instalación se realizó siguiendo las instrucciones adjuntas al software, donde básicamente se configuró la distribución fuente, se compiló, se distribuyó en los directorios predeterminados y finalmente se configuró el software de acuerdo a las necesidades propias. La configuración del servidor se realiza sobre el archivo /etc/socks5.conf, en el presente caso se utilizó la siguiente: auth - - # Permite cualquier tipo de autenticación # inclusive ninguna. permit - - 129.50.3. - - # Permite que todos los hosts de la red # 129.50.3 puedan tener servicio de proxy, # negando acceso a servicios proxy a cual# quier hosts de otra red set SOCKS5_V4SUPPORT # Brinda servicios de SOCKS versión 4 a # clientes que lo soliciten. El servidor SOCKS se ejecutó bajo línea de comando con la siguiente orden: <dir.de instalación>#./socks5 –b 1080 –d 2 –s Donde –b 1080 le indica que atienda en el puerto 1080 y –d 2 determina el nivel de información provista por el módulo de debugger en archivos de logs y –s indica que las líneas de debug deben ser redirigidas a la salida estándar de errores (monitor en nuestro caso). En el equipo pico, operando sobre sistema operativo Microsoft Windows 95, se instaló el software cliente HTTP denominado Navigator, de la empresa Netscape. Dado que la versión instalada (4.61) solo soporta el protocolo SOCKS versión 4 fue necesario incluir un agente residente que capture las peticiones del Navigator y las traduzca a peticiones SOCKS 5. Este software es provisto por la empresa NEC [4] y se denomina SocksCaps. Luego de instalado, se lo configuró indicando los siguientes parámetros: dirección IP y número de puerto del servidor SOCKS, indicación de quien resuelve la conversión de nombres (si es local o a través del servidor SOCKS), si se lleva un registro de logs sobre peticiones realizadas, aplicaciones sobre las cuales va a actuar. En definitiva, bajo Windows, SocksCaps a través de librerías dinámicas (DLL) provee un servicio transparente (para la 70 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB aplicación cliente) de acceso a servidores de aplicación a través de un servidor SOCKS. Esta tarea se denomina Socksification. Análisis del intercambio de mensajes de los distintos protocolos En base a la configuración enunciada en la sección anterior se procedió a realizar una captura de protocolo HTTP que incluyó una página HTML y un objeto gráfico asociado. para lo cual, en el equipo router34 se corrió el software de captura tcpdump con la opción de almacenamiento en archivo. En el equipo pico, cliente Microsoft Windows 95, ejecutando el software Navigator en modo Socksfied se procedió a tipear la siguiente dirección URL http://www.prueba.edu.ar (IP 129.50.4.2). Como resultado se obtuvo la página requerida con su gráfico asociado. Analizada la captura obtenida, a continuación se realiza un somero relato de los principales hechos sucedidos: En primer lugar el cliente de aplicación (CA) solicita una apertura de conexión TCP con el servidor SOCKS (SS), e intercambian mensajes de protocolo SOCKS a los efectos de acordar el método de autenticación. Luego CA envía una solicitud de servicio contra un servidor de aplicación (SA). SS consulta al servidor DNS acerca de la dirección IP de SA, para luego establecer una conexión TCP con SA y poder avisar acerca del éxito a CA. Este envía a SS un pedido de servicio de aplicación (GET /), el cual es reenviado por SS a SA. A partir de aquí en más SS funciona como agente de reenvío en ambos sentidos. Debido a que la página HTML recuperada contenía una referencia a un objeto externo, CA debe abrir una segunda conexión con SS para recuperarlo (siguiendo el mecanismo descripto anteriormente). Finalizadas ambas transferencias, se procedió a tipear desde CA una URL que apuntaba a un recurso inexistente en SA. Cabe notar aquí que esta nueva solicitud se canalizó por la primer conexión entre CA y SS, dado que a nivel protocolo HTTP mediante la directiva keep-alive el canal quedo abierto. Finalmente, por iniciativa del SA se cerraron ambas conexiones con SS, y por ende este con CA. El siguiente diagrama de tiempos muestra los mensajes intercambiados durante el procesamiento de la primer solicitud, donde se ve claramente la interacción entre las tres partes del modelo SOCKS. 71 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB SS 129.50.3.1 1056 a 1080 - SYN (s927) mss1460-w8192 129.50.4.1 129.50.3.2 CA 129.50.4.2 SA 1080 a 1056 - SYN ACK (s6218-a9272)-mss1460-w32120 1056 a 1080 - ACK (s:1)-w8760 1056 a 1080 - P ACK (s:1:4-a1)-w8760 1080 a 1056 - ACK (a4)-w32120 1080 a 1056 - P ACK (s1:3-a4)-w32120 1056 a 1080 - P ACK (s4:30-a3)-w8758 DNS 1027 a 53 - query DNS 53 a 1027 - response 1080 a 1056 - ACK (a30)-w32120 1045 a 80 - SYN (s820) - mss1460-w32120 80 a 1045- SYN ACK - (s4837:a821) mss1460-w32120 1045 a 80 - ACK (a1) - w321220 1080 a 1056 - P ACK (s3:13-a30)-w32120 1056 a 1080 - P ACK (s30:298-a13)-w8748 1045 a 80 - P ACK (s1:269-a1) - w32120 80 a 1045- ACK - (a269) w32120 1080 a 1056 - ACK (a298)-w32120 80 a 1045- P ACK - (s1:1449-a269) w32120 80 a 1045- P ACK - (s1449:1898-a269) w32120 1045 a 80 - P ACK (a1449) - w31856 1080 a 1056 - P ACK (s13:1473-a298)-w32120 1045 a 80 - ACK (a1898) - w31856 1056 a 1080 - ACK -(a1473)-w1898 1080 a 1056 - P ACK (s1473:1910-a298)-w32120 1056 a 1080 - ACK -(a1910)-w8323 La captura continua con la recuperación de un segundo objeto, por una nueva conexión, y a continuación se muestra la secuencia de cierre de la primer conexión 80 a 1045- FIN ACK - (s2314-a542) w32120 1045 a 80 - ACK (a2315) - w31856 1045 a 80 - FIN ACK (s542-a2315) - w31856 1080 a 1056 - FIN ACK (s2326-a571)-w32120 80 a 1045- ACK - (a543) w32120 1056 a 1080 - ACK -(a2327)-w7907 1056 a 1080 - FIN ACK -(s571-a2327)-w7907 1080 a 1056 - ACK (a572)-w32120 72 Cuadernos de Tecnología en Redes de Computadoras, nro.1 UNLu – DCB Bibliografía [1] Tanenbaum, A. “Redes de Computadoras”. 3ra edición, Prentice Hall. (1997). [2] Chapman, D. y Zwicky, E. “Construya Firewalls para Internet”. 1ra edición, Mc Graw Hill & O´Reilly. (1997). [3] “RFC 1928. SOCKS Versión 5”, (1996) [4] Sitio: Empresa NEC, producto SOCKS, http://www. socks.nec.com 73
