Salut à tous,
 
 
La question du jour est la suivante :
 
J'ai un réseau local chez moi de plusieurs ordinateurs, le tout relié à la freebox en mode routeur.
J'aimerai jouer à age of empires 2 conquerors (on ne rigole pas !) sur internet, non avec 1 pc mais 2 pc (les deux joueurs du réseau local se connectent à un troisième qui est sur le net).
 
Schéma :
 
           PC 1 ----------
  192.168.0.2             |
                          Freebox -----------> partie internet
                               |
           PC 2-----------
  192.168.0.3
 
 
Le soucis c'est qu'il faut router plusieurs ports UDP et TCP dans le mode routeur de la freebox : on ne peut les rediriger que sur une seule IP.
 
D'où la question : Y a t-il une solution pour les router sur 2 PC, ce qui me parait impossible ?
 
On m'a dit que ça pouvait peut-être marcher en passant en IPV6 "pour avoir une ip distincte sur chaque PC" mais j'avoue que je n'ai rien trouvé la dessus.
 
Merci d'avance aux experts réseau de m'aider !
 
Et bon weekend à tous.

aoe2 n'étant pas compatible ipv6 comme 99.99999% des jeux non tu peux pas.
 
Tu peux installer hamashi et ton pote aussi pour que vous puissiez jouer en réseau local tous les 3

Il faut router des ports ? Même pour être client ? étonnant...
Sinon tu créé la partie chez toi et tu routes les ports sur le PC hôte.
Ou Hamashi...

+1 router les ports pour etre client ?????
 
+1 pour faire serveur chez toi !
 
 tu ouvre les ports sur la free pour ton PC 1 , tu lance le jeux en serveur  
 
tu connecte ton PC 2 en rentrant l'adresse du PC1 192.168.0.2  
tu connecte ton pote a distance en lui donnant ton IP internet  http://www.whatismyip.org/
 
si tu a ouvert les bon port Serveur pour AOE2 ca devrait marcher , dans le doute par contre je me rappel plus si AOE2 permet de rentrer une IP de connexion manuellement  
 
au pire avec hamachi ca marchera nickel aussi

Oui il faut router les ports car un serveur de jeux ne fonctionne pas (seulement) en mode question/réponse. Il envoi de manière régulière de trames d'informations aux clients. Si les ports ne sont pas router il ne sait pas à quelle machine (client) attribué une trame donnée.

+1  hamachi
@+

Et alors ? Si le client initie la connexion le pare-feu laisse passer les session établies, donc ça ne doit pas poser de problème.

Hello,  
 
Euh non d'une part le plus souvent c'est de l'UDP => pas de connexions  
d'autres part les connexions TCP peuvent être fermées, même en cours de partie (dans ce cas le client en ouvrira une autre lors de sa prochaine requête) et cela quand même doit fonctionner dans l'autre sens.
 
Voilou

alors pourquoi des dizaine de milliers d'utilisateurs avec des box (donc des routeurs) , peuvent jouer a des jeux video sur des serveurs internet sans jamais ouvrir de ports ?
 
en 15 ans de jeux online j'ai jamais ouvert aucun port sur mon routeur pour jouer , et j'ai désactivé l'upnp depuis que ca existe !
 
c'est le role du routeur et du nat de faire en sorte que justement ca fonctionne
 
dans un schema classique le client se connecte au serveur avec un unique port (exemple 2302 pour ArmA) et "UNE SEULE" connexion TCP bidirectionnel est maintenue tout au long de la partie
 
ya qua lancé un analyseur reseau pour s'en convaincre
 
ouvrir des ports pour etre client      pas besoin !  
 
je veux bien que tu me cite certaines exception de jeux si tu en as ??  

Non mais ça dépend des jeux et AoE 2 en fait partie. C'est des vieux jeux et vu la grosse merde qu'est le NAT, normal que ça n'ait pas été prévu à la base

Certains jeux n'utilise que TCP, ce n'est pas la majorité. La raison est simple c'est trop lent. Tous (ou presque) les jeux nécessitant une réactivité élevée utilisent UDP ce qui implique le routage de port.

Je sais que Wow fait exemption. Mais HL 1 et 2 et tous leurs mods (CS, Day of Defeat ..) , Warcraft 1 et 2, Tribes, Unreal Tournement, War hammer 40000 etc etc tous les jeux de la XBOX 360 de la PS3 .... utilisent le l'udp.

