Mis à jour le mercredi 3 janvier 2018
  • 15 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Ce cours existe en livre papier.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

J'ai tout compris !

La NAT et le port forwarding

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Dans ce chapitre, nous allons voir pourquoi il a été nécessaire de mettre en place la NAT sur Internet, puis comprendre ce que c'est et à quoi elle sert.
Nous verrons ensuite quelques exemples pratiques de mise en place de NAT.
Attention, c'est un chapitre qui n'est pas simple et qui très important, alors prenez bien le temps de comprendre et d'assimiler ce qui y est expliqué !

Pourquoi la NAT ?

Un peu d'histoire

Les problèmes

En fait, la NAT vient répondre à deux problèmes majeurs, le second problème étant engendré par le premier.
Il y a tout d'abord eu un problème de pénurie d'adresses sur Internet auquel une réponse apportée a été de spécialiser certaines plages d'adresses IP pour une utilisation privée. Cela a engendré un second problème qui est de pouvoir accéder à Internet en utilisant ces adresses IP privées.
Examinons-les un par un.

Le problème number one

Nous avons vu qu'Internet était composé de réseaux connectés entre eux.

Mais combien de machines Internet peut-il contenir ?

Y a-t-il une limite ?

Quel serait le facteur limitant ?

En fait, si vous vous souvenez de la couche 3, il y a bien un facteur limitant au nombre de machines possibles sur Internet, c'est le nombre d'adresses IP disponibles.

En effet, une adresse IP est codée sur 4 octets, soit 32 bits. Elle peut donc prendre $\(2^{32}\)$  valeurs, soit environ 4 milliards.

C'est beaucoup... ou pas.
En effet, à l'échelle d'Internet et de sa croissance, 4 milliards c'est bien peu. Et d'ailleurs, nous avons quasiment utilisé tous les blocs d'adresses disponibles sur Internet... Nous ne pouvons plus rajouter de nouvelles machines sur Internet...

Voici des tableaux représentant l'utilisation des blocs d'adresses sur Internet, en 1993, 2000 et 2007. Chaque chiffre correspond au premier octet d'un bloc d'adresses (par exemple la case 52 représente tous les réseaux commençant par 52, soit 52.X.X.X)

Utilisation des blocs d'adresses IP en 1993
Utilisation des blocs d'adresses IP en 1993
Utilisation des blocs d'adresses IP en 2000
Utilisation des blocs d'adresses IP en 2000
Utilisation des blocs d'adresses IP en 2007
Utilisation des blocs d'adresses IP en 2007

On peut voir sur les images précédentes que, dès 2007, les plages disponibles étaient restreintes. On considère que la totalité des plages étaient utilisées en juin 2012. Aujourd'hui, l'organisme qui gère la distribution des adresses sur Internet utilise tous ses moyens pour libérer certaines grandes plages afin de rendre de nouvelles adresses disponibles, mais la fin est proche...

Quoi ? Comment peut-on garder son calme alors que la fin de l'évolution d'Internet est proche ? :o

Il suffit d'avoir un flegme naturel et extraordinaire. :D

Ou bien il suffit de savoir que la NAT répond à une partie du problème posé par la pénurie d'adresses et surtout qu'un nouveau standard de protocole IP est en cours de mise en place et réglera ce problème. Il s'agit d'IPv6, que nous verrons un peu plus tard.

La solution temporaire, l'adressage privé

Les personnes qui géraient Internet se sont dit à un moment donné que, vu que certains réseaux étaient privés et que les machines sur ces réseaux n'avaient pas besoin d'être jointes depuis Internet (elles étaient de simples clients, mais pas des serveurs), il n'était pas nécessaire de leur fournir une adresse IP publique à chacune d'entre elles.

Ainsi, on s'est dit qu'on pourrait donner des adresses IP privées à ces machines.

Euh... C'est quoi, une adresse privée ?

C'est une adresse qui a été réservée pour une utilisation privée.
En gros, on a réservé une certaine plage d'adresses pour une utilisation privée. Cette plage d'adresses n'est donc pas utilisée sur Internet, elle est réservée pour tous les réseaux du monde entier qui n'ont pas besoin d'être joints depuis Internet.

Par exemple, dans mon école, les élèves ont besoin d'accéder à Internet, mais ne font pas tourner de services qui ont besoin d'être accessibles. Un adressage privé est donc tout à fait adapté !

Mais comment ont été choisies ces adresses ?

La RFC 1918

Comme nous l'avons vu dans le chapitre sur l'adressage IP, la RFC 1918 précise les adresses à utiliser sur un réseau local.

