[UDP] Connexion et UDP

[plaristote]

Bonjour !

J'étais en train de me poser une question existentielle à propos de l'utilisation du protocole UDP : après m'être expliqué avec d'autres personnes un peu plus calé niveau réseau que moi, on a fini par s'entendre et comprendre qu'effectivement, quelque chose nous échappait.

Dans le cas d'une connexion TCP, en tant que développeur, les socket que nous fournissent le système nous permettent d'avoir la main-mise sur quelque chose de persistant.
Il n'y a donc que le serveur qui doit être, depuis le port spécifié, directement accessible via Internet.

Dans le cas d'UDP, en tant que développeur, on ne dispose pas d'un socket par client mais d'un socket tout court (ou un pour l'écriture et un pour la lecture) : et lorsque l'on envoi une réponse, on spécifie une IP et un port de destination.
Mais alors, si le client se trouve derrière un routeur qui ne redirige pas le port vers lui, il ne recevra pas les paquets envoyés par le serveur.

Je me demande alors comment font des serveurs de jeux comme ceux de Warcraft III ou Counter Strike pour communiquer avec leurs clients ?

Je code un jeu ou la connexion se fait en UDP en ce moment : ça ne me pose aucun problème que le serveur ne soit accessible que depuis mon sous-réseau, mais qui sait, si dans le futur je souhaite propager ma création, ça m'arrangerait pas mal de pouvoir simuler une connexion.

Quelqu'un peut-il m'éclairer sur le sujet ?

[Davidlouiz]

Un serveur UDP possède une seule socket à l'écoute sur un port donné.

Un client qui souhaite envoyer un message au serveur devra l'envoyer sur le port d'écoute du serveur. Lors de l'envoi du message, un port s'ouvre automatiquement sur le client.

