Discussion :

[zephyre]

Bonjour,

Voilà la question que je me pose :
Pour l'instant on ne prends pas en compte internet.
On va dire que l'environnement est le suivant :

1 LAN nommée LA1, adresse du réseau 192.168.1.0/24
2 LAN nommée LA2, adresse du réseau 192.168.0.0/16

Sur LA1 :
Une et une seule machine nommée M1_LA1, adresse 192.168.1.1/24

Sur LA2 :
Une et une seule machine nommée M1_LA2, adresse 192.168.1.1/16

On remarque que la machine M1_LA1 et la machine M1_LA2 ont la même adresse ip.
La seule chose qui les différentie c'est le masque.

Ce que je veux faire, c'est à partir de l'unique machine M1_LA1 pinguer la machine M1_LA2.
Et j'ai fait exprès qu'elles est EXACTEMENT la même adresse ip si on ne prends pas en compte le masque, car ce qui m'a toujours étonné avec la commande ping, c'est qu'on ne précise pas le masque.

On va dire qu'on a une route un routeur ... Bref tout est ok.
Je suis sur la machine M1_LA1 et je veux pinger la machine M1_LA2.
Quelle commande je tape ?

J'ai cherché dans le man linux : https://www.man-linux-magique.net/man8/ping.html
Pour savoir s'il existait un paramètre qui permet de préciser la passerelle/gateway.

Le seul truc qui pourrait y ressemble est ce paramètre :
-I adresse_interface
Fixe l'adresse source à l'adresse de l'interface spécifiée.
L'argument peut être une adresse IP numérique ou le nom d'un
périphérique. Cette option est requise lorsque l'on désire
« pinger » une adresse IPv6 link-local.

A part ça je vois rien.
Mais apparemment ça colle pas car il dise que c'est pour le protocole IPV6.

Je pense que si à partir de M1_LA1 je pingue l'adresse 192.168.1.1, et vu qu'on ne précise pas le masque, cette machine va se pinguer elle même.
Ce qui n'est pas ce que je veux.

Donc comment on fait, vu que la commande ping ne prends pas en compte le masque ?

Cordialement,
Zephyre

[A3gisS3c]

Hello,

On remarque que la machine M1_LA1 et la machine M1_LA2 ont la même adresse ip.
La seule chose qui les différentie c'est le masque.

Je t'invite fortement à ne jamais faire ça.

car ce qui m'a toujours étonné avec la commande ping, c'est qu'on ne précise pas le masque.

Pourquoi diable voudrais-tu qu'on précise un masque avec ping? ping sert à pinguer...un hôte. Si tu cherches à "pinguer un réseau" (en gros tu veux faire de la découverte) -> https://linux.die.net/man/1/nmap
Et sur un routeur intermédiaire (au hasard une appliance firewall) tu fais comment pour définir ton routage si les deux hôtes ont la même IP dans deux réseaux différents?

Je pense que si à partir de M1_LA1 je pingue l'adresse 192.168.1.1, et vu qu'on ne précise pas le masque, cette machine va se pinguer elle même.
Ce qui n'est pas ce que je veux.

ce n'est pas une commande (via un paramètre de ping) qui définit par ou passer, ce sont les tables de routage.
Ca doit possiblement être jouable avec un override de ta table de routage locale (et non ta table de routage courante) + un PBR de l'espace dans une table de routage prioritaire mais sérieusement oublie ton histoire de machines avec les mêmes IP.

Personne n'a jamais fait ça, personne ne fait ça et personne ne fera jamais ça.

[sevyc64]

1 LAN nommée LA1, adresse du réseau 192.168.1.0/24
2 LAN nommée LA2, adresse du réseau 192.168.0.0/16

Pas de problème s'il s'agit de réseaux indépendants.
Par contre s'ils sont interconnectés, LA1 est un sous-réseau de LA2, donc toutes les machines de LA1 sont aussi, de fait, des machines de LA2

On remarque que la machine M1_LA1 et la machine M1_LA2 ont la même adresse ip.

Gros problème ici, puisque LA1 étant un sous-réseau de LA2, M1_LA1 est de fait une machine de LA2.
Donc si 2 machines de LA2 ont la même adresse IP, il y a conflit d'adresse. Au mieux, une ou les 2 machines ne fonctionneront pas. Au pire tu auras de grosse perturbations sur ton réseau. A moins que tu ais un équipement (routeur, switch, ...) intelligent qui blackliste simplement les 2 machines.

Je suis sur la machine M1_LA1 et je veux pinger la machine M1_LA2.

Çà ne marchera pas. M1_LA1 se pingera elle-même. Comme tu indique sa propre adresse ip, la carte réseau de M1_LA1 va transformer cette adresse en 127.0.0.1. Normalement la commande ne sortira même pas sur le réseau, elle rebouclera dans la carte elle-même. Si ça marche, car il n'est pas rare que ce genre de situation soit filtré par les interfaces, justement.

Ping n'a pas besoin de masque. Il adresse une adresse IP. Si cette adresse fait partie du réseau local de la carte, déterminé par le masque qui lui a été attribué, la commande est envoyée directement sur le réseau, à l'adresse indiquée.
Si l'adresse ne fait pas partie du réseau local, la commande est envoyée à la passerelle (routeur), en charge à celle-ci de la router vers le réseau suivant pour atteindre la destination, ou la mettre à la poubelle s'il s'agit, comme ici, d'une adresse non routable et que la passerelle n'a pas reçu une configuration spécifique pour router ces adresses-là.

[zephyre]

Pourquoi diable voudrais-tu qu'on précise un masque avec ping? ping sert à pinguer...un hôte. Si tu cherches à "pinguer un réseau" (en gros tu veux faire de la découverte) -> https://linux.die.net/man/1/nmap
Et sur un routeur intermédiaire (au hasard une appliance firewall) tu fais comment pour définir ton routage si les deux hôtes ont la même IP dans deux réseaux différents?

