1. Introduction
2. Les conséquences du modèle TCP/IP
3. La notion de ports d'écoute
4. Approfondissement sur le transport IP
5. La solution par serveur proxy
6. La solution par routeur NAT

Voilà ! Vous avez connecté vos PC (2, 3, 10, plus !...) entre eux, et vous êtes devenus un véritable Terminator de Quake II en réseau.
Maintenant vous vous dites que vous avez assez joué, et que vous pourriez faire quelque chose de plus utile de votre réseau. Vous êtes par exemple un mordu du web, mais vous êtes continuellement dérangé par votre petit frère qui veut sans cesse discuter sur IRC. Vous vous dites alors : "Et si je connectais tout mon LAN sur Internet", et vous pensez à l'unique connexion réseau que vous avez acquise chez un provider (modem ou câble).

L'idée est excellente; elle est même tout à fait réalisable, mais pas nécessairement aussi facilement que vous l'auriez pensé.

Supposons que vous ayez suivi les quelques notions que je vous expose aux chapitre mise en place d'un réseau local et le protocole TCP/IP et Internet, vous avez retenu ceci :

1. Comme TCP/IP est le langage d'Internet, vous avez correctement configuré votre LAN sous ce protocole après avoir assigné à chaque ordinateur une adresse IP propre de type 192.168.0.1, 192.168.0.2, etc... (masque de sous-réseau : 255.255.255.0) et créé le fichier host adéquat sur chaque ordinateur.
2. Vous savez que votre ISP (Internet Service Provider) vous attribue une et une seule adresse IP lorsque vous vous connectez à Internet.
   Cette adresse est souvent fixe (on dit "statique") dans le cas d'un câble-opérateur, et variable (on dit "dynamique") dans le cas d'une connexion par modem (votre ISP a une fourchette d'adresses IP disponibles et vous en attribue une de libre lorsque vous vous connectez).
3. Vous avez retenu que les paquets IP que vous envoyez ou recevez sur Internet contiennent les adresses IP des l'expéditeur et du destinataire.

Si vous réfléchissez un peu à ces trois points, vous comprenez tout doucement le gravissime problème qui va se poser :

Vous ne pouvez pas identifier de manière univoque tous vos ordinateurs sur Internet, ce qui est une condition obligatoire (puisque le paquet IP doit contenir l'adresse de l'expéditeur et du destinataire).

En effet, seul l'ordinateur de votre LAN qui est connecté directement à Internet (l'ordinateur sur lequel le modem est connecté) possède un "numéro de téléphone" valable sur Internet (l'unique adresse IP attribuée par votre ISP). Les autres ordinateurs de votre LAN ont des adresses "bidons" de type 192.168.0.x qui sont sûrement utilisées par des milliers d'autres utilisateurs dans le monde qui, comme vous, ont créé un réseau local chez eux. C'est bien pour cela que ces adresses ne sont pas routées par les ISP.

Vous pourriez vous croire malin en attribuant la même adresse IP à tous les ordinateurs. Vous devriez cependant vous rendre compte qu'un tel système n'est pas possible, car une information entrante sur votre IP ne "saurait" quel ordinateur du LAN rejoindre. De toute façon, Windows interdit d'attribuer une même adresse IP à plus d'une machine sur un même réseau; le problème est donc réglé.

Vous vous retrouvez donc avec une architecture de ce type :

Vous constatez que la machine de gauche est "à cheval" sur deux réseaux :

1. le réseau local 192.168.0.0
2. le réseau Internet 195.44.56.0

Cette machine un peu particulière qui est capable de jouer sur les deux réseaux est appelée la passerelle (gateway).

• Si votre ISP vous offrait une plage d'adresses IP valables sur Internet (disons une distincte pour chacun de vos ordinateurs),

• Mais comme votre ISP ne vous attribue qu'une adresse IP valable sur Internet, et comme les IP de vos ordinateurs ne correspondent à rien sur Internet, la passerelle doit être capable de diriger sélectivement l'information provenant d'Internet vers un ordinateur précis du LAN.

Cette machine indispensable peut être soit un serveur proxy soit un routeur NAT.

Cette section décrit la manière particulière dont fonctionnent les applications Internet. Ces dernières, lorsqu'elles doivent communiquer sur Internet, utilise un paramètre supplémentaire en plus de l'adresse IP de l'expéditeur et du destinataire : le port de l'application. Généralement, chaque application travaille sur un port spécifique.
Une bonne approche des ports (dits aussi "sockets") pourrait être de les comparer au fonctionnement des lignes numériques (type ISDN) de nos téléphones actuels : vous savez que ces téléphones peuvent recevoir plusieurs appels sur votre seul numéro (par exemple, vous pouvez téléphoner avec un ami, surfer sur Internet et recevoir un fax, le tout simultanément). On peut faire l'analogie avec TCP/IP :

• Votre numéro de téléphone correspond à votre adresse IP sur Internet
• Les différentes lignes de votre téléphone correspondent aux différents sockets

La comparaison s'arrête là, car autant votre téléphone ISDN peut recevoir simultanément au plus 8 lignes, autant votre connexion à Internet comporte plusieurs milliers de ports d'écoute !

Ces ports ne sont pas totalement aléatoires : les différents types d'applications travaillent généralement sur des ports bien définis (même si, exceptionnellement, cela peut varier).

Je vous donne ci-dessous une liste non-exhaustive des applications réseaux les plus courantes.

Bien évidemment, certaines personnes font parfois tourner certains de ces services sur d'autres ports. Par exemple, si vous tapez dans votre browser l'adresse :

http://www.serveur.com:8080

cela veut dire que vous essayez de vous connecter à un serveur web tournant sur le port 8080 au lieu du port 80 usuel.

A côté du système proxy, il existe une autre solution pour partager une connexion à Internet : le routage NAT (Network Address Translation). L'utilisation d'un routeur NAT est une solution très élégante et transparente. Cependant, avant de se lancer immédiatement dans le vif du sujet, il me faut détailler un peu plus la manière dont les ordinateurs s'échangent des données sur Internet.

Vous devez savoir que lorsqu'un ordinateur transmet des données sur Internet, les paquets IP qui circulent contiennent tous les informations suivante :

1. l'adresse IP du "destinataire" (serveur)
2. le socket de l'application serveur
3. l'adresse IP de "l'expéditeur" (votre ordinateur)
4. le socket de l'application client

Notez que je n'aime pas trop les termes "destinataire" et "expéditeur", vu que toute connexion sur Internet voit des paquets IP aller dans les deux sens.

Exemple : vous ouvrez une page web dans votre navigateur (ex. http://www.joliepageweb.fr). Votre browser tente alors de se connecter à l'adresse IP du serveur distant (résolue par le serveur DNS) sur le port 80 (généralement utilisé par les serveurs web). Dans le paragraphe précédent, je vous indiquais certains ports usuels. Voici une liste plus exhaustive pour les intéressés.

Vous noterez que je n'ai pas encore précisé le port utilisé par l'application cliente. Contrairement à ce que vous auriez pu penser, le port sur lequel l'application cliente fait sa requête n'a pas à être identique au port de l'application serveur.

• D'une manière générale, on peut dire qu'une grande majorité d'applications serveurs tournent sur un port inférieur à 1024 (http : 80, ftp : 21, telnet : 23, pop3 : 110, etc.). Avec des exceptions toutefois, par exemple ders serveurs FTP "pirates" (tournant sur des ports exotiques) ou certains serveurs web (port 8080 par exemple).
• D'une manière générale, les applications clientes font leur requête sur un port supérieur à 1024.

Par exemple, un paquet IP envoyé par votre navigateur au site Microsoft aurait les paramètres suivants :

	IP du destinataire :  207.46.131.135  (Microsoft)
	port serveur web :    80
	IP de l'expéditeur :  195.2.200.149   (votre adresse IP)
	port client web :     7597

Ces quelques points un peu éclaircis, il me reste encore à vous dire quelques mots sur les types de protocoles IP présents sur Internet. Comme vous ne le savez peut-être pas, il y a deux types fondamentaux de protocoles IP : le protocole TCP et le protocole UDP.

• Les paquets IP les plus courants sur Internet sont les paquets TCP (Transmission Control Protocol). Ce protocole est utilisé pour une transmission fiable de données, c'est à dire sans pertes. C'est donc le protocole de la majorité des applications (http, ftp, mail, irc, etc.).
  J'ai déjà évoqué grossièrement le mécanisme de ce protocole. Rajoutons que dans ce protocole aucune donnée n'est transmise avant qu'une connexion n'ait été mise en place (à l'aide d'un flag (SYN)) entre les deux ordinateurs (qui font une sorte d'accord bilatéral de connexion). De même, lorsque toutes les données ont été transmises, la connexion est "officiellement" fermée. D'une manière analogue, un des ordinateurs peut, pour une raison ou pour une autre, clore la connexion (TCP reset; rappelez-vous du message "le serveur a réinitialisé la connexion" que vous avez sûrement vu quelquefois).
• Parallèlement, il circule sur le net des paquets UDP (User Datagram Protocol) qui sont utilisés pour des transmissions non fiables de données, c'est à dire où la perte de certains paquets IP est tolérée. Ce sont particulièrement les paquets émis par des serveurs de type Real Audio, MS Netshow, etc., bref toutes les applications qui vous permettent d'écouter du son ou voir de la vidéo en direct sur Internet. Dans ce cas, une fiabilité 100%, en d'autres termes la réception de l'intégralité des données, n'est pas exigée (au détriment bien évidemment de la qualité de réception). Lorsque vous utilisez ce genre de programmes, vous pouvez d'ailleurs voir le nombre de paquets perdus (souvent indiqués en %).
  Notez que le protocole UDP, au contraire de TCP, n'exige pas l'établissement d'une connexion : le serveur envoie comme bon lui semble les paquets IP à l'adresse IP et sur le port de son choix.

Il est temps maintenant d'expliquer un des façon de partager une connexion à Internet. Voici donc la manière dont fonctionne un serveur proxy.
Considérons un réseau local connecté à un serveur proxy lui-même connecté à Internet :

Admettons qu'un ordinateur du réseau local veuille télécharger une page web sur Internet. Pour cela il ouvre une connexion vers le proxy, sur le port défini pour le service concerné (ici http), et lui fait la demande de la page web. A son tour, le proxy ouvre une nouvelle connexion vers le serveur d'Internet concerné par la demande, récupère l'information et la retransmet aussitôt à l'ordinateur local.
Dans ce schéma, vous constatez que nous sommes en présence d'une double connexion.
L'avantage d'un serveur proxy est de pouvoir stocker dans un cache local les pages web visitée. Ainsi, si un ordinateur du LAN désire voir une page qui a déjà été téléchargée préalablement, le proxy est capable de fournir la page demandée directement depuis son cache local, ce qui est beaucoup plus rapide et économise le trafic sur Internet.

D'une manière plus générale, vous comprenez que la tâche du serveur proxy est de rester attentif à toute connexion entrant chez lui sur des ports bien précis que vous avez configurés. Vous pouvez aussi voir cela d'une autre façon : le serveur proxy "n'écoute" pas toutes les connexions; il ne s'intéresse qu'à celles pour lesquelles il a été configuré. Cette limitation a des avantages et des désavantages :

• Avantage, car le serveur proxy devient un "firewall" (pare-feu) qui filtre les informations le traversant. C'est une sécurité contre des attaques TCP/IP extérieures qui ont lieu généralement sur d'autres ports que ceux que je vous ai indiqués.
• Désavantage, car de nombreuses applications sophistiquées travaillent sur plusieurs ports en même temps, dont certains sont ouverts dynamiquement. C'est le cas de Netmeeting qui travaille sur 5 ports dont 3 dynamiques; un tel logiciel ne peut donc pas traverser Wingate. Même remarque pour les jeux se connectant sur des gaming-zones sur Internet; seul le logiciel Kali (http://www.kali.net) leur permettra de jouer à travers le proxy avec leurs amis sur Internet.
  De manière analogue, les commandes ICMP (comme 'ping' par exemple) ne dépassent pas le firewall. Ainsi, si vous êtes derrière un proxy et que vous tapez 'ping microsoft.com', vous obtiendrez probablement la résolution de noms 'pinging microsoft.com [207.46.131.16]...', mais vous aurez ensuite le message suivant : 'Destination host unreachable', car la commande ping ne peut traverser le proxy. Comprenez par là que le serveur proxy n'est pas un routeur.
• Autre tracasserie : tous les services que l'on veut utiliser (http, ftp, pop, smtp, etc.), pour autant qu'ils soient possibles, doivent être configurés un par un sur le serveur proxy (avec un certain port et des règles de "redirection" sur Internet), et toutes les applications sur les ordinateurs du réseau local doivent être en mesure d'utiliser le proxy et être configurées dans ce sens. Tout cela représente un travail non négligeable pour l'administrateur réseau.

Dans la partie 'Pratique', j'explique comment mettre en place un serveur proxy sur un système Microsoft (Windows 9x ou NT).

Il existe à mon goût une manière plus simple et plus élégante de partager une connexion à Internet que l'utilisation d'un serveur proxy : le routage NAT (Network Address Translation)

Le routeur NAT, tout comme un serveur proxy, est une machine à cheval sur le réseau Internet et sur le réseau local que vous voulez y connecter; il fait office de passerelle (gateway).

Le routeur NAT, comme son nom l'indique, fait réellement du routage de paquets IP, c'est à dire qu'il transmet bien les paquets reçus par un ordinateur du LAN vers Internet (et inversément), contrairement à un serveur proxy qui ouvre une seconde connexion.

L'ingéniosité du routage NAT vient de sa manière de gérer plusieurs ordinateurs locaux d'adresses IP de type 192.168.0.x, de transmettre leurs paquets spécifiques vers Internet, et de leur redistribuer spécifiquement les paquets reçus. L'astuce est la suivante :

Lorsque le routeur NAT reçoit un paquet IP d'un des ordinateurs du LAN, il en modifie :

1. l'adresse IP de l'expéditeur pour y mettre sa propre adresse (l'IP "légale" de votre connexion
2. le port de l'application cliente par une valeur particulière

Le routeur NAT logge ensuite ces informations dans une table.

Lorsque le serveur d'Internet répond à la requête et renvoie des paquets IP sur le routeur, ce dernier vérifie dans ses tables qu'il possède bien l'entrée correspondante (par rapport au port de l'application cliente), puis y réécrit les coordonnées (IP + socket) de l'ordinateur du LAN. Le paquet IP peut ainsi rejoindre sa destination dans le LAN.

Exemple : votre ordinateur du LAN d'adresse IP 192.168.0.7 veut accéder à la page web du serveur www.machin.com (d'adresse IP 124.40.67.43) via un routeur NAT travaillant sur l'IP 192.168.0.1 (locale) et l'IP 195.200.2.149 (Internet). Les deux tableaux suivants montrent précisément ce qui se passe.

Transfert des données

Quelques remarques s'imposent :

1. Les routeurs NAT travaillent souvent sur des ports "élevés". A titre d'exemple, le logiciel Winroute utilise des ports de 61000 à 61600.
2. On peut se demander pourquoi le routeur NAT modifie le port de l'expéditeur puisqu'il retient de toute façon le port sur lequel l'application cliente a fait sa requête. En fait, cette modification est nécessaire pour éviter des désagréments dans le cas où plusieurs ordinateurs du LAN feraient une requête sur le même port.
3. L'inconvénient du routeur NAT est d'être très pointilleux sur les connexions entrantes : si le routeur NAT n'a pas dans ses tables une entrée concernant une connexion, il ne laisse rien "entrer". C'est en quelque sorte une mesure de sécurité, et aussi une conséquence de sa façon de fonctionner : si vous voulez faire tourner sur un ordinateur du LAN un serveur (par ex. http ou ftp) qui soit accessible par Internet, il vous faudra configurer le routeur NAT pour accepter et rediriger correctement une connexion entrante.

Dans la partie 'Pratique', j'explique comment mettre en place un routeur NAT sur un système Microsoft (Windows 9x ou NT).

(C) 02/02/2008 - Dernière modification : 30/10/2013 - F4CVM / Pascal