UDP, NAT y la creación de "conexiones"

Question

Sé que la palabra "conexión" no es realmente apropiado cuando se habla de UDP, pero ...

¿Cómo un servidor (el que tiene la conocida IP) llegar ¿Sus paquetes UDP a través de Internet a un cliente que está detrás de NAT?

Por ejemplo: supongamos que un cliente se conecta y se autentica en el servidor utilizando algunos mensajes a través de TCP. En este punto, el servidor está listo para comenzar a transmitir datos al cliente a través de UDP, pero ¿cómo sabe el servidor dónde dirigirse a los paquetes UDP para que encuentren su camino a través de cualquier enrutador NAT para el cliente?

Si el cliente envía un mensaje "Estoy listo para la transmisión por favor" a través de UDP, ¿los enrutadores NAT mantendrían el puerto abierto para que el servidor pueda responder con su flujo de datos UDP?

¿O estoy fuera de la pista?

Answer 1

En general, la NAT frente al cliente en el nivel de TCP podrá determinar que se creó la conexión en el UDP. Una vez dicho esto, el NAT en el lado del cliente deberá configurarse para aceptar paquetes UDP del puerto del servidor SRC, y luego reenviarlos al IP de destino interno (cliente). Es importante recordar si NAT es quién llama y quién es el destinatario. Los NAT difieren en implementación y capacidad, por lo que una solución genérica fácil de implementar es probablemente lo que puede desear implementar, dependiendo de sus necesidades.

Tiene razón al suponer, creo, que en su caso el cliente no podrá recibir la secuencia UDP en la información. En su caso, su cliente deberá enviar su IP WAN a su servidor para iniciar la conexión UDP. Encontrar a sus clientes WAN IP puede ser complicado, pero hay sitios web que lo ayudarán a determinar su IP WAN al devolverlo en una página de texto.

Si la conexión UDP se crea después de la conexión TCP por el servidor abriendo un socket al cliente a un puerto UDP conocido, entonces, UPnP podría valer la pena examinarlo le permitirá configurar automáticamente el puerto hacia adelante en su NAT , eso es solo si su NAT admite UPnP como es el caso de los enrutadores DSL.

Un work-a-round sería para el cliente abrir los sockets TCP y UDP en el servidor. Como el cliente detrás de la NAT inició la conexión, los estados de las conexiones TCP y UDP se agregarán a la tabla de conexiones de la NAT.

Answer 2

Haciendo caso omiso de la prestación de traducción de puertos conocidos (es decir, datos sobre este puerto va a esta dirección) en su router (siempre que el NAT), puede utilizar UDP Hole Punching.

Supongo que no está hablando de multicasting, en el que cada par se une a un grupo y lo anuncia a las partes interesadas (en este caso, el enrutador), que luego puede realizar el enrutamiento adecuado. Aunque normalmente se usa para enrutar el tráfico de manera eficiente a varios hosts, el mecanismo de enrutamiento por grupo funcionaría para lo que describa arriba.

Answer 3

Si habla de protocolos de transmisión como SIP o RTSP, entonces la forma en que funciona es que el puerto UDP que el cliente desea que el servidor envíe se especifica en la solicitud de configuración de llamada.

El servidor enviará a ese puerto y el tráfico puede o no llegar al cliente dependiendo de si el NAT ha traducido la opción de puerto preferida a un número diferente o no.

Cuando el servidor recibe su primer paquete de transmisión UDP del cliente y si está en un puerto diferente al que estaba enviando, entonces cambiará a él. Esto permite que el UDP del servidor pase por el NAT, ya que el cliente ya ha creado el mapeo NAT al enviarlo al servidor.