Je ne vois d'ailleur pas ou est le problème. Router un port prend 20 secondes, car on aura prit soin de désactiver upnp (c'est vrai quoi un truc qui ouvre la port sans demandé la permission ca ne se fait pas )

ps : Age of empire 2 utilise les ports TCP : de 2300 à 2400, 47624 et UDP : de 2300 à 2400 (sources portforward.com)

mais c'est pas parce que c'est de l'UDP que ça ne peut pas marcher... Quand tu fais une requête DNS ton routeur natte bien les paquets comme il faut et tu reçoit la réponse non ? Et AoE date de 99, le NAT était déjà assez répandu.
Bon, après je ne dis pas que ça marche forcément, mais c'est quand même surprenant.

Je pense qu'il faut peux-être expliquer le fonctionnement du NAT pour mieux comprendre.  
La première chose à admettre, c'est que ce n'est pas parce que le NAT à été conçu pour régler ce type de problème qu'il est parfait et règle tous les cas. S'il l'était le cas (parfait) l'IPV6 n'aurait aucun intérêt.
 
Le Problème :
Prenons un réseau domestique de monsieur tout le monde avec doté de 4 PCs et une passerelle internet (une box) avec une (et une seule) adresse IP (v4) disponible fournie par le FAI.
Chaque PC veut avoir accès à internet mais comment faire puisqu'une seule adresse IP est disponible sur le réseau internet.  
 
La solution (actuelle) : Le NAT ou plutôt le Masquerading  
La passerelle (la box)  à une adresse WAN (celle fourni par le FAI) et distribue (dhcp) une adresse de classe C (de forme 192.168.x.y) à chacun des PCs. Le routeur NAT substitue l'adresse WAN à l'adresse LAN dans la trame IP. Dans le même temps il note dans un table de suivit de connexion la machine qui à émis (adresse IP source du paquet) cette trame et les infos sur la destination (IP, port, le protocole utilise TCP/UDP ... ).
Lorsqu'un paquet arrive de l'internet en réponse au paquet émis (typiquement l'utilisateur vient de demander la page d'accueil d'un site Web et le serveur envoi la réponse) le routeur recherche (avec l'adresse IP source, le port, le protocole)  dans sa table de suivit de connexion si cette réponse correspond à une demande connue. Dès qu'il l'a trouve, il opère la substitution inverse: l'adresse WAN destination est replacée par l'adresse LAN de la machine destinatrice. Tout fonctionne parfaitement.
 
Maintenant qu'en est-il d'un paquet arrivant spontanément sans requête préalable. Lorsqu'on héberge un service sur le réseau LAN qui doit être accessible depuis le WAN, ca peut être une serveur : site Web perso, serveur FTP, serveur de jeux ou un client P2P.
Le paquet arrive,  le router cherche dans sa table des connexions, il ne retrouve pas la connexion. Le paquet est jeter (drop) et ca ne marche pas.
 
Le cas des clients de jeux. Le problème un peu différent. Lorsque deux clients du réseaux communiques vers un seul et même serveur (le serveur de jeux), le NAT ne peut pas faire le distingo dans sa table de connexion entre les flux de communications. Si la communication est réalisé en TCP/IP le router pourra éventuellement utiliser les numéros de paquets pour s'y retrouver mais dans le cas de l'UDP ce numéro n'existant pas, le router ne peut retrouver le client auquel la trame est destiné.
 
Voila pourquoi le routage de port est obligatoire pour jouer en réseau online.  
Cela dit, c'est deux minutes à configurer  
 
Désolé pour le coté laïus j'ai essayé d'être clair et c'est toujours un peu long lorsque c'est technique.
 
Voilou @+
 
 
 
 
 
 

Mouis enfin a priori on savait ce qu'est que le NAT...
 

C'est pas comme si le numéro de port était là pour ça...
 
D'ailleurs en parlant de ça :

Rien que ça

Dans ce cas pas de problème. Ca n'a pas fait de mal hein

C'est pas comme si le numéro de port était là pour ça...
[/quotemsg]

N'hésite pas à développer un peu ...

D'ailleurs en parlant de ça :

Rien que ça [/quotemsg]

