ESTUDIO Y PRUEBAS PARA EL ESTABLECIMIENTO DE UN FLUJO DE DATOS UDP BIDIRECCIONAL EN UN ENTORNO NAT SIN CONFIGURACIÓN DE MAPEOS ESTÁTICOS EN EL ROUTER . PARTE II

Fernando Esteban de Lama

1- Introducción

El presente documento pretende definir la secuencia de acciones necesarias para el establecimiento de un flujo de datos udp, entre dos computadores conectados a la red Internet a través de un router NAT. Los resultados de este estudio podrán ser de gran ayuda para el desarrollo de aplicaciones streaming peer to peer , que usen UDP como protocolo de la capa de transporte. El escenario teórico práctico en el que realizaremos este estudio estará constituido por dos redes LAN privadas , conectadas a Internet a través de routers NAT.

-LAN 1 ---> Se conecta a Internet mediante el Router NAT 1 -LAN 2 ---> Se conecta a Internet mediante el Router NAT 1

Esquema de red

2- Material necesario para los ensayos

-Dos computadores con Sistema Operativo Linux-Herramientas Tcpdump y Hping3 instaladas en ambos-Conexión a Internet mediante routers NAT

3- Problemática a solucionar

Cuando se establece una conexión contra un servidor web , el hecho de que el usuario cliente esté situado detrás de un encaminador NAT, no plantea ninguna problemática dado que el camino hacia el servidor está claramente definido por una IP pública y un puerto conocido. Así mismo,con el primer paquete contenedor de segmento SYN para el establecimiento de la conexión TCP,ocurre que en el router NAT se establece una asociación inequívoca entre una IP privada , un puerto de origen privado , y un puerto de origen público, de tal manera que el camino de retorno queda también claramente definido mediante esta asociación a la cual también se conoce como mapeo efímero. Por lo tanto el paquete de respuesta del servidor que a su vez contiene el segmento ACK - SYN , llega sin problemas al computador donde se ejecuta el proceso cliente , pues parte del computador donde corre el proceso servidor portando en el campo de dirección de destino la IP pública del router que esconde al computador cliente. Gracias al mapeo efímero establecido , se traduce la dirección IP pública a la IP privada , y dicha respuesta llega al origen de la conexión.

Tras el tercer paquete de inicio de conexión , que lanzará el servidor, todos los datos que fluyan en ambos sentidos llegarán a su destino siguiendo esta misma lógica.Podría darse el caso en el que un servidor, al igual que el cliente, también esté detrás de un router NAT. En este caso un mapeo estático en el router tras del cual está el computador que hace servidor , servirá como guía para enrutar los paquetes hacia el servidor. Este mapeo estático, estará constituido por una asociación entre el puerto donde escucha el proceso servidor , y su IP privada, de tal manera que todos los paquetes que se dirijan desde la Internet hasta la interface pública del router NAT del servidor , y que tengan como puerto de destino,el puerto donde escucha el servidor , serán traducidos y direccionados hacia el computador donde corre dicho proceso.A la hora de establecer un flujo de datos bidireccional de tipo peer to peer, podríamos al igual que en el caso de cliente servidor, establecer mapeos estáticos en ambos routers, pero esta opción plantea la problemática de que ambos usuarios no versados necesariamente en redes informáticas , deben saber realizar estas asociaciones configurando el router manualmente.Ésta no es tarea compleja para el profesional de la informática y telecomunicaciones, o para un usuario avanzado , pero desanima y causa temor en el usuario convencional.Pretendemos por lo tanto posibilitar estos flujos mediante mapeos efímeros, como los que se establecen en el router del lado del servidor en comunicaciones cliente servidor. También pretendemos, y esto resultará muy novedoso, prescindir de un servidor intermediario o super nodo entre los agentes p2p , para que se pueda iniciar la transferencia de datos entre estos últimos.

4- Descripción general de las pruebas