Bas justement, je veux pinguer un HÔTE mais sur un réseaux différent.
Bas justement, dans la table de routage il y a le masque ! Donc même si les deux hôtes ont la même IP mais diffère par le masque, ça ne devrait pas poser de problème.
Et je suis sûr que ça arrive plus souvent que tu ne crois !
Je te donne un exemple :
On a un LAN1, adresse réseaux = 192.168.1.0/24
On a un LAN2, adresse réseaux = 192.168.0.0/16
On a un Routeur qui relie LAN1 et LAN2.
Comme on va pas "se faire chier" à mettre manuellement une IP à la main pour chaque machine normalement c'est géré par le protocole DHCP.
Donc si t'as atteint le nombre max de machine que tu peux mettre sur LAN1 et le nombre max de machine que tu peux mettre sur LAN2 => c'est obligé que au moins une machine de LAN1 et une autre machine de LAN2 ai la même IP, et ne se distingue que par la masque.
Et si ce que tu dis est vrai ça veut dire que ces machines (qui ont la même IP, seul le masque les distingue), ne peuvent pas communiquer entre elles => ABSURDE.
Donc c'est obligé que le masque soit écrit ou donné quelque part dans les couches du modèle TCP/IP.
Je sais pas ou, mais c'est obligé qu'il soit écrit quelque part.

ce n'est pas une commande (via un paramètre de ping) qui définit par ou passer, ce sont les tables de routage.
Ca doit possiblement être jouable avec un override de ta table de routage locale (et non ta table de routage courante) + un PBR de l'espace dans une table de routage prioritaire mais sérieusement oublie ton histoire de machines avec les mêmes IP.

Bon la tabouret tu me parles chinois, je sais pas ce que c'est la table de routage locale ni la table de routage courante et encore moins un PBR.
A mon avis tu fais fausse route.
Dans n'importe quelle table de routage y a TOUJOURS un masque que l'on précise !
Et de plus dans la table de routage il y aura une ip de l'interface/passerelle/gateway dans la table de routage dans LAN1 et dans LAN2 au minimum.
Ce qui fait 2 adresse ip au minium pur la passerelle/gateway/interface, une coté LAN1 et une coté LAN2.

Mais même là je ne comprends pas comment ça peut fonctionner !
Je m'explique :
Environnement toujours pareil un LAN1 et un LAN2 et un routeur entre les deux.
Machine 1 de LAN1 nommée M1_LAN1, adresse ip = 192.168.1.1/24
Machine 2 de LAN2 nommée M1_LAN2, adresse ip = 192.168.1.1/16

De ce que j'ai compris voilà comment ça fonctionne :
Initialement on est sur LAN1.
Il y a une liste d'adresse de toutes les ip sur le réseau LAN1 (je sais pas ou mais quelque part).
Le protocole, parcourt cette liste d'adresse ip :
- s'il la trouve il envoie le paquet à cette adresse ip
- s'il ne la trouve pas il l'envoie à sa passerelle par défaut

Ainsi c'est obligé qu'on précise le MASQUE dans ce procédé, quelque part, je sais pas ou, mais quelque part.
Sinon,
Tu pourras jamais joindre M2 à partir de M1 c'est IMPOSSIBLE !

Ou alors, tu lui précise l'interface/passerelle/gateway par ou il doit passer.
Mais dans ce cas là ce n'est pas possible non plus, car elle suggère à chaque fois une intervention manuelle, précision de l'interface/gateway/passerelle.
Surtout si on a plusieurs LAN.

Donc il en reste qu'une !

C'est obligé que ce putain de masque soit écrit quelque part !

Donc moi je vais partir de ce principe le masque est TOUJOURS écrit quelque part !

Gros problème ici, puisque LA1 étant un sous-réseau de LA2, M1_LA1 est de fait une machine de LA2.
Donc si 2 machines de LA2 ont la même adresse IP, il y a conflit d'adresse. Au mieux, une ou les 2 machines ne fonctionneront pas. Au pire tu auras de grosse perturbations sur ton réseau. A moins que tu ais un équipement (routeur, switch, ...) intelligent qui blackliste simplement les 2 machines.

Tant qu'on précise le MASQUE y a pas de problème !
Car même si les machines M1 et M2 ont la même IP elle n'appartiennent pas au même sur-réseau ou sous-réseaux, bref un réseau.
Un sur réseau ou sous réseau, bref, c'est juste un masque variable.
Je crois que le terme anglais exact est variability mask ou dynamic mask ou un truc comme ça.
Et comme je t'ai dit, c'est obligé que le MASQUE soit écrit quelque part dans une couche ou tu veux je m'en fou mais quelque part.

En toute logique sevyc64,
Si tu reconnais que ça pose un problème lorsque LAN1 et LAN2 pour reprendre ton terme, sont interconnecté (sous-réseau, sur-réseau, bref un réseau) tu devrais également reconnaitre que cela pose un problème également lorsque les réseaux LAN1 et LAN2 sont indépendants !

Car dans un cas comme dans l'autre la seule information qu'il nous manque c'est ce putain de MASQUE !

Et moi je te dis c'est obligé que le MASQUE soit écrit quelque part.

Sinon y a rien qui fonctionne que dalle !

Et personnellement c'est pour ça que j'ai toujours été étonné qu'avec la commande ping on ne précise pas le masque de l'IP.

Moi je pense plus qu'ils ont fait ça par sécurité.
Car si tout est relié à tout et comme tu sais pas comment c'est maillé en théorie tu pourrais pinguer n'importe quelles machines en rentrant un masque au pif et en bidouillant ta table de routage.
En supposant que les ports sont ouverts et que tu n'es pas de firewall ou une protection quelconque, exemple login mot de passe, ou certificat ou ce que tu veux.

Mais en théorie, le développement d'un tel outil est possible.

En 3 phrases :
Avant de pouvoir joindre n'importe quel hôte, il faut déjà joindre le réseau impérativement/obligatoirement.
Si tu ne peux pas joindre le réseau => tu ne peux pas joindre l'hôte de ce réseau.
Et qui dit joindre un réseau, dit adresse de réseau, dit MASQUE.

[Delias]

Tu n'as toujours pas compris.

Un équipement raccordé à un réseau IP (ordi, imprimante, IoT, etc.) n'est défini (adressable) que par son adresse.
Le masque de sous-réseau ne sert qu'à l'équipement en question (là où il est indiqué), pour savoir s'il peut appeler une autre adresse directement (même sous-réseau) ou s'il doit le faire indirectement via la passerelle (hors du sous-réseau), qui est généralement un routeur.

sevyc a parfaitement raison.

[zephyre]

Tu n'as toujours pas compris.

Ok, je veux bien je ne demande qu'a apprendre.
On va donc supposer qu'on a pas le MASQUE.
Environnement rien de plus simple :
Un LAN1 et un LAN2 reliés par un routeur.
Une machine sur LAN1 nommé M1_LAN1 et une machine sur LAN2 nommé M1_LAN2.
M1_LAN1 et M1_LAN2 ont exactement la même adresse IP, et ne diffère que par le MASQUE.
Explique moi, comment M1_LAN1 joint M1_LAN2 sachant que sevyc à dit que ça ne posait pas de problème !
Je veux bien.
Explique moi comment tu fais sans connaitre le masque ?
C'est à dire en émettant l'hypothèse que le masque est écrit nul part ni dans aucune couche ni rien, nulle part.
Va s'y explique moi stp ?

