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

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 , separadas por un router NAT,cuyo puerto WAN ethernet constituirá una interface con IP pseudopública, o lo que es igual, la LAN privada a la que se conecte será considerada como si fuera Internet. Por lo tanto a partir de este momento, y de cara a nuestros ensayos , quedan definidas dos redes:

-LAN 1 ---> La consideraremos como red pública (Internet)-LAN 2 ---> La consideraremos como red privada.

2- Material necesario para los ensayos

-Dos computadores con Sistema Operativo Linux-Herramientas Tcpdump y Hping3 instaladas en ambos-Un router NAT – PAT

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 escusa 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.

4.a-) Prueba A. El ordenador residente en la LAN 2 dispara continuamente paquetes UDP hacia una IP desconocida 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....) Con IP desconocida queremos decir una IP diferente , de aquella desde la cual enviaremos el flujo de datos UDP hacia ese canal de entrada. Pretendemos establecer un mapeo efímero en el router NAT de la LAN2.

Secuencia de acciones :

PC2 envía desde LAN2 paquetes UDP hacia una IP arbitraria con puerto de origen xxxPC1 envía otro flujo de datos UDP desde LAN1 hacia la IP pública del router NAT de LAN2 , usando como puerto de destino el puerto xxx. Desde PC2 se comprueba con un sniffer-analizador de tramas si recibimos el flujo de datos procedente de PC1.

Mostramos a continuación la secuencia de comandos en ambos ordenadores y en el orden seguido

En las figuras 1 y 2 se muestran los comandos para el envío del flujo de datos hacia una IP arbitraria y su visualización . Se ejecutan en PC2

Figura 1

Figura 2

En las figuras 3 y 4 se muestran los comandos para el envío y visualización del flujo de datos que simula el streaming útil,y que debiera atravesar el router NAT de LAN2. La dirección WAN de este router (pseudopública) es la IP 192.168.1.13. Se ejecutan en PC1

Figura 3

Figura 4

La Figura 5 muestra la visualización de las tramas que circulan por la interface 192.168.2.101 de PC2 donde esperamos visualizar el flujo de datos que se envía desde PC1

Figura 5

Vemos que el resultado no es satisfactorio pues no visualizamos paquetes con la IP de origen 192.168.1.12. De alguna manera el mapeo efímero no se origina o no funciona.No podemos disparar a una IP arbitraria esperando se origine un mapeo efímero que permita enviar un flujo streaming desde otra IP distinta de ésta arbitraria.

4.b-) Prueba B. El ordenador residente en la LAN 2 dispara continuamente paquetes UDP hacia la IP del PC1 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 de la LAN2. Dado el escenario planteado , tenemos que PC1 es como si estuviera situado en la Internet. Esperamos que los resultados obtenidos, sean idénticos a los que obtendríamos situando el computador PC1 detrás de un router NAT , es decir conectado a la IP privada de este router.

En las Figuras 6 y 7 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 . En esta segunda prueba , apuntamos hacia el computador desde el cual se enviará el flujo de datos streaming (PC1)Los comandos se ejecutan en PC2, y el tráfico observado en estas dos figuras es anterior al envió 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.

Figura 6

Figura 7

En la Figuras 8 y 9 se muestran los comandos para el envío y visualización del flujo de datos streaming desde el computador PC1 con destino al computador PC2, usando como dirección de destino la IP pseudopública del router NAT de la LAN2 , y esperando que el flujo de paquetes UDP enviado desde PC2 hasta PC1 haya creado el mapeo efímero que permita que dicho streaming atraviese el router NAT y llegue al PC2. El puerto de destino será el 6000 , pues es el que ha sido usado en el flujo para la apertura de puertos efímera en el router NAT. Estos comandos se ejecutan desde el computador PC1. En esta prueba se cambió la IP pseudopública del router NAT, siendo el valor asignado 192.168.1.2

Figura 8

Figura 9

En esta figura se ven los paquetes procedentes de PC2 que atraviesan el router NAT sin ningún problema , (se originan dentro de la red privada) , y los que se originan en PC1 y que representan el flujo streaming que debe atravesar el router desde la red pseudopública hasta la red privada.

En la Figura 10 se observa los paquetes que parten de PC1 con IP destino 192.168.1.2 y que al llegar al Frutero NAT son traducidos a la IP de destino 192.168.2.101 (La IP de PC2), gracias al mapeo efímero originado [IP 192.168.2.101 Puerto 6000 ]. También se observan los paquetes que originan dicho mapeo. El resultado es por lo tanto satisfactorio y facil de realizar en presencia de un solo router NAT.

Figura 10

--- FIN ---