Ce document dit en gros que si vous voulez créer un réseau local, vous devez utiliser des adresses réservées pour un réseau privé parmi les suivantes:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Voilà, vous savez maintenant quelles adresses utiliser sur votre réseau local. Toutefois, la plupart du temps, c'est votre box qui vous donne une adresse et qui vous impose l'utilisation d'une adresse parmi ces plages.

Mais que se passe-t-il si l'on ne respecte pas les plages indiquées par la RFC ?

Déjà, ce n'est pas bien de ne pas respecter les normes d'Internet ! :colere:
Cependant, ça fonctionnera... ou presque.
Vous arriverez à aller partout sur Internet, sauf sur les réseaux à qui appartiennent réellement les adresses que vous avez utilisées.

Ce n'est pas clair ? Prenons un exemple.

Vous venez de recevoir votre tout nouveau routeur, et vous souhaitez connecter entre elles vos machines chez vous. Au moment de choisir un adressage pour le réseau, vous prenez arbitrairement le réseau 74.125.230.0/24 (c'est un peu tordu comme choix, mais bon :o )
Vous branchez les machines entre elles et essayez de les pinguer... ça marche !
Vous configurez le routeur comme passerelle par défaut, vous le branchez à Internet et essayez de naviguer... ça marche encore !
Cool ! Tout semble marcher à merveille.
Vous jouez à vos jeux préférés, envoyez et recevez vos mails, tout va bien.
Puis, vous essayez d'aller sur Google pour faire une recherche et là, patatras, ça ne marche pas !
Tout fonctionne, sauf Google. o_O

Que se passe-t-il ?

Sans le savoir, vous avez choisi le même réseau que celui des serveurs de Google 74.125.230.0/24. C'est ce qui explique que vous ne puissiez plus les joindre désormais. Nous allons voir ce qui se passe exactement.

Regardons ce qui se passe au niveau de votre machine.

Pour mieux comprendre, regardons notre table de routage. Elle doit ressembler à cela :

Table de routage de notre machine

Réseau à joindre

passerelle

74.125.230.0/24

74.125.230.1

défaut

La box !

Ainsi, quand nous essayons de nous connecter à www.google.fr qui a comme adresse IP 74.125.230.84, notre table de routage nous dit qu'il faut rester sur le réseau local. Donc notre requête ne partira pas sur Internet et nous n'aurons jamais de réponse de Google.

Le fait d'avoir choisi arbitrairement une plage d'adresses en dehors de celles préconisées par la RFC 1918 nous empêche d'accéder aux vrais réseaux qui possèdent ces adresses.
À l'inverse, étant donné que les réseaux de la RFC 1918 n'appartiennent à personne sur Internet, nous sommes sûrs de ne pas nous priver d'accès à quelque réseau que ce soit en les choisissant.

Vous saurez donc maintenant choisir proprement vos adresses pour vos réseaux si vous devez en créer.

Mais revenons à nos moutons et à notre second problème !

Le problème number two !

Nous avons compris que la NAT allait permettre à nos machines possédant des adresses privées sur notre réseau local d'aller quand même sur Internet comme si elles possédaient des adresses IP publiques.

Description du problème

Imaginons que vous êtes chez vous, derrière votre box, avec un adressage privé en 192.168.0.0/24.
Votre machine a comme adresse 192.168.0.1/24.

Voici ce qui se passerait si nous n'avions pas de NAT et que nous voulions joindre un site sur Internet comme www.siteduzero.fr qui a comme adresse IP 217.70.184.38 au moment de ma requête.

Votre machine fabrique une jolie trame à envoyer sur le réseau avec le contenu suivant:

Adresse MAC DST

Adresse MAC SRC

Protocole de couche 3

...

@IP source, 192.168.0.1

@IP destination, www.siteduzero.fr soit 217.70.184.38

CRC

Trame Ethernet, qui contient le datagramme IP

Cette trame va, par la suite, aller de routeur en routeur sur Internet en fonction de son adresse IP destination qui est ici 217.70.184.38, et la trame va donc bien aller jusqu'à www.siteduzero.fr.

Tout se passe bien, ouf !

Mais attention au retour...

Le Site du Zéro va nous répondre, à l'adresse spécifiée comme adresse IP source dans le datagramme d'origine...
Et patatras, cette adresse est une adresse privée (192.168.0.1) qui n'appartient à personne sur Internet et qui ne peut donc pas être routée !

Notre trame va donc arriver à un routeur au cœur d'Internet, qui va la bloquer, car il sait qu'une adresse privée n'est pas censée se balader sur Internet.
Dans ce cas, nous n'aurons jamais notre réponse de la part de Google. :(

De manière générale, nous n'aurons jamais de réponses à des requêtes envoyées sur Internet quand nous utilisons des adresses privées...
Il va falloir trouver une solution à ce problème, et cette solution, c'est la NAT !

Fonctionnement de la NAT

Principe

Nous avons identifié le problème. Quand un paquet est envoyé sur Internet, la réponse ne revient pas, car l'adresse IP destination est une adresse privée.
Or, cette adresse IP destination dans la réponse est en fait l'adresse IP source qui était indiquée dans la requête !

Il faudrait donc que cette adresse IP source, qui est privée, puisse être remplacée par une adresse publique. C'est là tout le principe de la NAT !

Un peu de vocabulaire

Il existe deux types de NAT différents, la NAT dynamique et la NAT statique.

  • La NAT dynamique associe n adresses privées à une seule adresse publique. Ainsi, on peut connecter n machines en n'utilisant qu'une seule adresse publique. On économise donc des adresses.

  • En NAT statique, on fixe une adresse publique pour chaque adresse privée. On n'économise donc... rien du tout !

Dans la suite du cours, nous ne nous intéresserons qu'à la NAT dynamique, la NAT statique étant aujourd'hui très peu utilisée, car elle ne répond pas au problème de la pénurie d'adresses IP.

Fonctionnement de la NAT dynamique

Il nous faut maintenant changer l'adresse IP source dans un paquet envoyé sur Internet pour y mettre une adresse IP publique.

Mais laquelle choisir ?

C'est simple, nous allons tout simplement utiliser l'adresse IP du routeur qui fait la liaison entre notre réseau privé et Internet, réseau public. En effet, ce routeur possède une adresse IP publique du côté d'Internet.

Prenons l'exemple de votre réseau chez vous, derrière votre box Internet.

Réseau local derrière box Internet
Réseau local derrière box Internet

Les adresses locales sont sur le réseau 192.168.0.0/24 qui est bien un réseau privé. On voit bien aussi l'adresse 82.238.22.47 qui est l'adresse publique de notre box (choisie au hasard)

Regardons maintenant ce qui se passe dans le cas de la NAT lors de l'envoi d'un paquet sur Internet.

Étape 1, envoi sur le réseau local d'une requête au Site du Zéro :

Adresse MAC Box

Adresse MAC de 192.168.0.1

Protocole de couche 3

...

@IP source, 192.168.0.1

@IP destination, www.siteduzero.fr soit 217.70.184.38

CRC

Trame Ethernet en sortie de la machine 192.168.0.1
Étape 2, NAT du paquet par le routeur:

Adresse MAC routeur sur Internet

Adresse MAC box

Protocole de couche 3

...

@IP source, 82.238.22.47

@IP destination, www.siteduzero.fr soit 217.70.184.38

CRC

Trame Ethernet en sortie de la box
On voit bien ici que l'adresse IP source a été changée pour mettre celle de la box.

Ainsi, notre paquet va aller jusqu'au Site du Zéro, et celui-ci va répondre à l'adresse IP 82.238.22.47 qui est celle de notre box.

Mais comment la box va pouvoir renvoyer le paquet à la bonne machine sur le réseau local ? Que se passe-t-il si plusieurs machines font des requêtes en même temps sur le Site du Zéro ?

C'est une très bonne question !
Pour l'instant, notre box n'a aucun moyen de savoir à quelle machine en interne elle doit renvoyer le paquet, mais nous allons voir que nous pouvons utiliser les ports de la couche 4 pour ajouter une information qui nous permettra de savoir quelle machine a envoyé la requête !

Utilisation des ports de la couche 4

Lors de l'établissement d'une connexion, que ce soit en TCP ou en UDP, un port source est choisi par la machine qui émet la requête. Nous allons nous servir de ce port pour identifier la machine qui a émis la requête à l'origine. Sachant que ce port est choisi aléatoirement entre 1024 et 65535.

Si nous reprenons l'envoi de la trame et y ajoutons les informations de couche 4, cela donne:

Adresse MAC Box

Adresse MAC de 192.168.0.1

Protocole de couche 3

...

192.168.0.1

217.70.184.38

Port source 10277

Port destination 80

CRC

Trame Ethernet en sortie de la machine 192.168.0.1
La box va recevoir ce paquet et pouvoir noter la correspondance entre l'adresse IP source 192.168.0.1 et le port source utilisé 10277.

En fait, elle note même un quadruplet d'informations dans une table, la table NAT !

Table NAT

 

@IP SRC, @IP DST, port SRC, port DST

@IP SRC, @IP DST, port SRC, port DST

192.168.0.1, 217.70.184.38, 10277, 80

82.238.22.47, 217.70.184.38, 10277, 80

On a d'un côté les informations sur le réseau local, et de l'autre les informations à la sortie de la box, après que la NAT ait eu lieu.

Regardons maintenant le paquet renvoyé par la box:

Adresse MAC routeur sur Internet

Adresse MAC box

Protocole de couche 3

...

82.238.22.47

217.70.184.38

Port source 10277

Port destination 80

CRC

Trame Ethernet en sortie de la box
Le Site du Zéro va répondre à cette requête, et il va envoyer un paquet à notre box :

Adresse MAC routeur sur Internet

Adresse MAC site du zéro

Protocole de couche 3

...

217.70.184.38

82.238.22.47

Port source 80

Port destination 10277

CRC

Trame Ethernet en sortie du Site du Zéro
La box recevant ce paquet va pouvoir regarder dans sa table NAT et voir que celui-ci doit être naté en sens inverse et renvoyé à 192.168.0.1.

Table NAT

 

@IP SRC, @IP DST, port SRC, port DST

@IP SRC, @IP DST, port SRC, port DST

192.168.0.1, 217.70.184.38, 10277, 80

82.238.22.47, 217.70.184.38, 10277, 80

Ainsi, notre machine 192.168.0.1 qui a envoyé une requête sur Internet, avec son adresse IP privée, va quand même pouvoir recevoir la réponse.
N'est-ce pas magnifique ? :p

Enfin, presque...
Nous n'en avons pas encore tout à fait fini avec la NAT dynamique.
Imaginons, par le plus grand des hasards, que deux machines sur notre réseau local fassent une requête vers le Site du Zéro, en utilisant le même port source.

La table NAT de la box serait la suivante:

Table NAT

 

@IP SRC, @IP DST, port SRC, port DST

@IP SRC, @IP DST, port SRC, port DST

192.168.0.1, 217.70.184.38, 10277, 80

82.238.22.47, 217.70.184.38, 10277, 80

192.168.0.2, 217.70.184.38, 10277, 80

82.238.22.47, 217.70.184.38, 10277, 80

On se rend alors compte que les informations à droite dans le tableau sont parfaitement identiques.
Au retour d'un paquet appartenant à l'une ou l'autre des connexions, la box n'aura aucun moyen de savoir si c'est 192.168.0.1 ou 192.168.0.2 qui doit recevoir la réponse...

Donc le choix du port source comme élément différenciateur n'est pas suffisant. Il va encore falloir trouver une astuce.

La box entre en jeu

En fait, il y a un moyen simple de s'assurer que toutes les requêtes qui sortiront n'auront jamais le même port source, il suffit que ce soit la box qui le fixe.
Ainsi, la box modifiera à la fois l'adresse IP source ET le port source.

Par rapport à notre cas précédent, ça donnerait la table NAT suivante :

Table NAT

 

@IP SRC, @IP DST, port SRC, port DST

@IP SRC, @IP DST, port SRC, port DST

192.168.0.1, 217.70.184.38, 10277, 80

82.238.22.47, 217.70.184.38, 2356, 80

192.168.0.2, 217.70.184.38, 10277, 80

82.238.22.47, 217.70.184.38, 2357, 80

On voit maintenant que lorsqu'un paquet reviendra avec comme port destination 2356, la box saura qu'il s'agit d'un paquet à destination de 192.168.0.1 et que, lorsqu'il reviendra avec comme port destination 2357, ce sera pour la machine 2357.

Récapitulons un peu ce que nous venons de voir.

La NAT dynamique récapitulée

Nous avons vu que la NAT dynamique permettait à des machines connectées sur un réseau local à adressage privé d'accéder à Internet en utilisant l'adresse IP publique du routeur qui fait la liaison entre le réseau interne et Internet.
Ainsi, on économise beaucoup d'adresses IP, car on n'utilise qu'une seule adresse publique pour toutes les machines qui sont sur le réseau privé.

Mais y a-t-il une limite au nombre de machines sur le réseau privé ?

Théoriquement, oui.
Étant donné que la box ne peut allouer que 65535 ports, s'ils sont tous utilisés, la box ne peut pas accepter de nouvelle connexion.
Ainsi, si l'on a 65535 machines qui ouvrent chacune une connexion, on atteint les limites.
Or, la plupart du temps, les machines ont plus d'une seule connexion ouverte. En considérant qu'une machine ouvre en moyenne une dizaine de connexions en parallèle, on peut estimer raisonnablement pouvoir brancher 6000 machines derrière un routeur qui fait de la NAT.

En pratique, avoir une unique adresse IP pour 6000 machines est quand même rare, car les entreprises qui ont autant de machines ont souvent plusieurs adresses IP publiques à leur disposition et cette limite due à la NAT n'est quasiment jamais étudiée ni atteinte.

Quoi qu'il en soit, pour ce qui vous intéresse, vous ne devriez jamais atteindre cette limite chez vous, derrière votre box. :-°

Des problèmes encore des problèmes

Et des solutions !
En effet, depuis le début de notre cours, nous avons souvent identifié des problèmes mais nous avons réussi chaque fois à y apporter des solutions. :D

Nous avons vu que nous nous servions des ports pour réaliser la NAT dynamique. Les ports existent en TCP et UDP, mais quid d'autres protocoles qui n'ont pas de ports ? Je pense à ICMP que nous avons vu, ou encore à ARP…

En fait, des solutions spécifiques sont mises en place pour à peu près tous les protocoles existants. On étudie le contenu des en-têtes pour y trouver des éléments qui sont propres à chaque connexion, et on peut alors suivre les connexions individuellement.

Qu'en est-il du protocole ARP ?

Les plus perspicaces d'entre vous l'auront compris.
ARP n'est pas concerné par la NAT vu que c'est un protocole local basé sur le broadcast. Il ne passe donc jamais à travers un routeur et n'est donc jamais concerné par la NAT.

Cependant, nous avons encore des problèmes à étudier, et un problème majeur !

Accéder à Internet c'est bien, mais pouvoir être joint c'est mieux !

En effet, grâce à la NAT dynamique, nous pouvons sortir sur Internet en ayant une adresse privée.
Par contre, il n'est pas possible à quelqu'un de nous joindre de l'extérieur.

Nous n'avons qu'une seule adresse publique et n adresses privées. Ainsi, lors de l'établissement d'une connexion depuis l'extérieur, le routeur n'a aucun moyen de savoir pour quelle machine privée est la requête.
Quand c'est une machine interne qui initialise la connexion, le routeur peut noter les informations de connexion et ainsi identifier le paquet au retour. Par contre, quand le premier paquet d'une connexion arrive de l'extérieur, le routeur n'a aucun moyen de savoir pour qui est la requête. :(

Sens de connexion possible avec la NAT
Sens de connexion possible avec la NAT

Comme toujours, nous allons trouver une solution à ce problème !

Imaginons que nous faisons tourner un service sur notre machine sur le réseau local privé. Par exemple, un serveur web qui tourne sur le port 80 de la machine 192.168.0.1.

Réseau local avec serveur web
Réseau local avec serveur web

Si quelqu'un veut accéder à notre réseau, la seule porte d'entrée est l'adresse IP publique 82.238.22.47. S'il s'adresse au port 80 de ce routeur, il y a deux cas possibles :

  • soit il y a un serveur web sur le routeur et la personne tombera dessus ;

  • soit il n'y a pas de serveur web et le routeur renverra un segment TCP avec le flag RST de postionné.

Mais dans les deux cas, la personne n'arrivera pas sur notre joli site web local.

Il y a pourtant bien une solution, il est possible de dire à notre routeur de rediriger la requête spécifiquement vers notre machine 192.168.0.1 en fonction du port sur lequel la requête a lieu. Cela s'appelle le port forwarding !

Le port forwarding

Principe

Pour notre exemple précédent, nous allons dire au routeur que tout paquet arrivant sur son port 80 devra être redirigé vers la machine d'adresse 192.168.0.1 sur le port 80.

Table de port forwarding

 

 

 

@IP externe 82.238.22.47

Port externe TCP 80

@IP interne 192.168.0.1

Port interne TCP 80

Port forwarding vers notre serveur web
Port forwarding vers notre serveur web

Ainsi, toute personne accédant à notre adresse IP publique sur le port 80 sera automatiquement redirigée, sans même le savoir, vers notre serveur web local.
Notre serveur peut ainsi, grâce au port forwarding, être joignable depuis l'extérieur.

Par conséquent, si vous avez plusieurs services sur votre réseau local, comme par exemple un serveur FTP ou un serveur de jeu, vous pouvez tout à fait les rendre joignables depuis l'extérieur du réseau. Chacun sera joignable sur un port particulier.

Ce mécanisme est très intéressant, car seuls les services que nous voulons rendre joignables le seront, et cela présente un gros intérêt au niveau sécurité.

Le port forwarding, c'est sécurise !

Le fait d'utiliser de la NAT dynamique ainsi que le port forwarding augmente le niveau de sécurité de votre réseau.

Euh, mais moi j'ai jamais fait de sécurité ! Ça consiste en quoi ?

Le principe pour votre ordinateur est à peu près le même que pour votre maison. Vous pouvez avoir beaucoup de portes et de fenêtres, mais plus il y en aura et plus il y aura de possibilités pour entrer dans votre maison.
Pour un ordinateur, c'est pareil, chaque port ouvert sera une porte ouverte potentielle vers votre ordinateur.

Quand il n'y avait pas de NAT, chaque machine était connectée à Internet avec sa propre adresse IP publique. Ses 65535 ports étaient donc tous potentiellement accessibles... et constituaient potentiellement des portes ouvertes vers la machine.
Attention, je ne dis pas que les 65535 ports étaient accessibles. Seuls ceux qui étaient en écoute l'étaient, car une application tournait derrière. Seulement, peu de gens avaient conscience de tous les ports ouverts sur leur machine.

Prenons notre exemple précédent et regardons les conséquences.

Nous faisons tourner un serveur web sur notre machine 192.168.0.1, mais regardons tous les ports en écoute sur cette machine (en imaginant, pour une fois, que cette machine est sous Windows)

c:\netstat -an
Proto  Adresse locale         Adresse distante       Etat
TCP    0.0.0.0:80             0.0.0.0:0              LISTENING
TCP    0.0.0.0:135            0.0.0.0:0              LISTENING
TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
TCP    0.0.0.0:1033           0.0.0.0:0              LISTENING
TCP    0.0.0.0:1035           0.0.0.0:0              LISTENING
TCP    192.168.0.1:139        0.0.0.0:0              LISTENING
UDP    0.0.0.0:135            *:*
UDP    0.0.0.0:445            *:*
UDP    0.0.0.0:1034           *:*
UDP    0.0.0.0:1384           *:*
UDP    0.0.0.0:1434           *:*
UDP    0.0.0.0:1558           *:*
UDP    127.0.0.1:1043         *:*
UDP    127.0.0.1:1555         *:*
UDP    192.168.0.1:137        *:*
UDP    192.168.0.1:138        *:*
UDP    192.168.0.1:500        *:*

Nous voyons ici qu'il y a beaucoup plus de ports ouverts que nous pouvions le penser !
En effet, Windows ouvre un certain nombre de ports pour pouvoir partager des fichiers sur le réseau ou fournir d'autres services par défaut.
Quand il n'y avait pas de NAT, notre machine était donc accessible directement depuis Internet, et tous ces ports étaient autant de portes ouvertes vers elle.
D'ailleurs, beaucoup d'attaques ont été menées à cette époque, marquée notamment par la recrudescence des vers.

Il y a eu par exemple, pour les plus connus, MS Blaster ou SQL Slammer. Autant de vers qui ont paralysé énormément de machines et de services sur Internet quand ils sont apparus.

Si, à l'époque, les machines avaient été derrière la NAT, la diffusion de ces vers n'aurait pas été aussi importante, car les ports des machines n'auraient pas pu être atteints depuis Internet.

Un des intérêts majeurs de la NAT et du port forwarding est de ne rendre accessible QUE ce qui est nécessaire.
Dans notre exemple, nous n'aurions mis en place du port forwarding que pour le port 80 pour rendre accessible notre serveur web. Ainsi, tout autre port potentiellement vulnérable n'aurait pas été joignable depuis Internet, et les vers ou autres virus n'auraient pas pu se répandre de la sorte.

Ainsi, votre box, faisant de la NAT, protège vos machines sur votre réseau local. Merci la box ! :D

Nous avons donc vu comment mettre en place de la NAT dynamique afin de donner accès à Internet à des machines ayant des adresses privées.
Nous avons aussi vu comment rendre joignables nos machines sur un réseau privé grâce au port forwarding.
Enfin, nous avons vu comment la NAT et le port forwarding avaient indirectement amélioré le niveau de sécurité d'Internet et de tous les réseaux privés.

Le tableau semble bien rose, mais il y a pourtant un inconvénient majeur au port forwarding...

La limite du port forwarding

En effet, nous avons vu dans notre exemple que nous pouvons rendre notre serveur web joignable sur Internet.

Mais que se passe-t-il si nous avons deux serveurs web sur notre réseau local ?

Eh bien c'est la catastrophe !
Étant donné que nous n'avons qu'un seul port 80 disponible, nous ne pourrons pas le rediriger vers nos deux serveurs web, il va falloir faire un choix.
Au pire, nous pourrions rediriger un autre port que le port 80, comme le 81, mais cela ne respecterait pas les standards d'Internet.

Ce n'est donc pas une solution satisfaisante.
Malheureusement pour nous, nous atteignons une limite du port forwarding qui limite à un seul serveur sur le réseau local par port disponible.
Donc un seul serveur web, un seul serveur ssh, un seul serveur DNS, etc.

C'était trop beau. :o

Toutefois, je vais vous rassurer, il existe quelques solutions qui permettent, pour certains services, de mettre un nombre illimité de serveurs derrière une unique adresse IP publique. Mais, étant donné que ces solutions sont applicatives, de couche 7, nous ne les verrons pas tout de suite.

Il est temps maintenant de mettre vos connaissances en pratique !

Exercice pas si facile !

Énoncé

Vous venez d'être embauché en tant qu'administrateur systèmes et réseaux dans l'entreprise Zéro & Cie.
L'ancien administrateur a dû partir précipitamment et vous a laissé un projet à réaliser.
La société possède sur son réseau privé 10.0.0.0/23 quelques serveurs :

  • 5 serveurs SSH (port TCP 22) (10.0.1.1,10.0.1.2,10.0.1.3,10.0.1.4,10.0.1.5) ;

  • 4 serveurs web (port TCP 80) (10.0.1.6,10.0.1.7,10.0.1.8,10.0.1.9) ;

  • et 2 serveurs DNS (port UDP 53) (10.0.1.10,10.0.1.11).

De plus, il y a environ 250 salariés dans l'entreprise qui ont leurs adresses de 10.0.0.1 à 10.0.0.254.
L'ancien administrateur a acheté une plage d'adresses sur Internet qui est la suivante:
194.34.56.0/29

On vous demande d'écrire la table de port forwarding du routeur qui fera la liaison entre le réseau privé et Internet. Sachant que ce routeur pourra donc avoir toutes les adresses du réseau public sur son interface réseau externe.

À vous de dire si cette mise en place est possible, et si oui, de proposer votre solution de NAT dynamique et port forwarding.

Pour résoudre cet exercice, il va falloir prendre les problèmes un par un.

Déjà, nous allons calculer l'étendue de la plage d'adresses publiques à notre disposition.
En écrivant le masque en décimal, nous avons :
194.34.56.0/255.255.255.248

En utilisant la méthode du nombre magique, nous trouvons un nombre magique de 8 (256-248)
La première adresse du réseau étant 194.34.56.0, la dernière sera 0+8-1=7 soit 194.34.56.7
Nous aurons donc sur ce réseau 8 adresses allant de 194.34.56.0 à 194.34.56.7. Sachant que 194.34.56.0 sera l'adresse de réseau et 194.34.56.7 l'adresse de broadcast, il nous restera 6 adresses pour faire notre port forwarding.

Nous avons 5 serveurs SSH, 4 serveurs web et deux serveurs DNS, ce qui fait 11 serveurs au total.

Mais comment on va pouvoir faire entrer nos 11 serveurs avec seulement 6 adresses ?

C'est possible !
Si vous avez bien compris la limitation liée au port forwarding, on ne peut avoir qu'un seul serveur d'un certain type (SSH ou web ou DNS) par adresse IP.
Or, dans cet exercice nous avons au maximum 5 serveurs d'un même type à rediriger, cela devrait donc fonctionner.
Il faudra simplement rediriger plusieurs serveurs de types différents sur une même adresse IP.

Vous comprendrez peut-être mieux avec la solution. ;)

Nous avons deux choix :

  • commencer par rediriger tous les serveurs de même type, par exemple commencer par placer tous les serveurs SSH ;

  • commencer par chaque adresse IP.

Quoi qu'il en soit, nous arriverons de toute façon au même résultat. Nous allons choisir le second choix pour que vous compreniez bien le principe.

On commence par la première adresse IP publique que nous avons à notre disposition. Nous allons rediriger depuis cette adresse un serveur de chaque type, étant donné que nous avons plus d'une seule adresse IP :

Table de port forwarding

 

 

 

@IP externe 194.34.56.1

Port externe TCP 22 (SSH)

@IP interne 10.0.1.1

Port interne TCP 22

@IP externe 194.34.56.1

Port externe TCP 80 (web)

@IP interne 10.0.1.6

Port interne TCP 80

@IP externe 194.34.56.1

Port externe UDP 53 (DNS)

@IP interne 10.0.1.10

Port interne UDP 53

Nous utilisons donc une seule adresse IP publique parmi nos 6 adresses disponibles pour rediriger 3 services différents (SSH, web et DNS) vers trois serveurs différents !

Nous pouvons maintenant passer à la seconde adresse IP publique qui va, elle aussi, accueillir trois services différents :

Table de port forwarding

 

 

 

@IP externe 194.34.56.1

Port externe TCP 22 (SSH)

@IP interne 10.0.1.1

Port interne TCP 22

@IP externe 194.34.56.1

Port externe TCP 80 (web)

@IP interne 10.0.1.6

Port interne TCP 80

@IP externe 194.34.56.1

Port externe UDP 53 (DNS)

@IP interne 10.0.1.10

Port interne UDP 53

@IP externe 194.34.56.2

Port externe TCP 22 (SSH)

@IP interne 10.0.1.2

Port interne TCP 22

@IP externe 194.34.56.2

Port externe TCP 80 (web)

@IP interne 10.0.1.7

Port interne TCP 80

@IP externe 194.34.56.2

Port externe UDP 53 (DNS)

@IP interne 10.0.1.11

Port interne UDP 53

Vu que nous avons déjà placé nos 2 serveurs DNS, il n'y aura plus besoin de placer que deux services différents (SSH et web) sur la troisième adresse IP publique disponible :

Table de port forwarding

 

 

 

@IP externe 194.34.56.1

Port externe TCP 22 (SSH)

@IP interne 10.0.1.1

Port interne TCP 22

@IP externe 194.34.56.1

Port externe TCP 80 (web)

@IP interne 10.0.1.6

Port interne TCP 80

@IP externe 194.34.56.1

Port externe UDP 53 (DNS)

@IP interne 10.0.1.10

Port interne UDP 53

@IP externe 194.34.56.2

Port externe TCP 22 (SSH)

@IP interne 10.0.1.2

Port interne TCP 22

@IP externe 194.34.56.2

Port externe TCP 80 (web)

@IP interne 10.0.1.7

Port interne TCP 80

@IP externe 194.34.56.2

Port externe UDP 53 (DNS)

@IP interne 10.0.1.11

Port interne UDP 53

@IP externe 194.34.56.3

Port externe TCP 22 (SSH)

@IP interne 10.0.1.3

Port interne TCP 22

@IP externe 194.34.56.3

Port externe TCP 80 (web)

@IP interne 10.0.1.8

Port interne TCP 80

Et nous pouvons continuer avec les services restants, ce qui nous donne une table de port forwarding finale :

Table de port forwarding

 

 

 

@IP externe 194.34.56.1

Port externe TCP 22 (SSH)

@IP interne 10.0.1.1

Port interne TCP 22

@IP externe 194.34.56.1

Port externe TCP 80 (web)

@IP interne 10.0.1.6

Port interne TCP 80

@IP externe 194.34.56.1

Port externe UDP 53 (DNS)

@IP interne 10.0.1.10

Port interne UDP 53

@IP externe 194.34.56.2

Port externe TCP 22 (SSH)

@IP interne 10.0.1.2

Port interne TCP 22

@IP externe 194.34.56.2

Port externe TCP 80 (web)

@IP interne 10.0.1.7

Port interne TCP 80

@IP externe 194.34.56.2

Port externe UDP 53 (DNS)

@IP interne 10.0.1.11

Port interne UDP 53

@IP externe 194.34.56.3

Port externe TCP 22 (SSH)

@IP interne 10.0.1.3

Port interne TCP 22

@IP externe 194.34.56.3

Port externe TCP 80 (web)

@IP interne 10.0.1.8

Port interne TCP 80

@IP externe 194.34.56.4

Port externe TCP 22 (SSH)

@IP interne 10.0.1.4

Port interne TCP 22

@IP externe 194.34.56.4

Port externe TCP 80 (web)

@IP interne 10.0.1.9

Port interne TCP 80

@IP externe 194.34.56.5

Port externe TCP 22 (SSH)

@IP interne 10.0.1.5

Port interne TCP 22

Il nous reste même une adresse IP non utilisée ! C'est la fête‌ ! :p

Ceci dit, l'exercice n'est pas encore tout à fait terminé, car il faut aussi donner accès à Internet à nos 250 utilisateurs.

Mais ça, c'est facile, il suffit d'activer la NAT dynamique sur une de nos adresses IP.

Euh, mais on a déjà 5 adresses prises par du port forwarding, donc on ne peut pas utiliser n'importe laquelle de ces adresses, non ?

En fait, si !
Si vous vous souvenez bien, les ports alloués pour les clients sont alloués au-dessus de 1024. Or, ici, les ports utilisés pour le port forwarding sont tous en dessous. Nous avons donc, sur chacune de nos 6 adresses publiques disponibles, la possibilité de mettre en place de la NAT dynamique pour nos utilisateurs !

Et hop, mission accomplie pour notre nouvel administrateur ! :D

Nous en avons donc fini avec la NAT et le port forwarding qui sont si utiles aujourd'hui !

  • Vous avez maintenant vu toutes les couches de 1 à 4.

  • Vous connaissez les protocoles réseau associés à ces couches.

  • Vous connaissez les mécanismes comme la NAT qui sont nécessaires au bon fonctionnement d'Internet.

  • Enfin, vous avez appris toute la théorie des réseaux TCP/IP dont nous avons besoin pour comprendre le fonctionnement réseau d'Internet, à travers la compréhension du modèle OSI.

Si vous êtes arrivés jusque-là sains et saufs, bravo !

Pour s'assurer que vous avez tous bien compris et assimilé le cours, nous allons faire un récapitulatif complet de ce que nous avons vu pour bien fixer les idées.

 

Exemple de certificat de réussite
Exemple de certificat de réussite