Je te dis tu va consulter ta table d'adresse ip et tu va boucler sur toit même dés lors que tu ne lui précise pas le masque ou la route, ip de l'interface/gateway/passerelle d'une quelconque façon que ce soit.
Sinon je t'en prie explique moi comment tu fais ?

Autrement dit si sevyc reconnait que dans ce cas (réseau indépendant) ça ne pose pas de problème en tout logique il devrait reconnaitre également qu'avec les sur-réseau, sous réseau, bref ce qu'il nomme pour reprendre son terme, interconnecté, ça ne pose pas de problème.
Soit ça pose un problème dans les 2 cas (réseau indépendant + réseau interconnecté).
Soit ça pose pas de problème dans les 2 cas (réseau indépendant + réseau interconnecté).

Mais,
Il ne peux pas dire, dans un cas c'est ok et dans l'autre cas c'est ko, ça c'est pas possible d'un point de vue de la raison.

Tu sais pourquoi ?
Car d'un point de vue logique au sens informatique du terme c'est exactement le même principe !

Le masque de sous-réseau ne sert qu'à l'équipement en question (là où il est indiqué), pour savoir s'il peut appeler une autre adresse directement (même sous-réseau) ou s'il doit le faire indirectement via la passerelle (hors du sous-réseau), qui est généralement un routeur.

Dans un réseau interconnecté (sur-réseau ou sous réseau, bref un réseau) y a pas de routeur, de machine physique, dans cette configuration.
Le sous réseau ou sur réseau ici est une définition logique et NON physique.

[sevyc64]

On a un LAN1, adresse réseaux = 192.168.1.0/24
On a un LAN2, adresse réseaux = 192.168.0.0/16
On a un Routeur qui relie LAN1 et LAN2.

S'il y a un routeur entre les 2, les 2 réseaux sont isolés l'un de l'autre et n’interféreront l'un sur l'autre.

Et si ce que tu dis est vrai ça veut dire que ces machines (qui ont la même IP, seul le masque les distingue), ne peuvent pas communiquer entre elles => ABSURDE.

Non, elles ne peuvent pas communiquer entre-elles dans la plupart des cas.
Une machine de LAN1 ne pourra pas communiquer avec une machine de LAN2 qui aura son adresse en 192.168.1.x, car elle contactera en réalité la machine de LAN1 qui aura la même adresse (que cette machine existe réellement ou pas).
Une machine de LAN1 pourra communiquer avec une machine de LAN2 qui est en 192.168.y.x, à condition que y<>1 et que le routeur possède une règle de routage qui lui dit de rediriger ces requêtes provenant de LAN1, vers LAN2. Mais il faut une règle explicite car ces adresses étant à la base, des adresses non routables, s'il ni a pas de règle explicite de renseignée dans le routeur, la requête est simplement ignorée et tombe dans les oubliettes (même un routeur qui est configuré pour router les adresses inconnues de tous ses réseaux, vers une adresse spécifique de passerelle ne routera pas ces adresses non routables s'il n'a pas une règle explicite pour le faire).

Une machine de LAN2 ne pourra pas contacter une machine de LAN1 car elle contactera en réalité la machine de LAN2 qui aura la même adresse (que cette machine existe réellement ou pas).
Pour LAN2, le réseau LAN1 n'existe tout simplement pas car masqué par la partie correspondante de son propre réseau local.

Donc c'est obligé que le masque soit écrit ou donné quelque part dans les couches du modèle TCP/IP.

Le masque n'est renseigné que dans la configuration de l'interface. Il ne rentre pas en compte dans les échanges, il sert juste à l'interface à déterminer si l'adresse de fait partie du réseau local ou pas.
Si la destination fait partie du réseau local, l'interface envoie la requête directement à la machine. Si la destination ne fait pas partie du réseau local, l'interface envoie la requête à la passerelle/routeur pour que celui-ci fasse la fasse passer à un autre réseau extérieur, qui peut être le réseau de destination, ou pas !

De ce que j'ai compris voilà comment ça fonctionne :
Initialement on est sur LAN1.
Il y a une liste d'adresse de toutes les ip sur le réseau LAN1 (je sais pas ou mais quelque part).
Le protocole, parcourt cette liste d'adresse ip :
- s'il la trouve il envoie le paquet à cette adresse ip
- s'il ne la trouve pas il l'envoie à sa passerelle par défaut

Non, il n'y a pas de liste.
Ta machine de LAN1, elle sait qu'elle est sur le réseau 192.168.1.x par le masque qui est configuré dans sa configuration.
Donc elle ne va pas se poser de question. Toute requête à destination d'une adresse qui commence par 192.168.1, elle va l'adresser directement à cette adresse-là, sur son réseau local, qu'il y ait ou pas une machine à l'autre bout.
Toute requête qui ne commence pas par 192.168.1 sera adressée, sans autre réflexion, à la passerelle. Rien de plus.

Idem pour une machine de LAN2. Pour une requête à destination d'une adresse en 192.168, elle partira directement sur le réseau local. Donc une requête pour une adresse en 192.168.1 ne partira jamais vers le LAN1.



Il faut juste que tu enregistre une chose, le masque n'est pas transmis lors d'une requête TCP/IP. Le masque est juste une information de configuration dans le cas d'une interface réseau, ou un moyen d'indiquer la plage d'adresse concernée dans la configuration d'une route.
Le seul moment ou un masque peut circuler dans une requête TCP/IP, c'est la réponse à une requête DCHP, et encore, ça fait partie des options donc ce n'est pas systématique.

[A3gisS3c]

Y'a de grosses lacunes en réseau je vois.

En fait j'ai compris. Tu penses qu'une machine est adressable par le couple IP/Masque, c'est ça ton erreur.

Alors que non une machine n'est adressable que par son IP. Le masque n'est la que pour la gestion du routage des paquets.

[zephyre]

Oui je reconnais avoir de grosse lacune en réseau.
Mais c'est pas pour cela que ça doit m'empêcher de progresser et surtout de travailler primo.

Donc je reprends la configuration :
On a un LAN1, adresse réseaux = 192.168.1.0/24
On a un LAN2, adresse réseaux = 192.168.0.0/16
Machine 1 de LAN1 nommée M1_LAN1, adresse ip = 192.168.1.1/24
Machine 2 de LAN2 nommée M1_LAN2, adresse ip = 192.168.1.1/16
On a un Routeur qui relie LAN1 et LAN2.

