Bonjour à tous, voici ma feuille de mission, j'espère que vous apprécirez la présentation à la JamesBond
 
 
Objectif
 Me connecter à Battle.net pour y jouer à mon jeux préféré : StarCraft.
 
Données
Je suis connecté à un hotspot NeufWifi publique.
Starcraft utilise le port 6112 en UDP
 
Problème
La connexion à Battle.net échoue directement.  
Le programme met longtemps avant de se rendre compte qu'il ne peut pas se connecter.
J'en déduis que la 9box bloque le port 6112.
 
Solution testée N°1
J'ai installé un serveur socks 5 sur ma dédibox (en l'occurrence "danted" )
Configurée de façon très souple, le proxy accepte tout et redirige n'importe où.
J'utilise également proxifier pour socksifier Starcraft.exe
Résulats: Je parviens à me connecter à battle.net mais celui ci me dit : "Votre port 6112 udp à un débit très faible ou est fermé, vous pourrez discuter mais pas jouer. Contacter votre administrateur... blablabla"
 
Solution testée N°2
Utiliser YourFreedom et proxifier.
Résulats: Identiques. Je parviens à me connecter mais la communication sur le 6112 UDP ne marche pas ou mal
 
Votre mission :
Quels sont les réflexes à avoir pour trouver l'endroit qui coince ?
Y'a-t-il une configuration particulière à apporter à mon serveur socks pour l'UDP ?
Sur quel autre service UDP puis-je essayer de me connecter de chez moi via mon proxy pour savoir si le problème se trouve entre moi et le proxy ou entre le proxy et battle.net ?
 
 
Je vous remercie d'avance pour votre aide et vos suggestions.

Re-Bonjour à tous,
 
Voici quelques nouveaux éléments à ajouter au puzzle.
 
Objectif
Déterminer à quel niveau se situe le problème.
A. Entre le proxy socks et battle.net, ou
B. Entre le client (moi) et le proxy
 
 
Test N° 1:
 
Installation d'un serveur Proxy+ chez un ami qui n'a aucun souci de connexion à battle.net et ce, meme si il passe par son propre proxy.
-> La configuration du proxy est bonne, je parviens à m'y connecter, log à l'appuis coté client et serveur
-> La communication entre Proxy+ et Battle.net n'est donc pas à mettre en cause.
Résulats : Identique, toujours pas de communication sur le port 6112 UDP lorsque j'essaye de me connecter à battle.net via le Proxy+ de mon ami.
Conclusion : Le problème vient vraisemblablement de la communication entre le moi et le proxy plutot qu'entre le proxy et Battle.net
 
 
Test N° 2:
 
Installation d'un serveur à l'écoute de l'UDP sur la machine de mon ami et tentative de connexion sur ce serveur dans 4 configurations.
Résulats :
1. Depuis ma dédibox (test préalable)
    -> Connexion OK. Le programme qui écoute sur un port UDP répond bien aux requètes, la communication est donc possible.
    -> Pas de probleme de fermetures de ports sur la freebox de mon ami
2. Directement depuis ma machine (derrière mon hotspot Neuf Wifi)
    -> Connexion impossible au serveur UDP tant sur le port 80 que le 8080 (ports que je sais ouvert par la NeufBox, dumoins en TCP)
3. Via mon proxy socks danted (toujours derrière mon hotspot Neuf Wifi)
    -> Connexion impossible sur les ports UDP 80 et 8080
4. Via le Proxy+ de mon ami.
    -> Connexion impossible sur les ports UDP 80 et 8080
Conclusion : J'en déduis que la NeufBox bloque tout le trafic UDP tel qu'il soit.
 
 
Questions :
* Si on part de l'hypothèse que la NeufBox bloque tout traffic UDP, quelles solutions me reste-t-il ?
* Est il possible "d'encapsuler" les trames UDP dans du TCP ? (Pardonnez-moi si cette question n'a aucun sens. Encore une fois, je suis loin d'être un phénix en technologies réseaux)
* Je commence à perdre espoir dans cette quête héroïque digne de l'épopée d'Ulysse... et je me dis qu'il serait peut être plus simple de de contacter directement le propriétaire de la NeufBox pour qu'il m'ouvre ce dont j'ai besion. Reste un problème, comment le trouver. Y a-il a moyen de communiquer avec le propriétaire du hotspot sur lequel on se connecte ?

Pardonnez moi mon père car j'ai péché, j'avais perdu la foi... mais cela ne se reproduira plus !
 
J'ai des nouveaux éléments et quelques reponses (a mes propres question, certes, mais mieux vaut ça que rien du tout... merci les copaings !)
 
Question 1 :

Réponse :
Il faut essayer de déterminer à quel niveau l'information est bloquée dans le parcourt qu'elle empreinte.
Dans mon cas. je sais que les données doivent passer (dans la configuration proxy) de : A --> a --> B --> C puis de C --> B --> a --> A, avec
  A : mon pc fixe
  a : la Neuf box sur lequel je suis connecte via le hotspot Neuf Wifi
  B : mon serveur dedibox (qui héberge le proxy)
  C : le réseau Battle.net