Queremos establecer un mapeo efímero en dos routers NAT que esconden a dos agentes p2p,y que desean intercambiar datos. No deseamos la intervención de un tercer nodo , o servidor contra el cual establecer un flujo de datos como excusa para que vea nuestra IP pública y el puerto de origen con el que salimos a la Internet, y que forma parte de la información del mapeo estático. Esta información de ambos mapeos originados con el propio flujo saliente, es intercambiada entre los agentes gracias al supernodo, y permite a cada uno disparar su flujo ya hacia el otro agente , apuntando a la dirección pública del router NAT contrario y hacia el puerto público con el que sale el agente remoto. Por lo tanto, trabajaremos intercambiando la IP pública de cada router NAT de los agentes, vía correo electrónico, y con puertos de origen públicos conocidos desde las propias LAN, pues algunas pruebas preliminares realizadas con anterioridad a la realización de este documento, nos demuestran que al menos para el tráfico UDP , los routers NAT no traducen el puerto de origen de los paquetes salientes hacia la Internet. Así mismo, como es lógico, trabajaremos con puertos de destino también fijos. Las pruebas a realizar simularán la siguiente situación:

-El computador PC1 envía un flujo de datos streaming desde el puerto xxx hacia el computador PC2 que recibe dichos datos en el puerto yyy. Inicialmente el computador PC2 genera un mapeo efímero en el Router NAT 2 enviando un flujo de datos udp hacia el computador PC1 con puerto de origen yyy y puerto de destino xxx.La teoría NAT que podemos encontrar en la mayoría de los textos técnicos no hace referencia al puerto de destino a la hora de explicar los mapeos efímeros , ya que solo se necesita el puerto de origen del flujo para que sea viable el direccionado del flujo de contestación hacia el ordenador que inicia la comunicación, pero en realidad los mecanismos NAT guardan una tabla que contiene puerto de origen privado , puerto de destino y la IP privada. Para que el mapeo sea efectivo debe de haber concordancia los puertos entre los puertos del flujo que origina el mapeo, y los puertos del flujo streaming.

-El computador PC2 envía un flujo de datos streaming desde el puerto vvv hacia el computador PC1 que recibe dichos datos en el puerto www. Inicialmente el computador PC1 genera un mapeo efímero en el Router NAT 1 enviando un flujo de datos udp hacia el computador PC2 con puerto de origen www y puerto de destino vvv.

5 Secuencia de acciones

El ordenador residente en la LAN 2 dispara continuamente paquetes UDP hacia la IP pública del Router NAT1 usando un puerto de origen fijo, que constituiría en una aplicación real, el puerto de entrada por donde se recibirían el flujo de datos de entrada (vídeo, voz, etc....) Pretendemos establecer un mapeo efímero en el Router NAT 2 de la LAN2.

En la Figura 1 se muestran los comandos para el envío y visualización del flujo de datos UDP que establecerá un mapeo efímero en el router NAT de la LAN2 . Los comandos se ejecutan en PC2, y el tráfico observado en esta figura es anterior al envío de datos desde el PC1, es decir, aun no se ha intentado aprovechar el mapeo efímero que se consigue con el tráfico originado desde PC2.

PC2 va a tener dirección privada 192.168.1.37 y va a enviar paquetes generadores de mapeo efímero cuyos datagramas UDP contenidos tienen puerto de origen 6000 y puerto de destino 4000.La IP pública del Router NAT 1 va a ser 213.37.223.156La IP pública del Router NAT 2 va a ser 80.37.197.123

Figura 1

En la Figura 2 se muestra la captura del flujo generador de mapeos de PC2

Figura 2

En la Figura 3 se muestran el comando que se ejecuta en PC1 para enviar el streaming a PC2.

PC1 va a tener dirección privada 192.168.1.13 y va a enviar paquetes de streaming cuyos datagramas UDP contenidos tienen puerto de origen 4000 y puerto de destino 6000.

Figura 3

En la Figura 4 se muestra el flujo de datos streaming que llega con éxito a PC2 , atravesando el Router NAT 2 desde su lado público (WAN) hacia su lado privado (LAN2).También se observa el flujo generador de mapeo, que una vez que ha posibilitado la entrada del flujo streaming puede ser parado,dado que el mapeo se mantiene solo con éste último.Figura 4