S'il y a un routeur entre les 2, les 2 réseaux sont isolés l'un de l'autre et n’interféreront l'un sur l'autre.

Ok, vous voulez dire que ça foutra pas la merde au niveau de chaque LAN, LAN1 et LAN2 par ce qu'ils sont indépendants ?
Ce qui n'est pas sûr si on est en réseaux interconnectés (sûr sous réseaux) pour reprendre votre terme ?

Mais dans les 2 cas :
C'est PAS possible (M1_LAN1 joint M1_LAN2), on est d'accords ? Oui / Non => pour moi c'est NON mais je demande confirmation.

Y a un truc que je ne comprends toujours pas au niveau du MASQUE.
Vous me dites le MASQUE n'intervient que au moment du routage.

Un routage c'est quand on sort de son réseau LAN local => le MASQUE intervient.
Mais alors dans ce cas :
La machine/hôte ne peut pas distinguer un ipV4 = 192.168.1.1/24 d'une autre ipV4 192.168.1.1/16.
Elle peut pas on est d'accords ? Oui / Non
Vu que la machine/hôte ne raisonne qu'en terme d'ip et ne prends pas en compte le masque.

Admettons ce cas de figure :
On a un M1 de LAN1, ipV4 = 192.168.1.1/24 et une M1 de LAN2, ipV4 = 192.168.1.1/16
LAN1 et LAN2 sont indépendants.
Comment M1 de LAN1 fait pour joindre M1 de LAN2 ?
Sinon ça veut dire que les ip, sans prendre en compte le MASQUE de LAN1 et LAN2 doivent toutes être différentes.
Ce qui élimine beaucoup de possibilité d'ip car il y aura des conflits.