Lorsque le serveur souhaite répondre au client, il regarde la provenance du message (IP et port de l'expéditeur) et envoi sa réponse sur le port ouvert du client.

Code :

1
2
3
4
5
6
7
8
9
|-------------------------------------|
| IP DESTINATAIRE | PORT DESTINATAIRE |
|-------------------------------------|
|  IP EXPEDITEUR  |  PORT EXPEDITEUR  |
|-------------------------------------|
|                                     |
|              MESSAGE                |
|                                     |
|-------------------------------------|

Les routeurs ne se préoccupent pas du port. Ils ne font qu'acheminer le message vers la machine, il ne regarde que l'IP, pas le port. Dans le cas d'une NAT (LiveBox, FreeBox...) en revanche, les entête ip et port des messages sortants sont tous réécrit avec l'IP et le port choisi pour le nattage.

Voici un exemple :

Envoi d'un message :

Supposons une machine "C", caché derrière une NAT, possède un IP en 192.168.1.10 et souhaite envoyer un message au serveur "S" en 88.124.92.88 sur sont port 2500.

Une NAT possède deux IP :
- Une IP privé connu du réseau local uniquement
- Une IP publique connue du réseau Internet

L'IP de la NAT sur le réseau local est 192.168.1.20 tandis que son IP publique est 66.43.21.66.

Code :

1
2
3
|---|                               |-----|                                         |---|
| C |192.168.1.10 ----- 192.168.1.20| NAT |66.43.21.66 ---(Internet)--- 88.124.92.88| S |
|---|                               |-----|                                         |---|

Lorsque le client envoi un message au serveur, il envoi ce message à la NAT :

Code :

1
2
3
4
5
6
7
8
9
|-------------------------------------|
|  88.124.92.88   |        2500       |
|-------------------------------------|
|  192.168.1.10   |        1555       |
|-------------------------------------|
|                                     |
|              MESSAGE                |
|                                     |
|-------------------------------------|

Ce message ne pourrait pas circuler sur le réseau Internet car le champ IP EXPEDITEUR est un IP de réseau local inaccessible depuis l'extérieur. La NAT va donc réécrire ce champs en se désignant comme expéditeur. Elle en profite au passage pour réécrire le numero de port qu'elle mémorise dans une table de correspondance (local <---> internet).

Code :

1
2
3
4
5
6
7
8
9
|-------------------------------------|
|  88.124.92.88   |        2500       |
|-------------------------------------|
|   66.43.21.66   |        1444       |
|-------------------------------------|
|                                     |
|              MESSAGE                |
|                                     |
|-------------------------------------|

Table de correspondance à l'intérieur de la NAT :

Code :

1444 <---> 192.168.1.10:1555

Le message sera ensuite acheminé de routeur en routeur vers la machine serveur 88.124.92.88.

Retour de la réponse :

Le serveur, ayant reçu le message, découvre que l'expéditeur est 66.43.21.66:1444. Il s'agit de la NAT mais il n'a aucun moyen de savoir que c'est la NAT. Pour lui, son client c'est 66.43.21.66:1444 et il répondra à 66.43.21.66:1444.

Il envoi sa réponse en permutant les champs DESTINATAIRE et EXPEDITEUR :

Code :

1
2
3
4
5
6
7
8
9
|-------------------------------------|
|   66.43.21.66   |        1444       |
|-------------------------------------|
|  88.124.92.88   |        2500       |
|-------------------------------------|
|                                     |
|              REPONSE                |
|                                     |
|-------------------------------------|

Le message passe de routeurs en routeurs jusqu'à arriver à la NAT du côté Internet. La NAT regarde le champs PORT DESTINATAIRE et lit ceci :

Code :

1
2
3
|-----------|
|   1444    |
|-----------|

Elle regarde dans sa table de correspondance et vois ceci :

Code :

1444 <---> 192.168.1.10:1555

Elle réécrit les champs DESTINATAIRE et envoi le message du côté local :

Code :

1
2
3
4
5
6
7
8
9
|-------------------------------------|
|  192.168.1.10   |        1555       |
|-------------------------------------|
|  88.124.92.88   |        2500       |
|-------------------------------------|
|                                     |
|              REPONSE                |
|                                     |
|-------------------------------------|

Le client reçois alors le message de réponse en provenance du serveur. Il ignore d'ailleurs l'existence de la NAT.

J'espère que mes explications t'auront parue claire. J'ai passé certaines choses sous silence pour clarifier les explications. Si un jour tu entends parler du modèle OSI, sache que mes explications se sont limité volontairement au couche 3 et 4. En réalité, une couche 2 permet au client de connaitre et de communiquer avec la NAT. Cette couche 2 d'appui elle même sur une couche 1 : la couche physique (Wifi, Ethernet).

[Nieli]

Bonjour.

Je me permets de faire remonter ce sujet car il tombe pile sur le problème que nous avons.

Nous développons actuellement un jeu en P2P utilisant UDP pour les communications interclient.
Pour l'instant, afin que le jeu marche, nous sommes obligés de rediriger le port utilisé par l'application sur la box/routeur vers le client qui veut jouer.

Existe-t-il un moyen de faire en sorte que l'utilisateur n'ait pas à faire ça?
D'après ce que je comprends de votre explication, le NAT se fait tout seul ? Est-ce ce dont nous avons besoin ?

Devons nous changer de protocole ou de méthode de communication pour enlever cette contrainte de redirection de port ?

Merci d'avance,

Nieli

[nouknouk]

Hello,

les NAT 'classiques' le feront tout seuls à partir du moment où on leur a déjà demandé d'envoyer des paquets vers une destination identique (ie. IP et port) à l'expéditeur du paquet reçu.

Si un ordi [A] du réseau local (derrière le NAT) envoie un paquet à destination de l'88.111.222.123 sur le port 1234 et que quelques temps après le NAT reçoit un paquet de 88.111.222.123 sur le port 1234, il peut logiquement conclure que le paquet a toutes les chances d'être destiné à l'ordi [A] et pas un autre. Il va donc forwarder le paquet à [A].

Par contre, si le NAT n'a jamais relayé auparavant de paquet émis par [A] à destination de 88.111.222.123 : 1234, il n'a aucun moyen de deviner que le paquet qu'il vient de recevoir est destiné à [A] plutôt qu'un autre ordi de ton sous-réseau ; le paquet sera donc purement et simplement filtré.

Tu peux trouver plus d'infos en te renseignant sur la notion de 'UDP Hole Punching' qui consiste justement à "percer" les barrières pour que deux machines NATées puissent communiquer directement ensembles en UDP sans redirection de port

[Nieli]

Merci pour votre réponse.

Cependant, en enlevant la règle de redirection de la box (liveBox), il ne semble pas y avoir de redirection automatique, alors que c'est bien le client derrière la liveBox qui initialise la connexion.

Est-il possible qu'il y ait un rapport avec le fait que le client soit en wifi ? (redirection nat bloquée par sécurité en wifi ?)

[nouknouk]

Envoyé par Nieli

Est-il possible qu'il y ait un rapport avec le fait que le client soit en wifi ? (redirection nat bloquée par sécurité en wifi ?)

Je ne pense pas: la notion de WiFi intervient sur des couches réseau plus basses (couche physique, ...) qui typiquement encapsulent ce qui se passe aux couches plus hautes (typiquement IP, UDP). Donc c'est transparent pour le NAT.

Pour le reste, je ne vois pas à priori ce qui pourrait poser souci.

[Nieli]

Merci de votre aide !
En effet, nous avions mal saisi la notion de NAT, maintenant c'est beaucoup plus clair et en effet les règles NAT s'ajoute automatiquement.

Cependant, nous avons un autre problème inhérent à ces règles NAT, lorsqu'il y a 2 client dans le même réseau local:

Nous avons deux clients dans un réseau local : C1 et C2. Ces 2 clients se connectent à un serveur S sur le port P.
Nous avons compris que lorsque C1 initiait une connexion vers S, une règle NAT se mattait en place automatiquement sur son routeur (tout ce qui vient du serveur S et sur le port P est redigiré vers C1).
Cependant, si C1 et C2 font la même chose vers le même serveur (même ip serveur et même port), il faudrait alors 2 règles, du coup comment fait le routeur pour s'y retrouver et savoir s'il doit envoyer à C1 ou à C2 ?

D'après les tests que nous menons sur notre propre jeu, si C1 et C2 se connectent, seul le premier à s'être connecté reçoit les messages. Que doit-on faire pour que cela marche ?

Merci d'avance,

Cordialement

[nouknouk]

Envoyé par Nieli

Cependant, si C1 et C2 font la même chose vers le même serveur (même ip serveur et même port), il faudrait alors 2 règles, du coup comment fait le routeur pour s'y retrouver et savoir s'il doit envoyer à C1 ou à C2 ?

Réponse: il ne peut pas ; donc on observe le souci que tu mentionnes dans le reste de ton post.

Que doit-on faire pour que cela marche ?

Bidouiller: Multiplier le nombre de ports différents auxquels les clients peuvent se connecter et se débrouiller pour que lorsque deux clients sont derrière le même NAT non seulement ils le sachent mais qu'en plus ils aient les moyens de choisir deux ports différents.

[Nieli]

D'accord, c'est bien ce que nous redoutions. Nous avons déjà un peu bidouiller mais on voulait être sûr qu'il n'y avait pas de solution simple.

Merci encore