A continuación posibilitamos que desde PC2 se pueda enviar un flujo streaming a PC1 siguiendo la misma filosofía que para enviar streaming desde PC1 a PC2

Generamos mapeo efímero en el Router NAT1 introduciendo en PC1 el siguiente comando:hping3 -2 -s 7000 –keep -p 5000 80.37.197.123Véase la Figura 5

Figura 5

En la Figura 6 se muestra el flujo de datos streaming que llega con éxito a PC1 , atravesando el Router NAT 1 desde su lado público (WAN) hacia su lado privado (LAN 1).También se observa el flujo generador de mapeo, que una vez que ha posibilitado la entrada del flujo streaming puede ser parado,dado que el mapeo se mantiene solo con éste último

Figura 6

Parando los flujos generadores de mapeo en PC1 y PC2 , podemos visualizar únicamente el flujo streaming bidireccional en ambos computadores. Observese que en PC1 los paquetes entrantes, y procedentes de PC2 , tienen como dirección de origen la IP pública del Router NAT 2 , y en PC2 los paquetes entrantes, y procedentes de PC1 , tienen como dirección de origen la IP pública del Router NAT 1

Figura 6. (Flujos en PC1)

Figura 7. (Flujos en PC2)

5- Conclusiones de cara al desarrollo de una aplicación de streaming

5.1 Esquema de puertos a usar

Figura 8

5.2 Secuencia de flujos

a-Establecimiento del flujo que genera un mapeo efímero en el Router NAT 1 , para posibilitar que PC 2 envíe a PC 1 un flujo streaming desde su puerto 5000 hasta el puerto 7000 de PC 1

Este flujo generador de mapeo no atraviesa el Router NAT 2, pues no hay mapeo en el mismo que le permita llegar a PC 2. Tampoco es necesario.

Este mapeo efímero va a consistir en una asociación dirección IP de origen - puerto de origen, que le servirá al Router NAT 1 para redireccionar el tráfico procedente de Internet con puerto de destino 7000, hacia la IP 192.168.1.13, mediante la traducción 213.37.223.156 a 192.168.1.13 , y su posterior encaminamiento, hacia la interface privada del router

En la tabla de este mapeo también se guardará la asociación IP de destino - puerto de destino.Esta asociación no suele venir descrita en la bibliografía técnica que hay sobre NAT, pero ha sido descubierta tras la realización de las pruebas definidas en este documento. No es necesaria para la redirección del tráfico procedente de Internet hacia el host pertinente, pero supone una seguridad para los tráficos UDP consistente en el rechazo de streamings que no procedan de la dirección y puerto de quien se espera. En nuestro ejemplo queremos recibir un streaming procedente de la IP 80.37.197.123 - puerto 5000, y por eso generamos el flujo generador de mapeo, "disparandolo" a la IP 80.37.197.123 - puerto 5000. El mapeo vendrá determinado por la IP 192.168.1.13 y el puerto 7000, pero con la asociación IP 80.37.197.123 - puerto 5000 , nos aseguramos que a PC 1 no le llegará a su puerto 7000 , otro tráfico que no venga de PC 2.

Véase todo lo descrito en relación a este flujo en la Figura 9

Figura 9

b- Establecimiento del flujo streaming desde PC 1 a PC 2El flujo que parte de PC 2 atravesará el Router NAT 1 sin problemas gracias al flujo generador descrito en el apartado anterior.

Véase la Figura 10

Figura 10

c- Resto de flujosEl streaming que se establece desde PC 1 a PC 2, se establece de la misma manera que el streaming que parte de PC 2 a PC 1, es decir con un flujo generador que parte de PC 2 y que al atravesar el Router NAT 2 genera en este un mapeo efímero consistente en la asociación IP 192.168.1.37 – puerto 6000 .

5.3 Visión sencilla de la secuencia de flujos

Figura 11

--- FIN ---