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

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

2. 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 xxx
PC1 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

3. Figura 1

4. Figura 2

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

6. Figura 4

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

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

9. Figura 7

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

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

12. Figura 10
--- FIN ---