Après, il faut faire les tester que l'information passe bien entre les différentes sections.
Ici, je ne peux malheureusement pas tester individuellement les chemins A --> a et a --> B, donc on testera directement A --> B
Ce que nous amène à la question suivante...
 
 
Question 2 :

Si on reformule clairement la question, ca donne : Comment tester la communication UDP sur un port donne entre deux machines ?
Reponse :
La, j'ai fait quelques découvertes, notamment celle du l'utilitaire "nc" sous linux
Ce programme permet de créer un serveur qui écoute soit en UDP, soit en TCP sur un port donne.
Il permet également de faire office de client en se connectant sur une machine et un port donne, toujours en TCP ou UDP.
Dans mon cas, j'ai donc crée un serveur d'écoute sur ma dedibox, en UDP, sur un port que je savais ouvert par la NeufBox (dumoins en TCP), le 8080

De mon cote, sur mon pc, il me fallait un programme capable de faire office de client pour se connecter à ce serveur en UDP.  
Je connaissais bien telnet mais celui ci, à ma connaissance, se connecte uniquement en TCP. J'ai donc cherché et j'ai découvert l'utilitaire UDPCCLI, disponible ici : http://www.hyper.com/Portals/0/Dow [...] DPCCLI.zip
Ce package contient également un exécutable "UDPCServ.exe" qui permet d'avoir l'équivalent de "nc" en mode serveur UDP sous windows. Une belle trouvaille !
Bon au final, comme je l'ai explique dans ma dernière réponse, tous ceci ne m'a permis que de m'apercevoir que la NeufBox bloque tout le trafic UDP.
Ce qui m'avait amené à une autre question dans ma première réponse au topic.
 
Question 3 : Est il possible "d'encapsuler" les trames UDP dans du TCP ?
Réponse :
Oui ! C'est possible. Je ne connais pas les détails techniques ni les conséquences sur les communications d'une telle transformation (genre perte de données, trames coupées en deux, etc...) mais c'est possible assez facile à faire.
Voici comment (sous linux, je n'ai pas cherche pour l'instant à le faire sous windows mais je vais devoir m'y intéresser pour mon but final)
Sur la machine A, je lance un tunnel qui écoute sur le port 6112 UDP et qui rebalance tout sur la machine B sur le port 8080 en TCP à l'aide de la commande suivante :

88.x.x.x étant l'ip de ma dedibox.
 
Sur la machine B, je lance un tunnel qui écoute sur le port 8080 en TCP et rebalance tout sur le port 6112 UDP.
Ici, dans un objectif de test, je ne redirige pas le flux sur battle.net mais sur un 2em programme à l'écoute du port 6112 UDP sur la machine B. Cela permettra de s'assurer que les tunnels fonctionnent bien avant d'aller plus loin dans la chaine.

 
Il ne reste plus qu'a tester la connexion UDP encapsulée entre A et B. Pour se faire, comme je le disais à l'instant, je lance un programme à l'écoute du port 6112 UDP sur la machine B.  
Sur A, Je lance un client qui tente de se connecter en UDP. Biensur, ce client n'essaye pas de se connecter à B, mais bien à localhost, c.a.d. sur le tunnel qui devrait transformer les paquets TCP en flux UDP.
 
Machine B.

Machine A.

Et la, miracle ! Ça marche!  
L'information parcourt ainsi la chaine suivante :
A en 6112 UDP --> A en 8080 TCP --> a en 8080 TCP --> B en 8080 TCP --> B en 6112 UDP
 
Nouveaux objectifs :
1. Faire la même chose mais en A machine Windows.
2. Ensuite, se débrouiller pour que Startcraf.exe se connecte (qui est lancé sur A) non pas à battle.net mais à localhost, pour profiter du tunnel.
3. Faire en sorte que, en fin de chaine, B ne rebalance par le flux sur un programme de test à la con mais sur le vrai reseau Battle.net
 
Pour 2, je pense qu'un hack du fichier cwindows/system32/drivers/etc/hosts fera l'affaire, mais j'ai un peu peur que l'ip donnée par un "ping europe.battle.net" ne soit pas la vrai IP sur lequel le jeu se connecte. Je ne maitrise pas assez les DNS et les informations qu'ils charrient pour le savoir.
Pour 3, ma même chose, tout dépendra de 2.
Enfin, pour 1, je ne connais pas d'outils qui permette de faire ça. Du moins pas encore. Je sens que je vais encore bien galérer à crawler le net...
 
Questions :
Comment créer un tunnel UDP vers TCP sous windows (équivalent d'un "nc -l -u -p 6112 < /tmp/fifo | nc 82.x.x.x 8080 > /tmp/fifo" ) ?