Citation :
Je commence à perdre espoir dans cette quête héroïque digne de l'épopée d'Ulysse...
|
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 :
Citation :
Quels sont les réflexes à avoir pour trouver l'endroit qui coince ?
|
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 :
Citation :
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 ?
|
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
Code :
- root# nc -l -v -p 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 :
Code :
- root# mkfifo /tmp/fifo
- root# nc -l -u -p 6112 < /tmp/fifo | nc 82.x.x.x 8080 > /tmp/fifo
|
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.
Code :
- root# mkfifo /tmp/fifo
- root# nc -l -p 8080 < /tmp/fifo | nc -u localhost 6112 > /tmp/fifo
|
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.
Code :
- 1. root# nc -l -v -u -p 6112
|
Machine A.
Code :
- 1. root# nc -u localhost 6112
|
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 c
windows/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" ) ?
Message édité par micromaniac le 30-07-2009 à 09:56:29
FORUM HardWare.fr