Un ipV4 est codé sur 4 octets = 4 x 8 = 32 bits.
Il me faut au moins un bit pour l'host id sinon ça n'a pas de sens (faire un réseau sans mettre aucune machine dessus
avec une et une seule ip dessus si touts les bits de l'host id sont à 0 = adresse du réseau).
Si touts les bits de l'host id sont à 1 = adresse de brodcast.
Donc il me faut au moins 2 bits pour mettre au moins une machine dessus.
Soit 2^30 réseaux possibles.
Mais vu qu'on ne prends pas en compte le MASQUE => PLUS ON DECOUPE EN RESEAUX ET MOINS ON A D'ADDRESSE IP POSSIBLE.

On va prendre un exemple concret :
LAN1, adresse de réseau 192.168.1.0/24 => 8 bits pour l'ip - 2 (adresse de réseau + brodcast) = 2^8 - 2 = 254 ip possibles.
LAN2, adresse de réseau 192.168.0.0/16 => 16 bits pour l'ip - 2 (adresse de réseau + brodcast) = 2^16 - 2 = 65 534 ip possibles.
Maintenant on élimine les IP communes entre LAN1 et LAN2 au max il faut retirer au max 65534 - 256 = 65 278 ip possibles pour LAN2.
J'ai tout bon ? Oui / Non.
Et le protocole DHCP vérifie tout ça automatiquement ?

J'ai une question qui peut paraitre bête mais je la pose quand même.
LAN1 adresse réseau 192.168.1.0/24
LAN2 adresse réseau 192.168.1.0/24
ça c'est pas possible on est d'accords ? Oui / Non

Une dernière question sur le port :
Le port est une notion logique qui permet de faire du multiplexage d'adresse ip.
Sans le port => Une et une seule ip peut se connecter en même temps à un hôte.
Dans un modèle client/serveur.
Il il a un port coté serveur exemple 80 pour les serveurs web.
Et on identifie chaque utilisateur avec un port entrant sur le client pour savoir qui est qui.
Un port est codé sur 2 octets = 2 ^16 = 65 536.
Ca veut dire qu'il y a max 65 536 utilisateurs qui peuvent consulter la même page web en même temps ?

Merci pour votre aide.

[A3gisS3c]

Oui je reconnais avoir de grosse lacune en réseau.
Mais c'est pas pour cela que ça doit m'empêcher de progresser et surtout de travailler primo.

Exactement et ce forum est fait pour t'aider on est tous passés par là.

On a un Routeur qui relie LAN1 et LAN2.

Tu auras des problèmes crois-moi si deux machines ont la même IP avec un routeur qui les interconnecte.

C'est PAS possible (M1_LAN1 joint M1_LAN2), on est d'accords ? Oui / Non => pour moi c'est NON mais je demande confirmation.

Réponse courte, non en effet.

La machine/hôte ne peut pas distinguer un ipV4 = 192.168.1.1/24 d'une autre ipV4 192.168.1.1/16.

Ta machine ne distingue rien, elle ne fait qu'obéir aux règles de routage (dont ta table de routage locale -> ip route show table local, mais n'y accorde pas d'importance tu vas t'embrouiller plus qu'autre chose)

Et le protocole DHCP vérifie tout ça automatiquement ?

Le protocole DHCP vérifie queudal, il ne fait qu'attribuer une IP sur un LAN si tu le demande.

Une dernière question sur le port :
Le port est une notion logique qui permet de faire du multiplexage d'adresse ip.
Sans le port => Une et une seule ip peut se connecter en même temps à un hôte.
Dans un modèle client/serveur.
Il il a un port coté serveur exemple 80 pour les serveurs web.
Et on identifie chaque utilisateur avec un port entrant sur le client pour savoir qui est qui.
Un port est codé sur 2 octets = 2 ^16 = 65 536.
Ca veut dire qu'il y a max 65 536 utilisateurs qui peuvent consulter la même page web en même temps ?

Le port ne permet pas de faire du multiplexage d'IP. Le port est un paramètre de couche transport (couche 4 OSI - TCP), IP un protocole de couche réseau (OSI 3)
Le port te permet de distinguer des applications en écoute sur une IP donnée (les puristes désolé )

Chaque utilisateur n'est pas défini par son port, d'ailleurs deux utilisateurs attaquants le port 80 d'un serveur web peuvent avoir le même port source, mais pas la même IP evidemment.

Des millions de gens peuvent consulter ta page web simultannement (bon t'as interet d'être sur AWS avec un auto-scaling de l'espace et un porte monnaie conséquent).

[Christophe]

Le port ne permet pas de faire du multiplexage d'IP.

Sauf chez free, mais c'est pas le sujet
@zephyre ne tient pas compte de cette remarque qui va t'embrouiller, c'est une vanne d'informaticien.

[A3gisS3c]

Sauf chez free, mais c'est pas le sujet

Punaise!! Tu viens de m'apprendre un truc je ne savais pas j'ai été regarder l'info par curiosité du coup.
je plains les pauvres 3 mecs restants qui se tapent les ports 16384 -> 65535 ils ont du en bouffer du DNAT (port forwarding pour les puristes) sur leur box pour que tout fonctionne.

[sevyc64]

Sauf chez free, mais c'est pas le sujet

C'est pas limité à Free, et ça va se généraliser de pus en plus en ipv4

Punaise!! Tu viens de m'apprendre un truc je ne savais pas j'ai été regarder l'info par curiosité du coup.
je plains les pauvres 3 mecs restants qui se tapent les ports 16384 -> 65535 ils ont du en bouffer du DNAT (port forwarding pour les puristes) sur leur box pour que tout fonctionne.

JE confirme. Je suis dans la dernière tranche.
Là ou c'est plus gênant ce qu'au départ, Free ne le faisait que sur l'IPv4, désormais ils le font aussi sur l'IPv6 alors que ça ne se justifie pas (j'ai pas vérifié depuis que je suis avec la fibre).
D'un autre coté, ça fait une sorte de pare-feu naturel, les ports les plus couramment attaqués se situant plutôt plus dans la première tranche.

[Ti-Slackeux]

Punaise!! Tu viens de m'apprendre un truc je ne savais pas j'ai été regarder l'info par curiosité du coup.
je plains les pauvres 3 mecs restants qui se tapent les ports 16384 -> 65535 ils ont du en bouffer du DNAT (port forwarding pour les puristes) sur leur box pour que tout fonctionne.

Bonsoir,

On peut demander une IP V4 full stack chez Free quand on a un serveur.

hth,

[sevyc64]

Un temps c'était possible mais pas pour tout le monde. Il faut vérifier sur son compte abonné si le lien existe

[zephyre]

Ta machine ne distingue rien, elle ne fait qu'obéir aux règles de routage (dont ta table de routage locale -> ip route show table local, mais n'y accorde pas d'importance tu vas t'embrouiller plus qu'autre chose)

Mais c'est ça que je comprends pas putain de merde !
Dans un table de routage quand tu tapes une commande powershell ou linux pour afficher la table de routage => Y A LE MASQUE !
Donc quand on veut sortir de son LAN local on est bien obligé de prendre en compte la MASQUE à un moment donné ou à un autre.
Sinon on ne s'est même pas dans quel réseau (adresse réseau = adresse ip de destination ET MASQUE, le tout bit à bit).
Donc tu te démerdes comme tu veux dans une couche à un moment donnée dans certaines conditions tu prends en compte ce putain de MASQUE.
Et c'est NORMAL !
Faut bien pouvoir pinguer l'adresse du réseau avant de pouvoir pinguer l'adresse de l'hôte;
car l'hôte est dans un réseau.
Je résume :
Si tu ping l'hâte appartenant à un réseau => FORCEMENT tu pinges l'adresse réseau, le réseau de l'hôte.
Et pour connaitre l'adresse d'un réseau t'es obligé à un moment donné ou à un autre dans une couche, ou tu veux, dans certaines conditions, de prendre en compte le MASQUE, si tu veux sortir de ton réseau local LAN.

Le port ne permet pas de faire du multiplexage d'IP. Le port est un paramètre de couche transport (couche 4 OSI - TCP), IP un protocole de couche réseau (OSI 3)
Le port te permet de distinguer des applications en écoute sur une IP donnée (les puristes désolé ).

Je suis désolé mais là je ne suis absolument pas d'accords avec toi.
Le port permet de faire du multiplexage logique.
Le port appartient à la couche 4, transport.
L'ip appartient à la couche 3, réseau.
Le tout dans le protocole TCP/IP.

L'ip est une notion logique de même que le port mais il y a un ordre à respecter dans les couches, on rajoute des trucs logiques (couche n) sûr des trucs logique (couche n-1).
Si tu n'avais pas de port qu'es ce qui se passerait ?
C'est simple, une et une seul ip ne pourrait joindre qu'une et une seul autre ip, A LA FOIS, sûr la même connexion réseau.
C'est à dire qu'il te serais impossible d'avoir plusieurs ip sur la même connexion réseau
Tu peux avoir plusieurs ip sur la même connexion réseau justement grâce au port.
Et comment tu distingues sûr une même connexion réseau, dans un modèle client/serveur.
Avec un port coté client, qui s'appelle le port sortant.
Et un port coté serveur, qui s'appelle le port entrant.
Et ceci même si tu as la même IP dans ton réseau local LAN ou réseau particulier qu'un autre, sûr la même connexion réseau, on s'en branle.
Donc c'est ça l'idée majeur du port, c'est à dire le multiplexage.

Je te joins la page 41 du livre le MACMILLAN qui l'explique très bien.
Tu vois t'es pas le seul à être un puriste.

Chaque utilisateur n'est pas défini par son port, d'ailleurs deux utilisateurs attaquants le port 80 d'un serveur web peuvent avoir le même port source, mais pas la même IP évidemment.

Un utilisateur est définit par cela dans un modèle client/serveur : port entrant + ip + port sortant
Il faut qu'll y en ai au moins un sur les trois qui soit différent pour identifier l'utilisateur sinon on peut pas.

Des millions de gens peuvent consulter ta page web simultannement (bon t'as interet d'être sur AWS avec un auto-scaling de l'espace et un porte monnaie conséquent)

Un utilisateur est définit par cela dans un modèle client/serveur : port entrant + ip + port sortant
Le port entrant (coté serveur) est fixe, il ne bouge pas, sinon on ne sait pas quoi interroger au niveau du serveur, par exemple 80 pour une page web.
Pour savoir combien au total d'utilisateur peuvent consulter une page web en même temps sachant que le port sortant est codé sur 2 octets = 65 535 et que le port entrant est fixe = 80 (par exemple).
Donc ça fait, exemple avec le port 80 (page web) : nombre_ip_possible x nombre_possible_de_port_sortant_coté_client = nombre_ip_possible x 65 535.
Généralement le réseau LAN classique chez un particulier est 192.168.1.0 => 1 octet pour l'host ID => 256 - 2 (on retire l'adresse réseau et l'adresse brodcast) = 254 possibilités.
Et encore il faudrait en retirer encore au moins une pour l'adresse de la passerelle. Donc on va dire 253.
Ce qui nous fait : 253 X 65 535 = environs 16 millions 500 mille personnes pour une page web max à conditions qu'ils aient tous des ip distinctes (pas le pire cas).
Cette solution en pratique n'est pas fiable et n'est pas une bonne estimation.
Pourquoi ?
Car beaucoup de gens ont la même ip exemple 192.168.1.1 dans un réseau local LAN1 classique pour un particulier et un autre réseau local LAN2 pour un autre particulier etc etc.
Donc le pire cas c'est bien 65 535 utilisateur en même temps sur une et une seule page web, à partir de ce nombre faut commencer à s'inquiéter => ça peut foutre la merde.
La seule et unique solution pour être peinard chez AWS c'est de rajouter des couches d'abstraction ou logique par dessus.
Bref la même idée que le port.
Sinon c'est pas possible.
Et non même là c'est passible car la couche n dépends de la couche n-1 dans le protocole TCP/IP.
Donc même si tu rajoutes des couches c'est la même merde.
ça bloquera à un moment donné ou à un autre au niveau de la couche 3 (réseau) + couche 4 (transport) dans le TCP/IP.
Et si ça merde à ce niveau là tu peux rajouter tout ce que tu veux tu ne résous pas le problème.
Tu peux pas en pratique avoir des millions d'utilisateurs sur une seule page web => risque trop important de foutre la merde.
En tout cas pas en ipV4.

Ou alors faut que tu m'expliques par ce que là, je comprends rien.

[Christophe]

Je suis désolé mais là je ne suis absolument pas d'accords avec toi.
Le port permet de faire du multiplexage logique.

Le port permet de faire du multiplexage logique avec du NAT. Et pour ça tu as une table de correspondance entre IP LAN:port et IP WAN:port.
Ca ne peut fonctionner qu'avec 2 réseaux IP différents

Avec le NAT, la station qui accède à une machine ne voit pas l'ip de celle-ci mais l'ip de ta BOX (ou ton routeur supportant le NAT). schématiquement, quand ta box reçoit une connexion extérieure sur un port sur lequel il y a du NAT, elle va changer dans le paquet l'adresse et le port de destination et router le paquet vers la machine interne.

Généralement le réseau LAN classique chez un particulier est 192.168.1.0

Non, ce n'est pas une généralité, les BOX SFR par exemple utilisaient un réseau en 192.168.0.0, je crois que ce n'est plus le cas.

Tu peux prendre n'importe quel réseau entre 192.168.0.0 et 192.168.255.255, entre 172.16.0.0 et 172.31.255.255, et entre 10.0.0.0 et 10.255.255.255, ces adresses étant réservées pour un usage en réseau local.

De là ton masque de sous-réseau permettra de définir le nombre de bits réservés au réseau et le reste pour les hôtes en gardant une adresse pour l'adresse du réesau et une adresse pour l'adresse de broadcast, ceci définissant le nombre de machines possible sur le réseau.

2 machines ne peuvent pas avoir la même adresse IP sur le même réseau et 2 machines sur un réseau différents ne pourront pas communiquer sans routage.

Et pour répondre à la question posée :

Comment pinguer un machine ayant la même adresse ipv4 vu qu'avec la commande ping on ne précise pas le masque?

ping n'a pas besoin de connaitre le masque, celui-ci étant connu par ton OS par le biais de sa configuration. ping n'a même pas besoin de connaitre l'adresse ip si tu lui fourni une entrée DNS, une résolution DNS sera dans ce cas effectuée.

[A3gisS3c]

Hello,

Reprenons.

Le masque est prit en compte pour une décision locale de routage. Si tu veux le cheminement complet d'un paquet réseau sous Linux, check ce lien (mais bon...il va t'embrouiller je le sais d'avance)
https://commons.wikimedia.org/wiki/F...acket-flow.svg

Faut bien pouvoir pinguer l'adresse du réseau avant de pouvoir pinguer l'adresse de l'hôte;

Non. On ping un host (adresse /32) et non un réseau, le réseau (donc le masque) n'est check que lors de la décision de routage du flux ICMP au départ de la machine.
Souviens toi, un hote c'est une IP/32, pas IP/MASK. Le masque n'intervient que pour la décision de routage.

Le port permet de faire du multiplexage logique.

Non. Si tu veux faire du multiplexage, tu prends un démon de type inetd sous Linux. Le port permet de de différencier les applications sur ta machine (les puristes on se détend :p)

Tu peux avoir plusieurs ip sur la même connexion réseau justement grâce au port.

Non. Tu ne pourrais juste avoir qu'une seule application sur chaque host. Ou un démon de l'espace qui multiplexerait tout ça via ce qu'on appelle de l'application control sur un firewall next gen mais oublie ce detail.

Donc c'est ça l'idée majeur du port, c'est à dire le multiplexage.

Non je t'assure que non. Punaise je comprends ta frustration crois moi j'ai eu la même pour comprendre les VLAN :p

Un utilisateur est définit par cela dans un modèle client/serveur : port entrant + ip + port sortant

Un utilisateur n'est défini que par son IP, les ports définissent les applications.

Tu peux pas en pratique avoir des millions d'utilisateurs sur une seule page web => risque trop important de foutre la merde.
En tout cas pas en ipV4.

Faux.
Je peux même te mettre 1 milliards de visiteurs sur une page web en même temps si tu m'en donnes les moyens (AWS/Auto-scaling ou des centaines de serveurs web avec un F5 en cluster) L nombre n'est pas un problème, il faut bien sur qu'ils aient tous une IP différentes (sinon il va y avoir conflit evidemment).

Désolé si ca fout la merde dans ta compréhension mais persévère crois moi ca finira par venir.

EDIT: Ok j'ai compris ton histoire de multiplexage sur ta photo. le mot multiplexage est crois moi sujet à interpretation rigoureusement parlant, raison pour laquelle on ne se comprend pas.
Comme chaque application ouvre une connexion TCP différente des autres, ce n'est pas du multiplexage pour moi.
C'est du multiplexage de couche physique OK, mais pas du multiplexage TCP.

Je viens de m'apercevoir que ton bouquin + la littérature classique sur internet racontent très mal les choses, raison pour laquelle tu es perdu.

[zephyre]

Le port permet de faire du multiplexage logique avec du NAT. Et pour ça tu as une table de correspondance entre IP LAN:port et IP WAN:port.
Ca ne peut fonctionner qu'avec 2 réseaux IP différents

Tu as raison en pratique chrtophe mais en théorie tu as tords.
Je m'explique c'est vrai que dans les cas pratique comme on le rencontre souvent dans le vie courante dans un réseau pour les particuliers tu as une Box = (routeur + NAT + Modem).
Et donc en pratique c'est ce qui se passe, tu as parfaitement raison en pratique.

CONFIGURATION DU RESEAU :
======================================================================================
Mais supposons que tu n'es pas de NAT mais simplement un réseau LAN1, un réseau LAN2, et un réseau LAN3, ET Y A PAS INTERNET.
Un et un LAN fixé est relié à tous les autres par au moins un routeur.
Et ceci pour chaque LAN.
Bref touts les LAN sont relié de partout par des routeur 2 à 2 avec max de combinaisons possibles.
Sur LAN1 t'as une et une seule machine nommée LAN1_M1.
Sur LAN2 t'as une et une seule machine nommée LAN2_M1
Sur LAN3 t'as une et une seule machine nommée LAN3_M1

Les 3 machines, LAN1_M1, LAN2_M2 et LAN3_M3 ont EXACTEMENT LA MEME IP local dans leurs réseaux respectif.
======================================================================================

Si on adopte ton hypothèse : le port permet de faire du multiplexage logique avec du NAT <=> il est impossible de faire du multiplexage logique sans NAT.
Ce qui est évidemment FAUX.
Pourquoi ?
AVEC LA CONFIGURATION RESEAU QUE J'AI FIXEE :
Car ça voudrai dire que LAN1_M1 et LAN2_M2 ne peuvent établir une connexion réseau en même temps sur LAN3_M1 sur un port de LAN3_M1 fixé en même temps.
Alors que en théorie Dieu merci c'est tout à fait possible.
Et on distingue chaque utilisateur avec le port coté client.

Prenons un exemple concret :
LAN1_M1 veut faire une connexion SSH sur LAN3_M1 et LAN2_M1 veut également faire une connexion SSH sur LAN3_M1, LE TOUT EN MEME TEMPS.
Si on suit ce que tu dis alors c'est IMPOSSIBLE.
Ce qui est ABSURDE !
Dieu merci c'est tout à fait possible en théorie et en pratique aussi.

Avec le NAT, la station qui accède à une machine ne voit pas l'ip de celle-ci mais l'ip de ta BOX (ou ton routeur supportant le NAT). schématiquement, quand ta box reçoit une connexion extérieure sur un port sur lequel il y a du NAT, elle va changer dans le paquet l'adresse et le port de destination et router le paquet vers la machine interne.

Oui ça je le sais très bien pourquoi on passe par le NAT c'est très simple à comprendre.
On va fixer les hypothèses :
- Pour repérer/identifier une machine sur internet il faut impérativement qu'elle est une ip dite public, c'est à dire une ip l'identifiant dans le réseau des réseaux, c'est à dire Internet.
- Le nombre ip public est limité

A partir de là t'as 2 options :
La première, la plus intuitive et également la plus catastrophique voir irréalisable en pratique, c'est que à chaque machine au sens large (pc, smartphone, télévision, tablette, objets connectés , ..), bref tout ce que tu veux qui est accès à internet => tu donnes à chacune de ces machines une ip public.
Conséquence : tu bouffes les ip public à la vitesse grand V, sachant qu'elles sont limités
Et donc c'est la merde en pratique.
Donc qu'es ce que tu fais ?
Tu groupe les machines d'un réseau local ou de manière général tu groupes n machines et à ce groupe => tu lui associe une et une seul ip publique.
Le souci majeur c'est comment retrouver la machine qui à émit la requête, le message, ce que tu veux sur internet.
Simple une fois que tu as identifier le réseau vis à vis d'internet, c'est à dire par son ip publique, tu redispatche à l'ip local, puisque cette ip local est unique dans le réseau local.
Il doit donc y avoir une encapsulation quelque part, probablement au niveau du routeur/BOX entre la machine qui émets la requête, le message sur internet (ip publique) et l'ip local de ton réseau.
Sinon tout simplement on ne peut pas retrouver la machine émettrice du message.
Et là tu bouffes beaucoup beaucoup beaucoup moins d'ip publique.
C'est ça l'idée majeur/principale du NAT.

Tu peux prendre n'importe quel réseau entre 192.168.0.0 et 192.168.255.255, entre 172.16.0.0 et 172.31.255.255, et entre 10.0.0.0 et 10.255.255.255, ces adresses étant réservées pour un usage en local.

chrtophe, JE VAIS PAS TE LE DIRE 2 FOIS, SOIT TU PARLES CORRECTEMENT SOIT JE VAIS MEME PAS LIRE LA MERDE QUE T'ECRIT, DES QUE JE VERRAI chrtophe => JE ME CASSE OU JE SAUTE, BREF JE LIS QUE DALLE !

MAINTENANT JE VAIS DEMONTRER QUE Y A UN PUTAIN DE PROBLEME DANS CETTE PHRASE !

Première parti de la phrase (AVANT LA VIRGULE) :
Tu peux prendre n'importe quel réseau entre 192.168.0.0 et 192.168.255.255, entre 172.16.0.0 et 172.31.255.255, et entre 10.0.0.0 et 10.255.255.255,(VIRGULE) => le mot réseau veut dire ici adresse de réseau vu que tu donnes une plage d'adresse juste après l'emploi du mot réseau.

Deuxième parti de la phrase (APRES LA VIRGULES) :
, ces adresses étant réservées pour un usage en réseau local
, ces adresses LESQUELS ? => Les adresses de réseaux vu que ta phrase est continu MEME si y a une virgule !

ALORS QUE,
, ces adresses étant réservées pour un USAGE en réseau local. <=> ces adresses, c'est des adresses d'host ID dans un ou plusieurs réseaux LAN vu que c'est marqué POUR UN USAGE en réseau local.

En résumé ta phrase :
Adresse de réseau ET (sous entendu même si c'est pas écrit) ces adresses sont des adresses d'host ID => CONTRADICTION, c'est impossible.

Non. On ping un host (adresse /32) et non un réseau, le réseau (donc le masque) n'est check que lors de la décision de routage du flux ICMP au départ de la machine.
Souviens toi, un hote c'est une IP/32, pas IP/MASK. Le masque n'intervient que pour la décision de routage.

un hôte c'est une IP/32, pas IP/MASK.
Question :
/32 c'est pas le MASK ? ALORS C'EST QUOI ?
En notation CIDR ip/truc => truc c'est le masque.

Moi je peux te dire que je ping mon réseau local sans problème => je peux pinguer un réseau.

Dans le protocole TCP/IP :
- L'IP appartient à la couche 3 (réseau)
- Le masque appartient à la couche 3 (réseau)
- Le routage appartient à la couche 4 (transport)

Tu me dis le masque est vérifier que lors de la décision de routage.
Admettons :
Donc la machine connait bien le masque avant la décision de routage sinon il ne peut pas le vérifier !
Mais je crois que j'ai compris ce que tu essayes de me dire :
Tu veux dire que même si le masque existe préalablement dans la couche réseau, 3, il n'est pris en compte que au moment de la couche transport, 4.
Mais dans ce cas autant mettre directement le masque dans la couche 4 et pas dans la couche 3 non ?

Non. Si tu veux faire du multiplexage, tu prends un démon de type inetd sous Linux. Le port permet de de différencier les applications sur ta machine (les puristes on se détend :p)

Alors moi de ce que j'ai compris inedt ou xinetd selon les distributions.
C'est le démon qui gère tous les services réseaux, la parti application vis à vis du protocole TCP/IP, mais la on est plus dans le réseau on est dans le système.
Exemple ci dessous avec le service réseau telnet, couche 5 application vis à vis du protocole TCP/IP :
cat /etc/xinetd.d/telnet
service telnet
{
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
server_args = -D options
disable = yes
}

Ici ce qu'il faut regarder en priorité c'est le mot wait.
Quand on dit que le mot wait = non => multiplexage ok
sinon pas de multiplexage.
Mais la on est déjà à la couche 5, application, vis à vis du protocole TCP/IP.

Mais tu peux pas faire de multiplexage au niveau de l'application si avant tu ne fait pas de multiplexage au niveau de la couche 3 réseau.
An sens strict ça veut rien dire multiplexage d'application on parle d'instanciation.
Donc le terme exact est instanciation d'application.

Regarde on va toujours se placer dans le modèle client serveur :
10 clients ils ont tous comme adresses 192.168.1.1/24, ils sont tous chez SFR.
1 et un 1 seul serveur
1 et 1 seule application réseau disons une connexion SSH (port 22 par défaut). SSH vis à vis du protocole TCP/IP appartient à la couche 5 application. Cette application est installé sur tous les clients et le serveur.

Ce qu'on veut faire :
Tous les clients veulent se connecter au serveur via une connexion réseau SSH sur le même port entrant, le port 22 du serveur, EN MEME TEMPS !

On va faire deux hypothèse :
Y a pas de multiplexage d'IP au niveau de la couche 3 réseau.
tu peux faire plusieurs instanciations/multiplexage de l'application SSH au niveau du serveur.


Questions :
Comment tu identifies qui est qui au niveau des clients vis à vis du réseau ?
Réponse :
IMPOSSIBLE !
Toi du dis que le multiplexage intervient à la couche 5, application.
Moi je dis le multiplexage intervient à la couche 3, réseau.

Tu peux avoir plusieurs ip sur la même connexion réseau justement grâce au port.

Non. Tu ne pourrais juste avoir qu'une seule application sur chaque host

Je vais corriger :
Tu peux avoir plusieurs fois la même ip venant d'un réseau local LAN quelconque justement grâce au port.

La preuve est assez évidente :
On va prendre une configuration simple :
Toujours dans un modèle client serveur :
1 et 1 seul client
1 et 1 seul serveur

Ce que je veux faire :
A partir de cet unique poste client je veux faire plusieurs connexion SSH sur le serveur.
J'ai donc exactement la même ip.
Et ça marche !
Pourquoi car je peux faire du multiplexage d'ip grâce au port sortant, coté client et je passe exactement par le même chemin (routage).
Et je fais un truc sur la première connexion SSH et un truc différent sur la seconde connexion SSH sans problème.
Et le seul chose qui les différentie, c'est le port sortant, coté client.

Un utilisateur n'est défini que par son IP, les ports définissent les applications.

Le port appartient à la couche 3 réseau.
L'application appartient à la couche 5 application.
C'est facile à démontrer :
Suppose que le port n'appartient qu'à l'application, et ton application ne dépends pas du réseau.
Par contre ton application est accessible via le RESEAU !
Donc si y a pas de multiplexage au niveau de l'ip, ce que permet le port, on est toujours dans la couche 3 réseau, et que les utilisateurs ont la même ip dans leur réseau LAN respectif => T'es dans la merde !
Pourquoi ?
Car t'es dans l'impossibilité d'identifier qui est qui vis à vis du réseau.
Et donc tu ne pourrais pas avoir 2 connexion SSH à partir du même client sur le serveur.

EDIT: Ok j'ai compris ton histoire de multiplexage sur ta photo. le mot multiplexage est crois moi sujet à interpretation rigoureusement parlant, raison pour laquelle on ne se comprend pas.
Comme chaque application ouvre une connexion TCP différente des autres, ce n'est pas du multiplexage pour moi.
C'est du multiplexage de couche physique OK, mais pas du multiplexage TCP.

Oui j'ai compris ce que tu veux dire :
Une connexion réseau = port entrant + ip + port sortant.
Dés qu'on à au moins un de ses éléments qui diffèrent => nouvelle connexion TCP => pas de multiplexage au niveau logique, couche 3 réseau.
Donc tu as raison :
C'est à dire que c'est bien du multiplexage physique, vu que c'est le même tuyau.
Mais on peut pas dire que ce soit du multiplexage logique, comme c'est une nouvelle connexion TCP, et donc un canal différent.
Et c'est pour ça que tu dis que c'est au niveau de la couche 5 application qu'on fait une nouvelle connexion TCP.
Et que donc au sens strict il n'y a pas de multiplexage logique car c'est une nouvelle connexion TCP.

J'ai tout compris.

Mais tu comprendras que l'idée du port c'est bien même si c'est des connexions TCP différentes donc au sens strict pas de multiplexage,
d'avoir la même ip dans des réseaux locaux LAN et que cela ne pose pas de problème, lorsqu'il se connecte sur un serveur sur le même port.
Et comme c'est des connexion réseau/TCP différentes, on ne peut parler de multiplexage, même au sens logique, même si elles ont la même ip dans leur réseaux locaux LAN respectif.
Mais l'idée est la.

Y a toujours un truc que je comprends pas :
Si c'est des nouvelles connexions TCP au niveau de la couche 5 application et pas au niveau de la couche 3 réseau.
Comment l'application coté serveur dans un modèle client/serveur fixe le port sortant, coté client ?

[Christophe]

Vu le ton, moi je laisse tomber.