idem

Si tu peux mettre en service ce qui à été demandé sans HAMACHI et sans routage de port alors décrit moi cette solution, je ne suis pas opposé à m'améliorer

Si un PC 1 et un PC 2 font chacun une requête (DNS par exemple) en UDP vers un même serveur (1.2.3.4) sur internet. Ces requêtes ne viendront pas du même port. Le routeur remplace l'IP par son adresse WAN et note dans un coin :

Lorsque la réponse du serveur arrive, si elle arrive sur le port 40001 le paquet est forwardé vers le PC1, si elle arrive sur le 40002 alors c'est redirigé vers le PC2. En pratique, le routeur peut même changer le port à la volée, si par exemple le port 40001 était déjà pris par un autre client.
Ce que je ne sais pas c'est quand l'association expire.
 
 

Pour moi si l'IP distante créé la partie, les deux clients en interne seront en mesure de rejoindre. Je ne vois rien qui s'y opposerait. Maintenant peut-être que le protocole a été mal foutu, à ce moment-là ça met tout par-terre, notamment si le modèle TCP/IP n'est pas respecté.

 
Ok d'accord avec toi mais cela suppose que les clients utilisent (choisissent spontanément) des ports différents. Comme ils ne discutent pas entre eux comment règlent-ils ce problème ?

J'ai ça comme paramètres sur mon linux donc qq minutes
 
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_tcp_loose = 1
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_acct = 1
net.netfilter.nf_conntrack_max = 65536
net.netfilter.nf_conntrack_count = 231
net.netfilter.nf_conntrack_buckets = 16384
net.netfilter.nf_conntrack_checksum = 1
net.netfilter.nf_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_expect_max = 256

 
c'est le routeur qui translate ça aussi au besoin

En fait le gros problème vient surtout des protocoles qui dans leurs données donnent l'adresse ip et le port que doit utiliser le client/server pour faire une seconde connexion.
 
Genre le FTP. Pour ces protocoles il faut en plus modifier le contenu du payload pour réfleter le changement et c'est pour ça qu'il y a des conntrack spéciaux pour ces protocoles.
 
On est obligé aussi pour certains d'utiliser les protocoles genre ICE/STUN pour passer outre ces limitations (et le firewall).

 
En choisissant un port source aléatoire ?

C'est le cas sur HL et CS car le serveur reçoit sont adresse IP externe pour le déclarer au MasterServer.

C'est une possibilité mais qui ne fonctionnera pas à tous les coups.
Si le router NAT le port en cas de conflit à l'intérieur du LAN ca règle le problème.

 
 
J'ai pas compris ce que tu veux dire

Un stream udp est gardé 3 minutes dans la table de conntrack

C'est choisi aléatoirement sur plusieurs milliers de ports, donc peu de risque. Si c'est le cas le routeur reçoit un paquet venant de 192.168.0.1:40001, il l'enregistre. Si ensuite il reçoit un paquet du 192.168.0.2:40001, il change le port et met comme port source le 40002 (par exemple).

Effectivement le FTP est comme ça, et encore, c'est maintenant géré par la plupart des routeurs dignes de ce nom (et le FTP permet le mode passif). Le SIP notamment est très chiant pour ça (d'où l'utilisation de STUN comme tu l'as précisé)

Pas tout à fait
Le PC envoie un message au MasterServer (J'héberge un serveur CS ici). Le routeur fait son masquerade, donc le MasterServer enregistre l'IP publique. Le problème dans ce cas c'est que lorsque les joueurs tentent de se connecter le routeur ne sait pas quoi faire de ces requêtes. Il faut donc forwarder les ports.

Je suppose qu'il est renouvelé si le client renvoie des paquets ?

yep

Cool, tu peux faire des parties de plus de 3mn alors

Bon les mecs je vous file la soluce 1 an et 1/2 après ! (j'avais oublié le post!)
 
Alors il faut mettre le mode routeur de la freebox, désactiver le DHCP, attribuer des ips fixes sur chaque poste avec les DNS FREE et pas en DNS l'adresse IP de la freebox.
 
Ensuite il faut installer une interface virtuelle de carte réseau : j'utilise Tunngle mais yen a plusieurs.
 
Et voilà le travail.
 
En espérant que ça pourra aider certains.
 
Adios