[UDP] Connexion et UDP

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 ?

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).

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

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

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 ?)

Citation:

---

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.

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

Citation:

---

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.

Citation:

---

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.

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

Citation:

---

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 ?

---

Attention, je me permet de revenir sur ce sujet pour ajouter une explication.

Lorsque C1 et C2, derrière une même NAT se connecte à un serveur, deux cas possibles :

- C1 et C2 sont sur deux machines différentes.
- C1 et C2 sont sur la même machine.

Voyons ces deux cas de plus près.

C1 et C2 sont sur deux machines différentes

Dans ce cas, le NAT saura différencier les machines par leurs adresses IP distincts. Lorsque les paquets de C1 et C2 seront nattés, la NAT prendra soins de réécrire des ports sources différents. Ainsi, lors de la réponse, la NAT saura à qui est destiné le message par le port destination de la réponse sera différent.

Prenons un exemple :

Les machines A (192.168.0.10) et B (192.168.0.11) sont derrière la NAT N donc l'IP publique est 88.222.222.222 et souhaitent se connecter au serveur S (88.111.111.111) sur son port 1234.
Lorsque la machine A va se connecter au serveur S, la machine A va ouvrir un port automatiquement, choisi par le système, par exemple 5550. La NAT, située entre les clients et le serveur, va analyser le paquet de générer un numéro de port, par exemple 7770. Dans sa table, elle va donc associer 7770 à 192.168.0.10:5550. De plus la NAT va réécrire le champs source du message par son IP et son port généré de telle sorte que le serveur voie le message en provenance de 88.222.222.222:7770.

Tuple ajouté à la table de la NAT :

Code:

---

7770 -> 192.168.0.10:5550

---

Maintenant, la machine B envoie un message au serveur (même IP, même port). La machine B va ouvrir un port automatiquement, choisi par le système, par exemple 5550 (pas de bol, en plus il est identique). La NAT, située entre les clients et le serveur, va analyser le paquet de générer un numéro de port, par exemple 7771. Dans sa table, elle va donc associer 7771 à 192.168.0.11:5550. De plus la NAT va réécrire le champs source du message par son IP et son port généré de telle sorte que le serveur voie le message en provenance de 88.222.222.222:7771.

Tuple ajouté à la table de la NAT :

Code:

---

7771 -> 192.168.0.11:5550

---

Voici donc la table de la NAT :

Code:

---

1 2	7770 -> 192.168.0.10:5550 7771 -> 192.168.0.11:5550

---

Le serveur a reçu deux messages en provenance de la même IP, mais de deux port différents. (88.222.222.222:7770 et 88.222.222.222:7771). Il peux donc répondre à l'un comme à l'autre sans que ces messages soit mélangés. Il répond donc aux deux clients.

La NAT, toujours entre les deux, reçois donc deux messages : l'un sur son port 7770 et l'autre sur son port 7771.

Elle regarde sa table :

Code:

---

1 2	7770 -> 192.168.0.10:5550 7771 -> 192.168.0.11:5550

---

... et sais que le message reçu sur le port 7770 doit être acheminé vers 192.168.0.10:5550 et l'autre vers 192.168.0.11:5550.

Il n'y a donc pas de problème à avoir deux machines derrière une même NAT qui se connecte au même serveur, sur le même port.

C1 et C2 sont sur la même machine

C'est typiquement ce qu'il se produit lorsqu'on ouvre deux navigateurs et qu'on les connecte au même site.

Dans ce cas, la NAT fonctionne toujours de la même manière et le système, qui attribut les ports automatiquement, fonctionne également de la même manière. Seulement, lorsqu'un programme client demande l'ouverture d'un port au système, ce dernier lui en attribut un nouveau à chaque fois (bien souvent, c'est celui qui est immédiatement après), si bien que si C1 et C2 veulent se connecter au même serveur, le port source sera différent.

Prenons un exemple :

C1 (192.168.0.10) envois un message au serveur (88.111.111.111:1234). Le système génère un numéro de port, par exemple 6660. Le message sort de l'ordinateur avec comme adresse 192.168.0.10:6660.

La NAT fait le même travaille que tout à l'heure, génère par exemple le port 7770, et mémorise dans sa table :

Code:

---

7770 -> 192.168.0.10:6660

---

Ensuite, C2 fait la même chose, le système lui attribut le numéro de port 6661, le message sort de l'ordinateur avec comme adresse 192.168.0.10:6661. C'est la même machine mais pas le même port.

La NAT fait le même travaille que tout à l'heure, génère par exemple le port 7771, et mémorise dans sa table :

Code:

---

7771 -> 192.168.0.10:6661

---

Voici donc le contenu de la table de la NAT :

Code:

---

1 2	7770 -> 192.168.0.10:6660 7771 -> 192.168.0.10:6661

---

Pour le dialogue avec le serveur, c'est exactement la même chose que tout à l'heure, le serveur à affaire à la même IP, mais de deux port différents. (88.222.222.222:7770 et 88.222.222.222:7771). Il peux donc répondre à l'un comme à l'autre sans que ces messages soit mélangés. Il répond donc aux deux clients.

La NAT, toujours entre les deux, reçois donc deux messages : l'un sur son port 7770 et l'autre sur son port 7771.

Elle regarde sa table :

Code:

---

1 2	7770 -> 192.168.0.10:6660 7771 -> 192.168.0.10:6661

---

... et sais que le message reçu sur le port 7770 doit être acheminé vers 192.168.0.10:6660 et l'autre vers 192.168.0.10:6661.

Dans les deux cas, ce sera la même machine qui recevra les deux messages (tout comme c'était la même NAT qui a reçu les deux messages tout à l'heure). C'est ensuite dans le système que les deux messages sont être aiguillé vers le bon programme (C1 ou C2) car lors de la création de leur socket respectif, le système leur a affecté des ports différents (bien que ces programmes soit identique). Ainsi, le programme C1 récupèrera le message qui arrivera sur le port 6660 de la machine tandis que le programme C2 récupèrera le message qui arrivera sur le port 6661 de cette même machine.

Citation:

---

D'accord, c'est bien ce que nous redoutions.

---

Il n'y a rien à redouter. Il n'y a que dans le cas du P2P ou il faut procéder à une "bidouille" : soit effectuer un UDP Hole Punching ou paramétrer la NAT à l'aide d'un protocole spécifique comme UPNP ou STUN. Mais dans le cas d'une communication exclusivement client/serveur, tu n'as rien à faire de particulier, sauf, bien évidement, paramétrer le routeur derrière lequel se situe ton serveur (une seule fois) si tu veux qu'on puisse y accéder depuis l'extérieur.

Excellente explication (même si le post date un peu) !!