Cuadernos de Tecnología en Redes de Computadoras

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
bordi@unlu.edu.ar
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 bordi@unlu.edu.ar.
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