Non. Comme le disait le post précédent, une connexion est identifiée par 4 paramètres (en fait 5 : il faut préciser le protocole de niveau transport : TCP ou UDP généralement).
Reprenons l'exemple d'un site Web.
Ton client 1 envoie une requête au serveur Web. Il utilise le port TCP/10521 comme port source.
@IP client 1 : 10521 -> @IP serveur : 80
Le serveur répond, en utilisant comme port source le port 80
@IP serveur : 80 -> @IP client 1 : 10521
Vu qu'on a dit qu'une connexion est identifiée pour le 5-uplet (IP source, IP dest, protocole, port source, port dest), on peut très bien avoir un autre client sur le port 80
@IP client 2 : 12219 -> @IP serveur : 80
Le serveur répond, en utilisant comme port source le port 80
@IP serveur : 80 -> @IP client 2 : 12219
On peut même avoir le port source identique, puisque l'adresse IP des clients est différente.
Pour en revenir à notre serveur de messagerie / calendrier, il est tout à fait possible, en gros, qu'il travaille sur 3 ports : IMAP pour la réception des mails, SMTP pour l'envoi des mails et un port pour la gestion du calendrier (HTTP/Webdav par exemple). Et _tous_ les clients utilisent ces 3 ports uniquement côté serveur.
Après, le problème se pose dans le cas de la translation d'adresse sur un firewall. Lorsqu'on change l'adresse IP source (SNAT avec netfilter), on utilise généralement l'adresse IP publique du firewall. Donc tous les paquets sortent avec les mêmes adresses IP. Si on imagine que toutes les machines du réseau se connectent sur le même serveur Web, on est limité à 65535 - 1024 clients. C'est un cas extrême, mais il faut l'imaginer.
Une solution possible est de natter non pas derrière une adresse IP au niveau du firewall, mais derrière un "pool" d'adresse IP.
[^] # Re: heu ... les ports c pas des u_short ?
Posté par zejames . En réponse au journal Le serveur collaboratif Hula Hula ;-). Évalué à 3.
Reprenons l'exemple d'un site Web.
Ton client 1 envoie une requête au serveur Web. Il utilise le port TCP/10521 comme port source.
@IP client 1 : 10521 -> @IP serveur : 80
Le serveur répond, en utilisant comme port source le port 80
@IP serveur : 80 -> @IP client 1 : 10521
Vu qu'on a dit qu'une connexion est identifiée pour le 5-uplet (IP source, IP dest, protocole, port source, port dest), on peut très bien avoir un autre client sur le port 80
@IP client 2 : 12219 -> @IP serveur : 80
Le serveur répond, en utilisant comme port source le port 80
@IP serveur : 80 -> @IP client 2 : 12219
On peut même avoir le port source identique, puisque l'adresse IP des clients est différente.
Pour en revenir à notre serveur de messagerie / calendrier, il est tout à fait possible, en gros, qu'il travaille sur 3 ports : IMAP pour la réception des mails, SMTP pour l'envoi des mails et un port pour la gestion du calendrier (HTTP/Webdav par exemple). Et _tous_ les clients utilisent ces 3 ports uniquement côté serveur.
Après, le problème se pose dans le cas de la translation d'adresse sur un firewall. Lorsqu'on change l'adresse IP source (SNAT avec netfilter), on utilise généralement l'adresse IP publique du firewall. Donc tous les paquets sortent avec les mêmes adresses IP. Si on imagine que toutes les machines du réseau se connectent sur le même serveur Web, on est limité à 65535 - 1024 clients. C'est un cas extrême, mais il faut l'imaginer.
Une solution possible est de natter non pas derrière une adresse IP au niveau du firewall, mais derrière un "pool" d'adresse IP.