Question UDP perforation ne passe pas en 3G


J'essaie d'implémenter dans un logiciel une fonction de perforation. Le fait est que je l’implémente avec un serveur TCP déjà créé pour communiquer avec les utilisateurs.

Voici ce que j'ai jusqu'à présent:

  • "A" envoie un message à un serveur UDP "US" (sur le port 9333)
  • "US" renvoie à "A" le port auquel il s'est connecté (port 31000 - localport 31005)
  • "A" envoie un message à un serveur TCP "TS" en disant qu'il veut se connecter à B (et donner le port 31000)
  • "TS" envoie un message à "B" lui donnant le port "A" (31000) et ip
  • "B" envoie un message à "US" (sur le port 9333)
  • "US" envoie un message à "B" lui indiquant son port 45000 (localport 45005)
  • "B" envoie un message à "TS" donnant le port udp (45000)
  • "TS" envoie un message à "A" donnant le port udp de B (45000) et ip
  • "A" commence à envoyer un message UDP à l'adresse IP de B sur le port 45000 et écoute sur localport 31005
  • "B" commence à envoyer un message udp à l'adresse IP de A sur le port 31000 et écoute sur localport 45005

Bien sûr, les ports 31000, 31005, 45000 et 45005 sont ici, par exemple, à chaque nouvelle connexion que le port change, seul le 9333 est statique.

Je sais qu'il y a beaucoup de va-et-vient, plus qu'il ne devrait l'être. Le fait est que je suis obligé d'utiliser le serveur TCP pour communiquer avec les deux utilisateurs, le serveur udp est juste là pour renvoyer le port de l'utilisateur pour qu'il puisse le renvoyer au serveur TCP.

Cependant les messages entre utilisateurs ne sont reçus par aucun ... Quelqu'un aurait une idée pourquoi?


MODIFIER :

J'ai testé mon routeur avec http://nattest.net.in.tum.de/test.php et udp hole punching fonctionne bien, donc le problème ne vient pas de mon routeur, mais de mon protocole ...

Lorsque les utilisateurs sont derrière le même NAT, tout fonctionne bien, bien sûr, il utilise des propriétés IP privées, mais cela signifie que le code fonctionne également, donc à chaque fois, cela mène à un problème de protocole ...


EDIT 2:

En fait, je l'ai fait à moitié travailler (et le problème venait de mon code en fait, pas du protocole ... J'ai connecté 2 utilisateurs, un en 3G avec un iPhone, un derrière mon NAT sur Wifi.

La chose la plus amusante (et pas tellement), c'est qu’une seule socket pouvait recevoir et envoyer des données entre les deux utilisateurs. (le socket initié par l'iphone) Selon le protocole, je devrais avoir 2 prises bien connectées, je me trompe?

J'ai donc réussi à percer un trou dans mon NAT, mais pas dans le NAT cellulaire.

Bien sûr, j'ai tout de suite testé 2 iphones connectés en 3G. Et personne ne reçoit le message de l'autre.

Ai-je raté quelque chose à propos du NAT cellulaire?

P.S. : Désolé pour avoir mis à jour tellement ma question, mais comme je ne reçois aucune réponse, j'essaie de trouver par moi-même ...

P.S. 2: Depuis que j'ai réussi à percer un trou dans mon NAT, j'ai changé le titre en ajoutant "on 3G"


EDIT 3 : J'ai couru le http://nattest.net.in.tum.de/test.php Testez à nouveau avec mon ordinateur connecté à Internet via la connexion 3G de mon iPhone.

Voici le résultat: UDP HOLE PUNCHING RESULT

Apparemment, tous les tests de perforation ont été réussis lors du 9ème test.

En plus il semble:

Test de liaison UDP (?): Liaison indépendante du point de terminaison, la prédiction de port est facile

Donc, il ne devrait pas y avoir de problèmes de connexion entre 2 pairs sur la connexion 3G (enfin, pas grand chose que derrière un NAT "maison").


EDIT 4:

Juste pour être sûr, j'envoie maintenant un message à deux serveurs UDP distincts, pour vérifier si le port et le port local sont les mêmes sur la 3G.

En bref, les ports (locaux et publics) sont les mêmes lors de la connexion sur les deux serveurs. donc le test effectué sur EDIT 2 était correct, udp est indépendant du point de terminaison, donc il ne devrait pas y avoir de problème de perforation, je suppose ... (au moins avec mon FAI)


31
2017-09-10 21:09


origine


Réponses:


Malheureusement, il n'existe pas de méthode fiable pour effectuer des perforations NAT avec UDP. Au mieux, vous pouvez deviner comment les NAT et les pare-feu se comporteront probablement la plupart du temps. Mais il y aura toujours des exceptions et elles peuvent ne pas être rares.

Dans ce cas, il semble que vous utilisiez un serveur central pour permettre à deux homologues d'identifier chacun des ports externes, puis de commencer à se transmettre des données. C'est un bon algorithme. Le problème est que le routage du port externe peut varier en fonction de la destination. En d'autres termes, si A à B a un port externe de 5000, rien ne garantit que A à C viendra également de 5000. Donc, avoir un serveur central enregistrant le port qu'il voit peut ne pas aider à connecter quelqu'un d'autre.

Voici quelques questions connexes avec plus de détails.


15
2017-09-12 16:50



Le NAT que vous êtes derrière est symétrique ou modifie votre numéro de port sortant en fonction de votre destination. La perforation à travers un NAT symétrique nécessite une méthode différente (soit une perforation multi-trous TURN ou UDP). Essayez de le faire de cette façon: https://drive.google.com/file/d/0B1IimJ20gG0SY2NvaE4wRVVMbG8/view?usp=sharing 


1
2017-08-14 17:11