udp 3g hole-punching 3g-network

Perforación UDP no se realiza en 3G



hole-punching 3g-network (2)

Estoy tratando de implementar en un software una función de perforación. La cuestión es que estoy implementando esto con un servidor TCP ya creado para comunicarme con los usuarios.

Esto es lo que tengo hasta ahora:

  • "A" envía un mensaje a un servidor UDP "US" (en el puerto 9333)
  • "EE. UU." Devuelve a "A" el puerto al que se ha conectado (puerto 31000 - puerto local 31005)
  • "A" envía un mensaje a un servidor TCP "TS" diciendo que quiere conectarse a B (y le da el puerto 31000)
  • "TS" envía un mensaje a "B" que le da el puerto "A" (31000) y la dirección IP
  • "B" envía un mensaje a "EE. UU." (En el puerto 9333)
  • "EE. UU." Envía un mensaje a "B" indicándole su puerto 45000 (localport 45005)
  • "B" envía un mensaje a "TS" dando es el puerto udp (45000)
  • "TS" envía un mensaje a "A" dando el puerto udp de B (45000) e ip
  • "A" comienza a enviar el mensaje udp a la ip de B en el puerto 45000 y escucha en el puerto local 31005
  • "B" comienza a enviar el mensaje udp a la ip de A en el puerto 31000 y escucha en el puerto local 45005

Por supuesto, los puertos 31000, 31005, 45000 y 45005 están aquí, por ejemplo, cada nueva conexión cambia el puerto, solo 9333 es estático.

Sé que hay un montón de ida y vuelta, más de lo que realmente debería ser. El hecho es que estoy obligado a usar el servidor TCP para comunicarme con ambos usuarios, el servidor udp está aquí para devolver el puerto del Usuario a él mismo para que pueda enviarlo de vuelta al Servidor TCP.

Sin embargo, los mensajes entre los usuarios no son recibidos por ... ¿Alguien tendría una idea de por qué?

EDITAR:

He probado mi enrutador con http://nattest.net.in.tum.de/test.php y udp hole punching funciona bien, así que el problema no proviene de mi enrutador, sino de mi protocolo ...

Cuando los usuarios están detrás de la misma NAT, todo funciona bien, por supuesto usa IP privada, pero significa que el código también está funcionando, por lo que cada paso lleva a un problema de protocolo ...

EDICION 2:

En realidad, lo hice a medias (Y el problema provenía de mi código en realidad, no del protocolo ... He conectado 2 usuarios, uno en 3G con un iPhone, uno detrás de mi NAT en Wifi.

Lo gracioso (bueno, no tanto) es que solo un socket fue capaz de recibir y enviar datos entre ambos usuarios. (el zócalo iniciado por el iphone) De acuerdo con el protocolo, debería tener 2 zócalos bien conectados, ¿me equivoco?

Así que logré perforar un agujero en mi NAT, pero en realidad no en el NAT celular.

Por supuesto, probé de inmediato 2 iphones conectados en 3G. Y nadie recibe el mensaje del otro.

¿Me perdí algo sobre NAT celular?

PD: Perdón por haber actualizado tanto mi pregunta, pero como no recibo respuesta, estoy tratando de encontrarla por mi cuenta ...

PD 2: Desde que logré perforar un agujero en mi NAT, he cambiado el título agregando "en 3G"

EDIT 3 : Ejecuté la prueba http://nattest.net.in.tum.de/test.php nuevamente con mi computadora conectada a internet a través de la conexión 3G de mi iPhone.

Este es el resultado:

Aparentemente, todas las pruebas de perforación udp fueron exitosas en la novena prueba.

Más aún parece:

Prueba de unión UDP (?): Unión independiente de punto final, predicción de puerto es fácil

Por lo tanto, no debería haber ningún problema para conectar 2 pares a través de la conexión 3G (no mucho más que detrás de una NAT "doméstica") ... ¿Estoy en lo cierto?

EDIT 4:

Solo para estar seguro, ahora envío un mensaje a dos servidores UDP distintos para verificar si el puerto y el puerto local son los mismos en 3G.

Para abreviar, los puertos (locales y públicos) son los mismos cuando se conectan en ambos servidores. así que la prueba hecha en EDIT 2 era correcta, udp es independiente del punto final, por lo que no debería haber ningún problema para perforar, supongo ... (Al menos con mi ISP)

Desafortunadamente, no existe una forma 100% confiable de realizar perforaciones NAT con UDP. En el mejor de los casos, puede hacer algunas conjeturas acerca de cómo los NAT y los cortafuegos probablemente se comporten la mayor parte del tiempo. Pero siempre habrá excepciones y es posible que no sean raras.

En este caso, parece que está utilizando un servidor central para que dos compañeros descubran el puerto externo de cada uno y luego comiencen a enviarse datos entre ellos. Ese es un algoritmo bastante bueno. El problema es que el enrutamiento del puerto externo puede variar según el destino. En otras palabras, si A to B tiene un puerto externo de 5000, no hay garantía de que A hasta C también provenga de 5000. Por lo tanto, tener un servidor central que registre el puerto que ve puede no ayudar a conectar a nadie más.

Aquí hay algunas preguntas relacionadas con algunos detalles más.

  • Algoritmo de perforación UDP Hole
  • Perforación UDP Hole no es posible con el proveedor de telefonía móvil
  • Fallo UDP específica de perforación de agujero del agujero