Perforación UDP no se está ejecutando en 3G

Question

Estoy tratando de implementar en un software una función de perforación. El problema 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 de UDP "US" (en el puerto 9333)
• "US" envía de nuevo a "A" del puerto se se ha conectado a (puerto 31000 - puerto local 31005)
• "A" envía un mensaje a un servidor TCP "TS" diciendo que quiere conectarse a B (y proporciona el puerto 31000)
• "TS" envía un mensaje a "B" que le da el puerto "A" (31000) e ip
• "B" envía un mensaje e para "US" (en el puerto 9333)
• "US" envía un mensaje a "B" diciéndole que su 45000 puerto (localport 45005)
• "B" envía un mensaje a "TS" dar es el puerto UDP (45000)
• "TS" envía un mensaje a "a" dando puerto de B UDP (45000) e IP
• "a" empezar a enviar mensajes UDP para IP de B en el puerto 45000 y escuchar en localport 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 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 se reciben por ... Cualquiera podría tener una idea de por qué?

---

EDIT:

He probado mi router con http://nattest.net.in.tum.de/test.php y UDP perforación funciona bien, por lo que el problema no viene de mi router, pero desde mi protocolo ...

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

---

EDIT 2:

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

Lo curioso (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.

¿Eché de menos algo sobre celular NAT?

P.S. : Perdón por actualizar tanto mi pregunta, pero dado que no recibo respuesta, estoy tratando de buscar por mi cuenta ...

P.S. 2: Ya que he conseguido hacer un agujero en mi NAT, he cambiado el título añadiendo "en 3G"

---

EDITAR 3: me encontré con la prueba http://nattest.net.in.tum.de/test.php nuevo con mi ordenador conectado a Internet a través de mi iphone de Conexión 3G

Aquí está el resultado:

Al parecer, todas las pruebas de perforación de orificios UDP tuvieron éxito en la prueba noveno.

Más lejos más que parece:

UDP Ensayo de Unión (?): Punto de unión, la predicción puerto independiente es fácil

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

---

EDITAR 4:

Sólo para estar seguro, ahora me envío un mensaje a dos distintos servidor UDP, para comprobar 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. entonces la prueba hecha en EDIT 2 era correcta, udp es independiente del punto final, así que no debería haber ningún problema haciendo la perforación, supongo ... (Por lo menos con mi ISP)

Answer 1

Lamentablemente, no hay ningún 100% confiable forma 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 permitir que dos compañeros determinen 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.

• UDP Hole Punching Algorithm
• UDP Hole Punching not possible with mobile provider
• UDP hole punching host-specific failure

Answer 2

El NAT se encuentra detrás es simétrica, o cambia su número de puerto de salida en función de su destino. El perforado a través de NAT simétrico requiere un método diferente (TURN o perforación con múltiples orificios UDP). Intente hacerlo de esta manera: https://drive.google.com/file/d/0B1IimJ20gG0SY2NvaE4wRVVMbG8/view?usp=sharing