pfSense : Comment ajuster manuellement le Timeout pour les services sensibles (VoIP)

Auteur & Source :Grégory Mouchon  |  IT-Central.fr

Certaines personnes peuvent rencontrer des problèmes avec des services ou protocoles réseau plus sensibles que d’autres en termes de latence comme les services de VoIP. Ce genre de services ont souvent besoin de conserver l’enregistrement de la connexion pour une durée généralement plus importante que ce qui est souvent rencontré par défaut sur les pare-feux et routeurs. Le problème est que pfSense efface la table d’état des connexions ouvertes après une certaine période prédéfinie, très souvent inférieur aux prérequis de la VoIP.

Ces périodes prédéfinies se trouvent dans des profils ou stratégies. Ces profils se trouvent dans System> Advanced > Firewall & NAT > Firewall Optimization Options :

pfSense : choix du Profils du timeout

Les différents profils préréglés du Timeout

En générale, il est plus courant et plus facile de résoudre ces problèmes de latence en réduisant tout simplement de manière globale le niveau d’agression du pare-feu/Nat vis-à-vis de toutes les connexions ouvertes. C’est ce qu’il est possible de faire dans pfSense via ces profils.

Mais c’est bien dommage, car le trafic VoIP est presque toujours basé uniquement sur UDP. Normal, car il faut des latences très courtes que le TCP ne peut pas fournir. Du coup, le fait de modifier ces paramètres va aussi prendre en compte tous les autres protocoles, alors qu’ils n’en ont pas besoin.  Un risque supplémentaire pour problèmes d’incompatibilité dans l’avenir. Et puis c’est plus pro…merde quoi !

Voici un exemple parmi d’autres des prérequis de l’offre Centrex d’OVH:

  • Le trafic vers les réseaux 91.121.128.0/24 et 91.121.129.0/24 doit être autorisé.
  • Pour le protocole SIP : le trafic doit être autorisé sur les ports 5060 et 5962 en UDP.
  • Pour le protocole MGCP : le trafic doit être autorisé sur les ports 2424 et 2427 en UDP.
  • La plage de ports 30000 à 40000 en UDP doit également être ouverte (ports RTP, plage de son).
  • La durée de vie des sessions UDP (Time/Timeout/NAT Session) doit être supérieure ou égale à 180 secondes.
  • La fonction SIP ALG doit être désactivée sur les équipements actifs (si possible).
  • Pour une ligne sans Plug&Phone : le client SIP utilisé doit avoir une durée d’enregistrement de 1800 secondes.

Pour obtenir une qualité de communication optimale, assurez-vous que les
valeurs suivantes sont bonnes :

  • Le débit disponible recommandé est de 100kbps par ligne (envoi ET réception).
  • La gigue* idéale est inférieure à 5ms (entre votre téléphone et le serveur OVH).

Comme vous pouvez le constater, il n’y a que de l’UDP.

Si nous définissons le profil sur conservative, ce qui aura pour effet d’augmenter le Timeout sur toutes les connexions (UDP, TCP etc), il y aura inévitablement plus de consommation mémoire et CPU que nécessaire. Ce qui n’est probablement pas ce que la plupart des professionnels souhaitent, car il y a en général beaucoup de connexions réseau ouvertes en dehors d’UDP.

Pour pallier à cela, il existe une bien meilleure méthode pour obtenir exactement le même résultat. Il s’agit d’ajuster manuellement les délais d’attente pour un type de trafic en particulier. En l’occurrence pour la VoIP, UDP.

Il est possible de visualiser les délais d’attente configurés par défaut pour chacun des profils proposés dans pfSense. Ce qui nous permettra d’avoir une idée sur ce qu’il convient de changer ou pas. Par exemple nous pouvons vérifier si ces données sont conformes aux prérequis de notre prestataire VoIP ou tout autre service externalisé de VoIP ( ex: voir ci-dessus pour OVH).

Pour cela allez dans Diagnostics > Invite de commandes et tapez pfctl -st

pfSense : Command Prompt en mode navigateur

pfSense: Command Prompt en mode navigateur

Avec le profil Conservative, nous pouvons voir ceci:

pfSense : Commande Prompt pfctl -st

Et si nous revenons et sélectionnons à la place le profil Normal, plus agressif, nous pouvons voir ceci:

pfSense : Commande Prompt pfctl -st

Dans le but d’analyser nos propres besoins, nous nous rendons dans Diagnostics > States, en prenant soin de filtrer la liste avec l’IP de la cible qui nous intéresser et qui nous pose un problème (ici un téléphone IP sur offre Centrex), et de déterminer le type (State) de trafic. Il y a trois State possibles : FIRST, SINGLE ou MULTIPLE, une fois repéré vous pourrez par la suite ajuster vos timeout de manière granulaire en fonction du trafic provenant du périphérique ou service qui pose problème.

pfSense : Diagnostics/States

Donc, dans mon cas, on voit bien que mes sessions sont basées sur UDP et qu’ils ont une ou deux State associés à savoir SINGLE et MULTIPLE. Ce sont ces valeurs qui nous intéressent pour pouvoir régler nos Timeout.

Revenons dans Système > Avancé > Pare-feu et NAT, et remettons le profil par défaut Normal  dans «Option d’optimisation du pare-feu».

pfSense : Firewall Optimization Options

Faites défiler jusqu’au bas de la page dans la partie State Timeouts:

C’est à cet endroit que vous pouvez rentrer vos Timeouts. Ici pour notre démonstration et selon notre diagnostic vu précédemment, nous allons changer UDP SINGLE  et UDP MULTIPLE  afin de respecter les minimas recommandés par OVH, c’est à dire supérieur ou égale à 180 secondes pour UDP Single et beaucoup plus pour UDP Multiple.

Note: Voici d’autres pistes pouvant orienter les personnes confronté à des problèmes avec le protocole VoIP dans pfSense.

Grégory Mouchon

Share

La résolution de noms DNS

Auteur & Source : Christian Caleca

Tous les internautes vous le diront, l’URL est le gouvernail de la navigation sur le Net.

  • URL : Uniform Resource Locator /C’est la méthode d’accès à un document distant. Un lien hypertexte avec une syntaxe de la forme : <Type de connexion>://<FQDN>/[<sous-répertoire>]/.../<nom du document>. Le RFC 1034 définit les concepts de ce système ;
  • FQDN : Full Qualified Domain Name. Le nom complet d’un hôte, sur l’internet, c’est-à-dire de la machine jusqu’au domaine, en passant par les sous-domaines.

Les serveurs DNS

Ils sont en place pour permettre la résolution de de FQDN en adresses IP (et réciproquement, si nécessaire). En utilisation courante, nous exploitons un serveur DNS « récursif » dont l’adresse IP est généralement fournie par DHCP ou RADIUS, suivant le cas. Ces serveurs ne gèrent pas obligatoirement de zones particulières, mais savent effectuer les recherches nécessaires dans une architecture arborescente que nous allons voir en détail, pour résoudre n’importe quel nom d’hôte.

Cette architecture arborescente est construite au niveau mondial et nous verrons que c’est une petite merveille d’organisation.

Objectifs de ce chapitred

L’objectif avoué est double :

  • fournir aux internautes « non spécialistes » les informations de base nécessaires à la compréhension de la résolution des noms ;
  • donner des informations approfondies sur les mécanismes utilisés à ceux qui souhaitent comprendre plus en profondeur le fonctionnement de DNS.

 

Notions de base

Découverte du serveur DNS utilisé

Donc, notre fournisseur d’accès nous propose une ou plusieurs adresses de serveurs DNS récursifs, et notre système va les récupérer lors de sa configuration IP. Pour connaitre ces adresses, il faut savoir retrouver sa configuration. La façon de faire varie suivant le système d’exploitation utilisé.

Le clicodrome Windows propose quelques chemins plus ou moins détournés. Le plus simple étant sans doute d’utiliser la commande nslookup dans une invite de commandes :

Nous sommes ici dans le cas d’une machine sous MS Windows, connectée à une FreeBox en mode pont ethernet (nous n’exploitons pas les fonctions de routage). Il est également possible de récupérer l’information avec la commande :

Pour les distributions Debian GNU/Linux et dérivées, l’information se trouve généralement dans le fichier /etc/resolv.conf :

Test de résolution

Windows XP propose la commande nslookup, qui permet d’effectuer une résolution manuellement. Exemple :

Ça fonctionne, et le Réponse ne faisant pas autorité est à se mettre sous le coude, nous comprendrons plus tard ce que cela veut dire.

Dans les systèmes GNU/Linux, la commande nslookup n’est plus maintenue. Les outils à retenir sont host et dig.

Quel que soit le service que nous utilisons sur un réseau, navigateur web, client de messagerie, IRC, dès lors que nous identifions le serveur interrogé par son nom, le système devra effectuer une résolution de ce nom, de manière à trouver l’adresse IP correspondante, et exploitera les services du serveur DNS, comme nous l’avons fait avec nslookup ou host.

Analyse d’un FQDN

Prenons un exemple un peu compliqué, comme www.education.gouv.fr ; en toute rigueur, il serait plus correct d’écrire www.education.gouv.fr. (avec un point final, subtile différence).

FQDN

  • la partie la plus à gauche représente toujours un hôte ;
  • la partie la plus à droite représente toujours un domaine générique (TLD) ;
  • entre les deux, les éventuels sous-domaines et le domaine déposé de l’entité concernée.

Ainsi, un serveur (un hôte), ici www appartiendrait à un sous-domaine (education) du domaine gouv, lui-même étant un élément du domaine générique fr (la réalité n’est hélas pas si simple, comme l’avenir va le montrer). Notons qu’il serait plus judicieux de parler d’un nœud ; en effet, un hôte peut disposer de plusieurs interfaces réseau et donc disposer de plusieurs adresses IP.

Nous avons donc une structure arborescente dont l’origine est le fameux point final, que l’on omet généralement, mais qui existe bel et bien et qui représente la racine de l’arbre. Nous pouvons d’ailleurs utiliser la commande host comme ceci :

Tiens, voilà autre chose…

www.education.gouv.fr ne serait pas un « vrai nom », mais simplement un synonyme de front.webedu.men.aw.atosorigin.com ? Encore une remarque à se mettre sous le coude. En effet, DNS prévoit qu’un hôte (un nœud) puisse s’appeler de diverses manières, parfois très différentes comme c’est le cas ici. L’éclaircissement viendra sans doute dans la suite de ce chapitre.

Pourquoi « serveur récursif » ?

Dans la suite de ce chapitre, nous allons voir d’un peu plus près comment un serveur DNS est structuré et comment l’architecture arborescente d’un FQDN est en fait l’image d’une arborescence de serveurs DNS spécialisés.

A priori, un serveur DNS récursif n’a par lui-même aucune réponse, du moins aucune réponse « qui fait autorité ». en revanche il sait exactement rechercher qui et dans quel ordre il faut interroger pour obtenir une réponse « qui fait autorité ». Comme en informatique, la paresse et la mémoire sont deux qualités fondamentales, notre serveur DNS récursif va conserver dans sa mémoire pendant « un certain temps » les résultats de recherche qu’il a obtenus et s’en servira en priorité, pour avoir moins de travail. Nous étudierons tout ceci plus loin, mais cette fonctionnalité explique déjà la réponse « ne faisant pas autorité » vue plus haut. En effet, lorsqu’un serveur DNS sert une réponse issue de son cache, il signale de cette manière qu’elle ne vient pas d’un serveur de référence.

 

Notions avancées

Considérations générales

Par la pratique, nous savons que la partie la plus à droite d’un FQDN est régie par des usages stricts. En effet, cette partie représente un « Top Level Domain », Domaine de premier niveau en français. Il en existe un certain nombre, ils sont définis par l’ICANN (Internet Corporation for Assigned Names and Numbers). Un article bien documenté sur Wikipédia vous donnera plus de détails.

A l’intérieur de chaque TLD, il est possible pour toute entreprise, association, personne morale ou physique, d’enregistrer un nom de domaine. Il suffit d’en faire la demande auprès d’un « registar », bureau d’enregistrement en français. Voir encore Wikipédia pour plus de détails. Le registar vérifiera l’unicité du domaine demandé, les éventuelles conditions d’obtention et se chargera des démarches pour l’enregistrement du domaine. Le cout de l’opération varie beaucoup en fonction du registar choisi.

Nous allons voir l’influence qu’a cette opération sur la structure du DNS.

La structure de DNS

DNS

Root-Servers

Nous avons au départ une série de serveurs DNS appelés root-servers. Nous en trouvons la liste et leur implantation dans le monde sur le site root-servers.org.

Ces serveurs ne sont pas récursifs, ne savent pas résoudre les FQDN, mais savent dire quels serveurs sont spécialisés dans les divers TLDs.

Serveurs TLD

Ces serveurs DNS ne sont pas non plus récursifs, mais pour un TLD donné, savent dire quels sont les serveurs DNS qui gèrent un domaine appartenant à ce TLD.

C’est à ce niveau que le registar intervient techniquement. Une fois le nom de domaine enregistré, le demandeur doit fournir l’adresse d’au moins un serveur DNS qui saura résoudre les noms dans le domaine en question et ce DNS doit être enregistré sur les serveurs du TLD choisi.

Manipulations

Mais une petite expérience vaut mieux qu’un long discours. Nous allons utiliser notre outil host pour chercher à résoudre le FQDN www.education.gouv.fr, non plus en posant la question à notre serveur DNS récursif, mais en partant de la source, à savoir un root-server : 192.58.128.30, en utilisant la commande comme ceci :

host -v www.education.gouv.fr 192.58.128.30

  • le -v indique que l’on veut des détails (verbose) ;
  • l’adresse IP en dernier argument indique quel serveur DNS nous voulons interroger.
J-root-servers.net ne répond pas directement, comme nous pouvions nous en douter. En revanche, il nous envoie la liste des serveurs DNS compétants dans le TLD fr. Reposons donc la question au premier de la liste : a.nic.fr :
Cette réponse nous apprend deux choses :

  • gouv.fr est un « domaine sectoriel», géré par l’afnic, et donc directement par les serveurs .NIC.FR et il en va de même pour des « domaines descriptifs définis dans le .fr ;
  • pour résoudre des noms dans le domaine education.gouv.fr, il faut poser la question à ns4.atos.net ou à ns3.atos.net.

Malheureusement, nous ne disposons pas cette fois-ci des « Additionnal information » et n’avons pas l’adresse IP de ces serveurs. Il nous reste à repartir du début avec une nouvelle requête:

A peine plus avancés, interrogeons alors a.gtld-servers.net :

Nous n’avons jamais été aussi proches de la solution finale. Une dernière question à ns4.atos.net dont nous connaissons désormais l’adresse IP :

Et voilà le travail. Nous pouvons constater à quel point il peut être fastidieux et nous nous félicitons de disposer d’un bon gros serveur DNS récursif, qui fait tout ce travail à notre place. Car c’est exactement de cette manière qu’il s’y prend pour nous obtenir la réponse.

Les renseignements qu’il glane en effectuant cette recherche, il va les garder en mémoire et s’en resservira pour d’éventuelles résolutions futures. Nous verrons que pour cette raison, les serveurs « qui font autorité » indiquent une durée de validité pour les informations qu’ils donnent. Ainsi, les serveurs récursifs devront rafraichir le contenu de leur cache en fonction de dette durée de validité.

 

Construire un serveur DNS

Pourquoi faire ?

  • pour comprendre mieux comment ça fonctionne ;
  • pour disposer d’une solution de secours si le(s) serveur(s) DNS de notre fournisseur d’accès montre(nt) des signes de faiblesse ;
  • pour se créer un petit intranet sympa, même avec un nom de domaine « en bois » qui ne sera fonctionnel que sur notre LAN.

Les raisons sont-elles suffisantes ? Oui, alors allons-y. Nous avons bien un vieux PC qui traine dans un coin et qui ne demande qu’à reprendre du service. Nous y installons une Debian (Lenny dans ce qui suit), sans aucune fioriture, le strict minimum, quoi. Avec bind9 et quelques outils de base, nous ne dépasserons pas les 800 Mo sur le disque et 256 Mo de RAM pourront faire l’affaire, si notre réseau local ne dépasse pas 100 postes…

Bon gros avertissement

Ce que nous allons faire ici est destiné à l’usage exclusif de notre LAN. Aucune considération de sécurité ne sera abordée. Si le principe reste le même pour la mise en place d’un serveur DNS public, il faudra prendre en compte tous les risques d’agression et ils sont nombreux.

Qu’avons-nous ajouté sur notre machine ? Le très célèbre serveur DNS de chez ISC, nommé bind, dans sa version 9 et la commande host.

Un simple cache

En l’état, notre bind est fonctionnel, c’est un serveur DNS récursif qui sait par lui-même répondre à toutes les demandes de résolution de FQDN de l’internet. La preuve ?

L’emploi de l’option -v rend la réponse un peu indigeste, mais assez instructive.

Nous apprenons que www.altavista.fr. n’est qu’un alias de rc.yahoo.com., lui-même alias de rc.fy.b.yahoo.com. et que son adresse IP est 206.190.60.37.

En prime, nous apprenons que le domaine fy.b.yahoo.com. est géré par les serveurs DNS yf1.yahoo.com. et yf2.yahoo.com., que www.altavista.fr. ne dispose pas d’adresse IP v6, la réponse à la question ;rc.fy.b.yahoo.com. IN AAAA aurait eu une réponse et enfin, que le SOA pour ce domaine est yf1.yahoo.com.. C’est quoi un SOA ? Rappelez-moi d’en parler plus loin dans ce chapitre si jamais j’oubliais.

Toutes ces informations, c’est notre bind à nous qui les a trouvées en se débrouillant tout seul, et en 961 millisecondes seulement ! Nous n’aurions pas fait mieux.

Bien sûr nous pouvons lui poser une question plus simple (sans l’option -v) pour un nœud qui n’a rien à voir :

C’est plus lisible, il y a moins d’informations. Remarquez qu’un seul nom dispose ici de plusieurs adresses IP. C’est du « round-robin » (tourniquet en français). A quoi ça sert ? Rappelez-moi d’en parler plus loin dans ce chapitre si jamais j’oubliais…

Bref, notre bind sait parfaitement effectuer pour nous toute résolution de FQDN, nous pouvons désormais nous passer des serveurs DNS récursifs de notre fournisseur d’accès, à l’exception des clients d’Orange™ qui devront prendre quelques précautions et là encore, nous verrons pourquoi plus tard.

Par quel prodige ?

Notre installation de bind9 a produit une configuration par défaut, minimaliste, qui permet au serveur de fonctionner en mode récursif. Sans entrer dans tous les détails, allons y voir de plus près.

Tout se trouve (sur Debian) dans le répertoire /etc/bind.

Nous n’en avons pas parlé jusqu’ici, mais il faut tout de même en dire quelques mots, de la résolution inverse, celle qui consiste à retrouver un nom d’hôte à partir de son adresse IP. Ce service est peu utilisé par le particulier (entendez par là l’internaute en général). Il l’est cependant parfois par des services sur l’internet, comme par exemple SMTP, pour tenter de lutter contre le spam. Pour cette raison, nous n’en dirons pas plus sur la question.

Voyons sans plus tarder le contenu de named.conf qui, de toute évidence, constitue le fichier de configuration principal :

Déjà, nous constatons que ce fichier fait lui-même appel à deux autres fichiers de configuration, named.conf.options et named.conf.local. Nous aurons à modifier au moins l’un d’entre eux. En revanche, named.conf ne devrait (sur Debian) jamais être modifié, sauf par les mises à jour futures de la distribution.

A part ceci, nous observons des déclarations de zones, presques toutes destinées à la résolution inverse, à l’exception de celle qui sont surlignées en vert.

La zone “localhost”

Pas bien utile en général, elle permet de résoudre localhost :

Le fichier db.local a une structure que nous aurons besoin de détailler plus tard. Nous y apprenons que localhost dispose des adresses 127.0.0.1 en IPv4 et ::1 en IPv6, ce que nous savions probablement déjà.

La zone “.”

Plus intéressant est le fichier db.root :

Il contient en effet toutes les informations sur les root-servers, sans quoi, notre bind n’aurait rien pu faire. Notez que le ; est un signe de commentaire.

Le contenu de ce fichier évolue peu dans le temps et les mises à jour de la distribution suffisent normalement à le maintenir dans un état satisfaisant. Notez que certains (mais peu encore) des root-servers disposent d’une adresse IPv6.

Créer une zone

Tout ceci est bien, mais nous voudrions maintenant créer une zone pour notre intranet, avec un nom de domaine « en bois » comme par exemple maison.mrs. Le TLD n’existe pas, le domaine maison.mrs ne peut donc exister sur l’internet, mais il peut parfaitement fonctionner sur notre LAN.

Pour ce faire, il nous faut tout de même entrer un peu plus dans le détail des informations que peut donner un serveur DNS.

$TTL

Indique en secondes la durée de vie de l’information fournie. Les serveurs DNS récursifs conserveront en cache les informations récoltées pendant la durée indiquée dans ce paramètre. 0 devrait indiquer que les valeurs ne doivent pas être conservées en cache (utile pour les « dyn DNS » mais c’est une autre histoire).

SOA

Start Of Authority. Si nous avons plusieurs serveurs DNS qui servent la même zone, nous avons vu l’exemple pour yahoo.com qui en a deux, mais il pourrait y en avoir plus, il y en a un qui est le serveur « maitre », les autres n’étant que des « escalves », c’est à dire de simples répliquas. L’administrateur met à jour le maitre, qui notifiera ses esclaves (l’informaticien a une tendance à la paresse). Le champ SOA indique donc quel est le serveur « maitre ».

Nous pouvons d’ailleurs, au moyen de la commande host savoir rapidement toutes ces choses :

Tiens, il y a bien plus de deux Name Servers pour le domaine Yahoo.com, finalement… Mais tous n’ont pas forcément besoin d’être référencés sur les serveurs du TLD com, deux suffisent.

Mais quel est dans cette liste le serveur « maitre » ?

C’est ns1.yahoo.com. et nous disposons également d’autres informations, que nous allons retrouver lors de la construction de notre zone « maison ». Nous avons l’assurance que ce serveur fournira toujours la bonne information (sauf erreur de l’administrateur).

Comme nous allons le voir, le symbole @ n’a pas ici la signification habituelle at. Aussi, l’adresse e-mail du responsable de la zone est marquée : hostmaster.yahoo-inc.com.. Si nous avons une remarque à faire au responsable de la zone, nous adresserons le message à hostmaster@yahoo-inc.com.

Serial

Numéro de série qu’il faut incrémenter à chaque modification de la zone. Il est d’usage de le construire à partir de la date de modification. Ainsi, dans l’exemple précédent, nous pouvons imaginer que le serveur a été mis à jour le 29 janvier 2009, peut être à 6h GMT, ou alors ce serait la sixième modification opérée ce jour. Cette façon de faire est une recommandation, mais pas une obligation. Un simple incrément suffit. Ce numéro de série permet aux serveurs « esclaves » de savoir s’il y a eu ou non une modification de la zone depuis leur dernière synchronisation.

Refresh

Indique en seconde le temps au bout duquel les serveurs « esclaves », aussi appelés secondaires, devront demander à rafraichir leur données pour cette zone. 3600 secondes dans l’exemple, soit une heure.

Retry

Indique en secondes au bout de combien de temps un serveur esclave doit ré-essayer de se synchroniser si la tentative a échoué après le temps refresh. Ici toutes les 300 secondes, soit toutes les 5 minutes.

Expire

Si toutes les tentatives de synchronisation échouent, indique le temps (en secondes) au bout duquel les serveurs secondaires devront considérer qu’ils ne savent plus répondre aux requêtes concernant cette zone. Ici 1814400 secondes, soit 21 jours ! Mieux vaut donner une réponse peut-être fausse que de ne pas en donner du tout ?

Negative Cache TTL

Paramètre dont la signification est assez floue. Pour bind9, indique le temps pendant lequel les caches (DNS récursifs) conserverait l’information NXDOMAIN, « le domaine n’existe pas », lorsqu’un incident s’est produit.

NS, A, AAAA, CNAME et les autres

Le champ NS (Name Server) indique le nom d’un serveur de noms. Pour une zone donnée, s’il y a plusieurs serveurs de noms, il y aura plusieurs champs NS.

Le champ A (Address) fait correspondre un nom à une adresse IPv4, alors que le champ AAAA fera correspondre un nom à une adresse IPv6.

Le champ CNAME (Common Name) fait correspondre un alias à un « vrai nom ». Le « vrai nom » doit disposer par ailleurs d’un champ A, dans la même zone ou dans une autre, sur le même serveur ou sur un autre (nous en avons vu un exemple avec www.education.gouv.fr).

Il existe encore d’autres champs comme MX (Mail eXchanger), utile pour le protocole SMTP ou TXT, (utile surtout, hélas, pour « tunnelliser » n’importe quoi dans du protocole DNS, mais c’est une autre affaire).

Le symbole « @ »

Dans un fichier de configuration de zone, ce symbole représente exactement le nom de domaine de la zone. Par exemple, lorsque nous allons créer notre zone maison.mrs, écrire :

Nous pourrons écrire :

La zone maison.mrs

Nous en savons assez pour créer notre zone « maison ». Notre serveur va s’appeler debvirt.maison.mrs et dispose de l’adresse IP 192.168.0.254 :

Créons d’abord dans /etc/bind/ un fichier nommé par exemple : db.maison.mrs qui contiendrait ceci :

Ceci devrait permettre de répondre aux requêtes de type NS pour le domaine maison.mrs, de répondre aussi aux requêtes de type A pour debvirt.maison.mrs et pour test1.maison.mrs, constater aussi que les alias fonctionnent dans et hors du domaine.

Il nous faut maintenant indiquer à bind que cette zone existe. Nous allons le faire dans le fichier /etc/bind/named.conf.local :

Enfin, nous redémarrons bind avec un /etc/init.d/bind9 restart et nous contrôlons

Tout va bien, notre serveur DNS fonctionne parfaitement.

Conclusion

Encore une fois, cette configuration ne tient compte d’aucune considération sécuritaire. Cependant, nous avons un service récursif pour les résolutions sur l’internet et qui pourra gérer les noms dans notre intranet.

Note pour Orange™

De longue date, ce petit problème existe. De nombreux clients utilisent les services de smtp.wanadoo.fr pour envoyer leurs e-mails. Faisons avec notre beau bind une résolution de smtp.wanadoo.fr :

Voyons maintenant depuis une connexion Orange™, qui utilise les serveurs DNS renseignés par la connexion PPPoE :

Ce ne sont pas les mêmes… Pourquoi ?

Il faut le demander aux administrateurs de wanadoo.fr. Toujours est-il que votre vaillant Firefox (ou équivalent), si vous êtes usagers de smtp.wanadoo.fr, ne parviendra pas à poster vos messages, la résolution faite par notre cache personnel ne donnant pas les bons serveurs. La solution est de créer sur notre bind une zone wanadoo.fr de type « forward » et d’y indiquer les adresses IP des serveurs DNS fournis par la connexion Orange™. La documentation de bind indique comment réaliser cette opération. Cette documentation complète se trouve sur le site d’ISC (124 pages en anglais, pour la version 9.4, fournie avec Lenny) dont la lecture est indispensable si l’on souhaite réaliser un serveur public ou simplement découvrir toutes les possibilités de l’outil.

psst ! le round-robin ?…

Comme nous l’avons vu, il arrive parfois qu’à un FQDN corresponde plusieurs adresses IP (parfois nombreuses, comme dans le cas de smtp.wanadoo.fr). Reprenons l’exemple plus simple de www.google.fr, en posant trois fois de suite la même question à notre serveur :

Nous observons une permutation circulaire dans l’ordre des réponses (tourniquet). Comme l’application demandeuse prendra la première réponse servie, si trois clients de notre serveur veulent accéder tour à tour à www.google.fr, ils utiliseront chacun une adresse IP différente et donc probablement aboutiront à un serveur différent. Ce système est très souvent utilisé pour répartir simplement la charge sur plusieurs hôtes.

 

Un peu d’espionnage

Pour les amateurs de sniff (de réseaux), voici ce que l’on peut capturer avec un wireshark lorsque notre serveur DNS récursif effectue lorsqu’il cherche à résoudre www.education.gouv.fr alors qu’il vient juste de démarrer et que son cache est vide. Je vous laisse la joie d’analyser ceci par vous-même. Vous y découvrirez la suite de questions posées aux divers serveurs non récursifs, pour obtenir la réponse finale :

 

Share

Le routage

Auteur & Source :

Introduction

Objet de ce cours

Le but de ce document est de vous présenter comment les informations peuvent transiter d’un ordinateur à l’autre sur Internet.
Nous nous limiterons aux aspects réseau du dialogue. Tous les aspects applicatifs seront donc mis de coté (gestion des noms de machines, protocoles applicatifs, etc.)
L’étude se limitera donc aux couches 2 et 3 du modèle OSI, soit Ethernet et IPv4 dans notre cas.
Oups… ces mots sont du charabia pour vous, je vous invite alors à continuer la lecture du document qui vous présentera plus en détail chacun des concepts évoqués.

Prérequis

Pour une meilleure compréhension de ce cour, il sera nécessaire d’avoir quelques bases en ce qui concerne l’adressage IPv4 et les sous-réseaux.
Pour cela, je vous conseillerai la lecture de la faq sur les masques de sous réseau.

Réutilisation de ce cours

Vous êtes libre d’utiliser de courts extraits de ce cours, dans la mesure où vous incluez un lien permettant d’avoir accès à l’ensemble du document. Ceci dans le but de permettre à vos lecteurs d’obtenir facilement un complément d’information.
De même, vous êtes libre de copier ce cours dans son intégralité, à condition cependant d’en avertir l’auteur, et que cette utilisation soit exempte de tout caractère commercial (bannières publicitaires incluses). Cette restriction étant principalement due au plus élémentaire des respects : celui du temps que j’ai consacré à la rédaction de ce cours.
Toute autre utilisation devra faire l’objet d’un accord préalable avec l’auteur.

Décharge

L’auteur décline toute responsabilité concernant la mauvaise utilisation ou compréhension du document qui engendrerait l’écroulement de votre réseau 😉

Votre travail

La seule et unique tâche que je vous demanderai d’accomplir sera de corriger mes erreurs (aussi bien dans la cohérence des éléments avancés que pour l’orthographe), me donner des conseils sur ce qui est mal expliqué pour le rendre plus accessible, ajouter des éléments qui ont trait aux masques et rendent l’exposé plus complet, combler tout manque pour améliorer ce cours.

Mais maintenant, entrons dans le vif du sujet…

Une communication, comment ca marche ?

Que faut-il pour dialoguer ?

“Peux tu me passer le sel s’il te plait ?”
“Oui, tiens, le voici”
Il apparait souvent très simple de dialoguer, cependant, un dialogue nécessite une multitude de normes à mettre en place pour que chacun puisse s’exprimer et comprendre l’autre.
“Peux tu me passer le sel s’il te plait ?”
“Excuse me, but I don’t understand what you’re talking about”
“Pardon ? je te demande le SEL ! tu me comprends pas ou quoi ?”
Et bien non, il ne comprend pas puisqu’il n’utilise pas le même moyen pour communiquer.

On voit donc qu’il est nécessaire de se mettre d’accord sur des normes communes pour pouvoir dialoguer.

Analogie de la parole

Nous avons vu précédemment que deux personnes devaient utiliser la même langue pour se comprendre, ou du moins, que chacun d’eux comprenne la langue utilisée par l’autre.
Mais le dialogue par la parole ne se limite pas à cela.
Le dialogue met en place deux interlocuteurs, chacun à leur tour émetteur puis récepteur. Ils doivent donc avoir chacun un moyen d’écouter, et un moyen de parler. Il faudra par ailleurs un moyen de transmission de l’information.

L’émetteur sera les cordes vocales. Le récepteur le tympan. Le moyen de transmission sera les ondes sonores. Le support de transmission sera l’air. Il faudra aussi se mettre d’accord sur une langue à utiliser, qui elle-même sera régie par des règles, etc.

Nous voyons donc qu’il est nécessaire de mettre en place tout un nombre de normes pour communiquer.

Et Internet dans tout ça ?

Effectivement, vous ne voyez peut-être toujours pas le rapport que tout cela peut avoir avec Internet ?
Et bien de la même façon que nous communiquons par la parole, nous souhaitons faire communiquer des machines par Internet.
Si l’on suit le même raisonnement que précédemment, il apparait nécessaire de mettre en place des normes permettant de décrire la façon dont les ordinateurs vont communiquer entre eux.

Et effectivement, lors de la création d’Internet, un modèle décrivant les normes à mettre en place a été choisi, il s’agit du modèle OSI (open systems interconnection)

Définitions

Ce chapitre va nous permettre de présenter plusieurs notions qu’il sera nécessaire de bien comprendre pour pouvoir poursuivre la lecture du cours sans problèmes.

Le modèle OSI

En se basant sur les observations précédentes, on voit que chacun des éléments en jeu (tympans, cordes vocales, etc,.) remplit une tâche particulière. Le modèle OSI est basé sur ce principe. Il part de l’observation des tâches que nous avons à accomplir et associe ces tâches à des couches.
Le modèle est organisé en sept couches ayant chacune un ou plusieurs rôles précis.

Représentation:

  • Couche 7: Application
  • Couche 6: Présentation
  • Couche 5: Session
  • Couche 4: Transport
  • Couche 3: Réseau
  • Couche 2: Liaison de données
  • Couche 1: Physique

Chaque couche a donc un rôle précis séparé des autres. Les couches peuvent communiquer avec les couches directement adjacentes (la couche 2 pourra avoir des échanges avec les couches 1 et 3)
Ainsi, l’utilisation de l’ensemble de ces couches permet de réaliser une suite de tâches qui, regroupées, permettent la communication.

Un message à envoyer parcourt les couches de la couche 7 à la couche 1 qui représente le support de transmission.
L’analogie avec la parole serait le cerveau qui crée le message de la couche 7, jusqu’au support de transmission qui est l’air et qui représente la couche 1. Tout cela en passant par les couches intermédiaires représentées par les nerfs, les cordes vocales, les ondes, etc.
Chacune des couches formate donc bien le message et l’envoie à la couche suivante (du cerveau aux nerfs, des nerfs aux cordes vocales, etc.)

L’encapsulation

Au cours de son passage par chacune des couches, des informations relatives à chacune d’entre elles sont ajoutées pour lui permettre d’effectuer la tâche qui lui incombe, on appelle cela l’en-tête.
Cela permet d’avoir un certain nombre d’informations nécessaires à chaque couche pour effectuer son travail, et que ces informations circulent avec le message à transmettre.

Chaque couche ajoute donc sa propre en-tête à l’information d’origine. Ce procédé s’appelle l’encapsulation. Ces notions seront présentées plus en détail par la suite.
Lorsqu’une machine reçoit le message, il parcourt les couches dans le sens inverse, de la couche 1 à la couche 7 qui représente l’application qui doit recevoir le message.
De la même façon que lors de la réception d’un message auditif (ondes transportées par l’air, qui font vibrer les tympans, les tympans envoient l’information reçue par l’intermédiaire des nerfs au cerveau)

Retour à Internet

Maintenant que nous connaissons le modèle en couche et les principes qu’il représente, nous allons pouvoir nous pencher sur l’implémentation de ce modèle en couches pour la communication de machines sur Internet.

Dans ce document, nous présenterons les couches 2 et 3 qui permettent d’acheminer les données d’un ordinateur à un autre.

  • La couche 2 permet à deux machines directement connectées de dialoguer, on dit alors que les machines sont sur un même réseau (avec la définition de réseau présentée dans le lexique)
  • La couche 3 permet le dialogue entre réseaux, ce que l’on appelle le routage.

On remarque ainsi que deux machines sur un même réseau pourront dialoguer directement, mais pour parler à une machine située sur un réseau distant, il faudra passer par des machines intermédiaires qui feront la liaison entre les réseaux (on appellera ces machines intermédiaires des routeurs)

La couche physique (couche 1)

Le rôle de la couche 1

Nous ne nous attarderons pas longtemps sur la couche 1 car son rôle est simple et ne demande pas de connaissance particulières (du moins, si l’on n’entre pas dans les détails 😉

La couche 1 concerne le support physique de transport des données. Cela peut aller du simple câble transportant un signal électrique, à la fibre optique, en passant par les ondes radio. Le rôle de la couche 1 est donc d’offrir un support de transmission permettant d’acheminer les données d’un point à un autre.

La couche liaison de données (couche 2)

Les rôles de la couche 2

La couche liaison de données a pour rôle de transmettre les données de façon fiable entre des équipements directement connectés. D’autres rôles lui incombent, mais leur connaissance ne nous sera pas utile pour comprendre le transport des informations.

Nous allons donc voir dans ce chapitre comment deux machines directement liées vont faire pour dialoguer.
Sur un réseau, il y a souvent plusieurs machines connectées, il faut alors pouvoir les différencier les unes par rapport aux autres. Pour cela, nous allons les identifier individuellement grâce à des adresses.

L’adressage des machines

Pour la couche 2, ce sont les adresses MAC.
Les adresses MAC sont codées sur 6 octets, soit 48 bits donc 248 = … plusieurs milliers de milliards d’adresses possibles !
Elles sont la plupart du temps écrites par octet sous forme hexadécimale, séparés par le caractère “:”
Ce qui donne par exemple 3C:AB:35:48:FF:D2 qui est une adresse MAC.

Nous pouvons ainsi identifier chaque interface de machine individuellement. Il nous faut maintenant définir les règles qui permettront aux machines de dialoguer. Pour cela nous allons définir un langage de communication, aussi appelé protocole.

Le protocole Ethernet

Le protocole Ethernet définit le format des messages échangés. Le message de base utilisé par Ethernet est la trame. La trame est composée d’un en-tête et d’une “charge utile” contenant les informations à transmettre.
L’en-tête Ethernet contient les informations nécessaires au bon fonctionnement de la couche 2 qui pourront permettre la transmission des informations. Nous y retrouvons notamment les adresses MAC des machines participant au dialogue.

Format d’une trame Ethernet

La description suivante ne prend en compte que les informations qui nous intéressent et n’est pas le format complet d’une trame Ethernet.
La trame est composée d’une en-tête contenant les informations du protocole Ethernet, et d’un payload contenant les informations à transporter.

Nous allons voir plus en détail ce que contient l’en-tête Ethernet.

L’adresse MAC source est l’adresse de la machine qui envoie la trame.
L’adresse MAC destination est celle de la machine qui doit recevoir la trame (jusqu’ici ce n’est pas bien sorcier 🙂
Le protocole sup est le protocole utilisé par la couche supérieure (la couche 3 dans notre cas puisque Ethernet est un protocole de couche 2) Ceci est utile car quand la couche 2 reçoit le message, elle doit savoir à quel protocole de couche 3 envoyer les informations reçues (il est possible sur une machine d’utiliser plusieurs protocoles pour une même couche)

Dialogue entre deux machines

Prenons l’exemple d’une machine A qui veut envoyer le message “Bonjour” à une machine B située sur le même réseau.
Il lui suffit de connaître l’adresse MAC de B pour lui envoyer le message.
Ainsi, en lui envoyant la trame suivante, elle devrait pouvoir lui envoyer le message:

B reçoit la trame et voit que c’est son adresse MAC qui est en destination, elle lit donc le reste des informations.
Il s’agit des informations des couches supérieures (XXXXX), et enfin, du message “Bonjour”

Nous avons donc réussi grâce à la couche 2 à faire dialoguer deux machines connectées sur un même réseau.
Nous allons maintenant voir comment faire communiquer deux machines appartenant à des réseaux différents.

La couche réseau (couche 3)

Les rôles de la couche 3

La couche réseau a pour rôle d’acheminer les informations d’un réseau à un autre. C’est ce que l’on appelle le routage. Les réseaux sont donc reliés entre eux par des machines que l’on appelle routeurs. Ces routeurs vont donc recevoir les paquets sur un réseau, et les renvoyer sur l’autre. Ils ont donc une connexion sur chaque réseau.
Tous les réseaux ne pouvant pas être reliés entre eux, il va souvent falloir passer par des réseaux intermédiaires pour pouvoir envoyer un paquet d’un réseau à un autre.

La couche réseau a d’autres fonctionnalités auxquelles nous ne nous intéresserons pas ici.

Principe de fonctionnement:

Lorsque la machine A veut envoyer un message à B, le paquet va d’abord passer par le réseau 1. Puis le routeur 1 qui est connecté à ce réseau va le récupérer pour le renvoyer vers le réseau 2, et ainsi de suite jusqu’au réseau 3 où la machine B va pouvoir le recevoir.

Cela est bien joli, mais comment ca marche ? Comment le routeur 1 sait-il qu’il faut envoyer le paquet sur le réseau 2 pour qu’il puisse atteindre B ??? Et puis on sait maintenant envoyer une trame d’une machine à une autre sur un même réseau, mais sur deux réseaux différents ?

Nous allons essayer de répondre à ces questions dans les paragraphes suivant.

Quelles adresses pour la couche 3 ?

Je vous invite à lire le paragraphe 2.2 de la faq sur les masques pour comprendre l’intérêt de l’adresse IP et du masque qui lui est associé.
Une adresse IP est donc codée sur 4 octets. Elle s’écrit en décimal séparés par des points. Par exemple, 192.168.0.1 est une adresse IP.

Pourquoi encore une adresse alors que nous avons déjà l’adresse MAC ?

Il est nécessaire de différencier les adresses de couche 2 et de couche 3, car l’adressage au niveau de chacune de ces couches n’a pas le même rôle. L’adressage MAC en couche 2 permet d’identifier les machines SUR UN MEME RESEAU.
L’adressage IP en couche 3 permet d’adresser les machines SUR DES RESEAUX DISTINCTS.

Peut-on alors utiliser pour ces deux couches une seule de ces deux adresses ?

La réponse est malheureusement non.
Les adresses de couche 2 sont en rapport avec le matériel réseau utilisé (le protocole de couche 2 est géré au niveau de la carte connectée au réseau et non pas par le système d’exploitation comme les couches supérieures) il est donc difficile de modifier les adresses MAC qui sont censées être codées directement sur la carte réseau.
Cela est notamment du au fait que chaque adresse MAC doit être unique sous peine de conflit matériel, et que cette adresse doit être accessible très tôt lors du boot d’une machine.
Les adresses de couche 3 quant à elles demandent une certaine souplesse d’utilisation car on ne connait pas à priori l’adresse du réseau sur lequel une machine va se trouver.

Il y a donc une incompatibilité d’utilisation d’une adresse de couche 2 pour une adresse de couche 3, et vice versa.

Enfin, les protocoles réseau évoluant au fil du temps, il est nécessaire que chaque couche soit indépendante des autres.
Il y a d’autres raisons qui nous obligent à utiliser des adresses différentes pour des couches différentes, mais ceci n’étant pas partie intégrante du sujet, nous ne nous y attarderons pas ici, d’autant plus que les arguments présentés devraient vous avoir convaincus 🙂

Comment déterminer qu’une machine est sur mon réseau ?

Si vous avez compris la faq sur les masques de sous réseau, vous savez que le masque permet notamment à une machine de savoir quelles sont les autres machines de son réseau.
Ainsi, quand une machine veut dialoguer avec une autre, elle va d’abord regarder si cette machine est sur son propre réseau, ou si elle va devoir passer par des routeurs intermédiaires pour lui envoyer son paquet.

Ceci va être possible grâce à la table de routage.

Qu’est ce que la table de routage ?

La table de routage est un regroupement d’informations permettant de déterminer le prochain routeur à utiliser pour accéder à un réseau précis sur lequel se trouvera la machine avec laquelle nous souhaitons dialoguer.

Ainsi, si l’on reprend l’exemple du §6.1, le routeur 1 doit savoir que pour atteindre le réseau 1, il devra envoyer les informations sur son interface de gauche sur le schéma, que pour atteindre le réseau 2, il devra envoyer les informations sur son interface de droite, et enfin, pour atteindre le réseau 3, il devra envoyer les informations sur son interface de droite vers le routeur 2.

La table de routage doit pouvoir regrouper toutes ces informations. Elle les regroupe par ligne en indiquant pour un réseau donné par où il faut passer.

Pour le routeur 1 par exemple, sa table de routage doit être:

En fait, la réalité est un peu plus précise. Les interfaces peuvent être identifiés par leurs adresses ou leur type, et les réseaux sont identifiés par l’adresse du réseau et le masque associé.

Ainsi, cela se traduit en:

Où 192.168.0.0, 172.16.0.0 et 10.0.0.0 représentent les réseaux 1, 2 et 3. Et 172.16.0.254 représente l’adresse de l’interface de gauche du routeur 2.
Ainsi, pour atteindre la machine d’adresse 10.0.0.45 située sur le réseau 3, le routeur va voir dans la table de routage quelle entrée correspond au réseau contenant cette adresse. Il s’agit du réseau 10.0.0.0/255.0.0.0, et pour atteindre ce réseau, il est dit d’envoyer le paquet par l’interface ethernet 2, vers l’adresse 172.16.0.254.
Et voilà !

Ce système semble très bien, mais on en voit vite les limites sachant que le réseau Internet est composé de plusieurs millions de réseaux… Cela voudrait dire qu’il faut connaître la route vers chacun de ces réseaux pour pouvoir dialoguer avec eux.

Heureusement, une solution a été mise en place pour répondre à ce problème. Il s’agit de la route par défaut.

Qu’est-ce qu’une route par défaut ?

La route par défaut est la route qui sera utilisée lorsqu’aucune route spécifique pour aller vers la destination spécifiée n’aura été trouvée.
Ainsi, dans le cas précédent, si je voulais atteindre l’adresse 193.253.25.46, aucune entrée de ma table de routage ne m’aurait indiqué comment y aller… Ce qui fait que ma machine n’aurait pas su vers qui envoyer le paquet et qu’il serait allé directement à la poubelle 🙁

En indiquant en plus une route par défaut, cela aurait permis à ma machine d’avoir une destination, même quand aucune entrée de la table de routage ne correspondait à l’adresse demandée.
J’aurais donc envoyé mon paquet vers ma route par défaut, en fait vers le prochain routeur à utiliser, et c’est ce prochain routeur qui se serait occupé de continuer à router le paquet.
Si lui non plus n’avait pas eu de route spécifiée pour l’adresse de destination demandée, il aurait envoyé le paquet à son propre routeur par défaut, et ainsi de suite jusqu’à tomber sur un routeur connaissant la route !

Cela peut sembler un peu aléatoire comme stratégie, mais aujourd’hui, Internet est fait de telle façon que les routeurs qui le composent connaissent les routes vers toutes les destinations. Cela est mis en place grâce à des protocoles évolués permettant d’échanger des informations de routage en temps réel ! Mais ceci sort un peu de notre objectif 🙂

La table de routage pour le routeur 1 devient alors:

Cette ligne peut parfois être aussi écrite:

NB: On peut se rendre compte dans notre exemple que la route vers le réseau 10.0.0.0 n’est plus nécessaire, vu que la route par défaut pointe vers le même routeur.

Mais si l’on met une route par défaut, peut-on en mettre plusieurs ?

Cela n’a pas d’intêret dans l’absolu, et sera traité différemment selon les sytèmes. Disons qu’une table de routage normale ne devrait avoir qu’une route par défaut.

Puis-je mettre l’adresse d’un routeur n’étant pas sur mon réseau comme passerelle ?

Non !
Et d’ailleurs, cela n’aurait pas de sens, puisqu’une passerelle est censée nous indiquer un chemin pour sortir de notre réseau. Si on indique l’adresse d’une machine en dehors de notre réseau, c’est que l’on en est déjà sorti !

La conséquence est que les passerelles indiquées dans une table de routage devront toujours appartenir à mon propre réseau, ou du moins, à l’un des réseaux auxquels appartiennent mes interfaces, si j’en ai plusieurs.

Vu que ma machine a plusieurs interfaces, dois-je avoir plusieurs tables de routage ?

Là encore la réponse est non. La table de routage est censée contenir toutes les informations de routage pour votre machine (ou routeur) quel que soient le nombre d’interfaces. D’ailleurs, vous avez pu voir dans la table de routage du routeur 1 que les routes contenaient des informations sur ses deux interfaces.

Il existe cependant des fonctions avancées de routage avec plusieurs table, mais nous n’en sommes pas là 😉

Mais maintenant que nous savons comment une machine fait pour aiguiller un paquet, il nous reste à savoir quelles informations de couche 3 ce paquet devra contenir pour que le routage puisse être effectué. Le message de base utilisé par IP est le datagramme.

Format d’un datagramme IP

De la même façon qu’avec Ethernet, la couche IP (couche 3) va nécessiter un certain nombre d’informations pour pouvoir effectuer les tâches qui lui icombent comme le routage. A la manière de la trame Ethernet, le datagramme IP se compose d’une en-tête IP, et d’un payload contenant les informations à transporter.

Nous allons voir plus en détail ce que contient l’en-tête IP, même si nous ne décrivons pas l’ensemble de l’en-tête, mais juste les informations qui nous intéressent.

Celle-ci ressemble fort à ce que nous avons vu précédemment pour Ethernet, nous ne détaillerons donc pas son contenu.

Maintenant que nous avons décrit la couche 3, nous allons pouvoir voir plus en détail comment se fait l’interface avec la couche 2

Cas particulier des liaisons point à point

Il existe cependant des cas où l’utilisation d’une table de routage est un peu différente, et où la précision d’une passerelle n’est pas nécessaire.
C’est quand deux machines sont reliées directement l’une à l’autre. On parle alors de liaison point à point.
Dans ce cas, nous sommes sûrs qu’un paquet envoyé par une des machines à une extrémité de la connexion va être reçu par l’autre machine. Il suffit alors dans la table de routage de spécifier l’interface de sortie.

Les interactions entre les couches 2 et 3

Trame et datagramme, qu’est-ce qui circule sur le réseau ?

Et bien oui, nous avons vu que les couches 2 et 3 avaient chacune leur propre format de message utilisé pour transporter l’information, mais le quel des deux circule vraiment sur le réseau ?
Si nous répondons la trame, cela voudra dire que notre trame sera contrainte de rester sur le réseau local, puisque la couche 2 ne permet pas d’aller d’un réseau à l’autre.
Si nous répondons le datagramme, de la même façon, nous ne serons pas capables de dialoguer avec les machines de notre réseau, et donc pas avec les routeurs à utiliser pour aller vers d’autres réseaux.

Donc la réponse semble être: ni l’un ni l’autre…
Ou plutôt: l’un et l’autre !

Effectivement, nous avons parlé au §3.2 d’encapsulation des informations. C’est exactement le principe qui va être utilisé ici. Les informations de couche 2 et 3 vont être mises ensemble avec les informations à transmettre.
Le paquet ainsi formé contiendra ainsi l’ensemble des informations nécessaires au transport de l’information.
C’est donc une trame qui circulera sur le réseau, et cette trame Ethernet contiendra le datagramme IP.

Maintenant, comment est organisée cette encapsulation pour que chaque couche retrouve facilement ses informations ?

L’organisation de l’encapsulation

Comme nous l’avons vu au §3.2, lors de l’émission d’une information, chaque couche ajoute son en-tête. Le paquet final ainsi formé contient donc les informations de toutes les couches, ainsi que l’information d’origine. La dernière couche ayant apporté son en-tête est la couche 2 (la couche 1 n’a pas besoin d’apporter de l’information, ou du moins, cela est transparent pour nous)

Ainsi, quand le paquet arrive à sa destination, ce sont les informations de couche 2 qui sont accessibles en premier, et ça tombe bien puisque ce sont elles dont nous avons besoin en premier pour recevoir le message !

La réception d’un message se passe donc ainsi:

La carte réseau de ma machine reçoit la trame suivante

La couche 2 regarde l’adresse MAC de destination et si cela correspond bien à notre machine, elle envoie les informations à la couche 3 en prenant soin d’enlever l’en-tête Ethernet, qui ne servira plus.

De la même façon, la couche 3 regarde l’adresse IP de destination, et si cela correspond bien à UNE DES adresses IP de notre machines, elle envoie les informations à la couche 4, et ainsi de suite.
Si par contre, le datagramme est à destination d’une autre adresse IP, notre machine va router ce paquet vers sa vraie destination (cela n’est vrai que si le routage est activé sur la machine, mais c’est normalement le cas pour un routeur 🙂

En fin de chaîne, l’application impliquée dans le dialogue va recevoir les informations qu’elle attend:

Tout cela semble marcher parfaitement comme une machine bien huilée. Cependant, il nous manque encore quelques informations pour pouvoir avoir une compréhension globale du fonctionnement du routage.
Par exemple, nous savons déterminer l’adresse IP du prochain routeur à utiliser, mais c’est de l’adresse MAC dont nous avons besoin pour dialoguer avec lui directement sur notre réseau… Il faut donc pouvoir récupérer une adresse MAC en fonction d’une adresse IP. Pour cela, nous allons devoir utiliser un protocole particulier, dédié à cette fonction, que l’on appelle ARP.

Qu’est-ce que le protocole ARP ?

Le protocole ARP permet d’obtenir une adresse MAC en fonction d’une adresse IP.

Reprenons notre problème.
Le routeur 1 veut envoyer un paquet vers l’adresse 10.0.0.45 du réseau 3. Comme nous l’avons vu précédemment, le routeur regarde dans sa table de routage pour savoir où il va devoir envoyer le paquet.
La table de routage lui dit que pour atteindre le réseau 10.0.0.0/255.0.0.0 qui contient l’adresse 10.0.0.45, il faut passer par le routeur dont l’une des adresses d’interface est 172.16.0.254.
Le nouveau travail du routeur est donc d’envoyer le paquet vers 172.16.0.254.
Cette adresse IP étant sur son propre réseau (notre routeur a une interface dans le réseau 172.16.0.0./255.255.0.0), il faut connaître son adresse MAC pour pouvoir lui envoyer le paquet. Pour connaître son adresse MAC, l’idéal serait de lui demander, mais pour lui demander, il faudrait connaître son adresse MAC !!!

Et on tourne en rond 🙁 Vu qu’aucune autre machine du réseau n’est censée connaître l’adresse MAC de 172.16.0.254, nous ne pouvons pas non plus leur demander. Il faut donc trouver un moyen de s’adresser à l’adresse MAC de 172.16.0.254 sans la connaître !

Et si vous vous rappelez bien du cours sur les masques de sous réseau, vous avez peut-être deviné que nous avons un mécanisme à notre disposition nous permettant de faire cela…
Il s’agit du principe de broadcast ! En envoyant ma question à tout le monde, je suis sûr que la machine 172.16.0.254 va le recevoir.

Je peux donc envoyer à tout le monde ma requête ARP demandant:

  1. Qui a l’adresse IP 172.16.0.254 ? et quelle est son adresse MAC ?
    1. Toutes les machines reçoivent cette question, mais seule 172.16.0.254 va me répondre.
  2. Je suis 172.16.0.254 et mon adresse MAC est 04:CF:65:84:C5:E2

J’ai ainsi pu récupérer l’adresse MAC de 172.16.0.254, et je peux désormais lui envoyer le paquet à transmettre.

Nous avons ainsi réussi à faire la liaison souhaitée entre l’adresse IP connue et l’adresse MAC recherchée 🙂

Une question se pose quand même, car si toutes les machines doivent envoyer des messages à tout le monde à chaque fois qu’elles souhaitent communiquer, on va vite encombrer le réseau…

Pour répondre à ce problème, ARP utilise une solution de cache local. C’est à dire que lorsqu’une requête ARP va être effectuée, la réponse à cette requête va être gardée pendant un certain temps pour pouvoir être réutilisée.
Ce temps est paramétrable, et est souvent de l’ordre de quelques minutes.
Ainsi, si mes machines continuent de dialoguer ensemble, il n’y aura plus besoin de faire des broadcasts ARP, il suffira d’aller chercher dans le cache ARP l’information.

D’ailleurs, le fonctionnement de ARP veut que le système aille d’abord regarder dans le cache ARP si l’information s’y trouve, avant de faire le broadcast ARP (ce qui semble normal 🙂

Bon, et bien nous avons maintenant en notre possession toutes les connaissances devant nous permettre de comprendre en partie le dialogue entre deux machines distantes. Allons-y !

Dialogue entre deux machines distantes

Présentation du dialogue

Nous allons reprendre le même type de schéma que nous avonsvu précédemment, avec une machine A souhaitant envoyer un message à une machine B sur Internet.

Interface gauche routeur 1: 193.25.25.254/24
Interface droite routeur 1: 140.40.40.14/28
La partie Internet n’est pas mise en détail mais représente quelques de routeurs successifs avant le routeur 2.

NB: Comme petit exercice, vous pouvez vous demander pourquoi je n’ai pas précisé le masque de sous réseau pour la machine B ?

Emission du message par A

La machine A veut envoyer le message “bonjour” à B.
Comme nous l’avons vu à travers le modèle OSI, ce message va traverser les différentes couches du modèle pour que chacune y apporte l’information nécessaire à l’accomplissement de sa tâche. Dans le modèle TCP/IP utilisé sur Internet, les couches 5 et 6 ne sont pas utilisées (on peut en déduire que les fonction effectuées par ces couches ne sont pas nécessaires, ou qu’elles sont prises en charge par une autre couche) Le message passe donc par la couche 4 qui, une fois son en-tête ajouté, envoie le paquet à la couche 3.

La couche 3 reçoit le paquet (segment TCP) et l’adresse de destination 232.32.32.32. Elle va voir dans sa table de routage (celle de la machine sur laquelle on est, cad A) à qui envoyer les informations.

Table de routage de A:

Elle n’a pas de route spécifique pour l’adresse 232.32.32.32, ce sera donc la route par défaut qui sera utilisée.
A doit donc maintenant envoyer le paquet à l’interface 193.25.25.254 du routeur 1. A retourne voir dans sa table de routage par quel interface sortir pour envoyer le datagramme à 193.25.25.254.
Elle doit maintenant connaître l’adresse MAC de l’interface 193.25.25.254. Pour cela, elle va voir dans son cache ARP si elle ne trouve pas l’information. Si c’est le cas, elle connait l’adresse MAC, sinon, il faut qu’elle fasse un broadcast ARP pour la trouver.
Maintenant que la couche 3 connait l’adresse MAC destination, elle peut envoyer le datagramme IP (en-tête IP + segment TCP) et l’adresse MAC destination à la couche 2.

La couche 2 reçoit le datagramme et y ajoute son en-tête Ethernet. La trame est maintenant prête à être envoyée sur le réseau.

La trame circule sur le réseau jusqu’à sa destination qui est l’adresse MAC de 193.25.25.254.

Réception du message par le routeur 1 intermédiaire

Le routeur 1 intermédiaire reçoit la trame. La couche 2 regarde l’adresse MAC en destination, et comme c’est l’adresse MAC de l’interface 193.25.25.254, le datagramme IP est envoyé à la couche 3.

La couche 3 reçoit le datagramme et regarde l’adresse IP de destination. Ce n’est l’adresse d’aucune des interfaces du routeur 1, donc le paquet devra être routé vers sa destination. Le routeur va donc voir sa table de routage pour voir vers qui renvoyer le paquet.

Table de routage du routeur 1:

Il n’y a pas de route spécifique pour l’adresse 232.32.32.32. C’est donc la route par défaut qui sera utilisée.
La prochaine machine à qui envoyer le paquet est donc 140.40.40.13. Le routeur retourne voir dans sa table de routage par quel interface sortir pour atteindre 140.40.40.13. C’est la seconde ligne de la table qui contient l’information et l’interface à utiliser est l’interface 2.
De la même façon que précédemment, il faut trouver son adresse MAC pour lui envoyer la trame contenant les informations nécessaires. On la trouve facilement grâce aux mécanismes ARP. Le routeur 1 peut donc envoyer la trame vers le prochain routeur.

Nous n’allons pas détailler la suite, le passage par chaque routeur étant identique à celui-ci.

Les informations arrivent donc jusqu’au routeur 2 grâce aux mécanismes de routage d’Internet 🙂
Celui-ci va comme précédemment renvoyer le paquet qui ne lui est pas destiné vers la machine B qui est sur son réseau.

Réception du message par la machine B

  1. La trame arrive donc sur l’interface de la machine B.
  2. L’adresse MAC en destination est bien celle de cette interface (Cette adresse MAC aura été trouvée grâce au mécanisme ARP mis en oeuvre par le routeur 2, vous suivez bien ?)
  3. La couche 2 renvoit donc le datagramme IP à la couche 3 IP.
  4. La couche 3 reçoit le datagramme et regarde l’adresse IP de destination. C’est bien l’adresse d’une des interfaces de la machine !
  5. La couche 3 va donc pouvoir envoyer les informations à la couche 4, qui enverra elle-même le message “bonjour” à la couche 7 applicative.

Et hop, nous avons réussi ainsi à envoyer le message “bonjour” de la machine A à la machine B !!! Magisme…

Bien sûr, certains points n’ont pas été détaillés et demandent des connaissances plus poussées pour pouvoir être expliqués. Mais cela fera l’objet d’un autre cours 😉

Quelques remarques

Et bien oui, même si tout s’est bien déroulé dans notre dialogue, et que vous avez tout parfaitement compris, il est bon de mettre en valeur certains aspects de la communication.

  • Les adresses MAC source et destination sont modifiées à chaque passage par un routeur

Oui, et c’est normal. Ces adresses MAC sont relatives à la couche 2 dont le rôle principal est le dialogue sur un réseau local. Donc les adresses MAC utilisées dans une trame doivent être en relation avec le réseau sur lequel on se situe, pas celui d’à coté 😉

Que se passerait-il si une adresse MAC de destination était celle d’une interface étant sur un autre réseau ?
Ça ne marcherait plus 🙁 car la trame serait envoyée sur le réseau local (en couche 2) et ne trouverait pas de machine ayant cette adresse MAC. La trame serait donc perdue.
Les adresses MAC contenues dans une trame Ethernet doivent donc toujours être en rapport avec le réseau local. C’est ce qui explique qu’elles doivent être modifiées à chaque passage sur un nouveau réseau.

  • Par contre, les adresses IP source et destination n’ont pas été modifiées durant le transport de A à B

Oui, et cela est encore normal !
La couche 3 concerne les informations de routage, donc sur des adresses appartenant à des réseaux distants. Ces adresses représentent donc les deux extrémités du dialogue et ne doivent pas être modifiées.

Que se serait-il passé si on avait modifié les adresses IP source et destination à chaque passage d’un routeur ?
Ici encore, nous aurions eu des problèmes. Le datagramme IP serait bien arrivé jusqu’au routeur 1, et lui l’aurait renvoyé vers le prochain routeur sur Internet en mettant comme adresse IP destination 140.40.40.13. Le routeur ayant cette adresse 140.40.40.13 aurait bien reçu le datagramme, mais voyant que c’était lui l’adresse IP de destination, il aurait pris le paquet pour lui et la communication se serait arrêtée là (la couche 4 n’aurait pas reconnu ce paquet comme appartenant à une connexion valide) et badaboum…
Il est donc impératif de ne pas modifier les adresses IP lors du transport du datagramme. Le dialogue IP se fait de bout en bout entre les réseaux distants, alors que le dialogue Ethernet se fait de proche en proche sur chacun des réseaux traversés.

Voici un petit dessin pour schématiser les deux principes que nous venons d’évoquer.

NB: Il est cependant possible que les adresses IP source et destination soient modifiées dans le cas de la traduction d’adresse. Ceci ne faisant pas partie intégrante du sujet, je vous invite à lire la faq sur la nat (traduction d’adresse)

  • Une autre remarque que nous pouvons faire, est la foultitude d’étapes qui ont été utilisées pour un simple envoi de “bonjour”

Et encore, ce n’est rien, en rentrant plus dans le détail, il y a encore bon nombre d’autres communications que nous n’avons pas détaillées qui sont nécessaires au dialogue.
Et dire que tout cela se fait en quelques milisecondes et est complètement transparent pour l’utilisateur final…
C’est quand même bô Internet :-))

Mini lexique

Adresse IP

L’adresse IP est un numéro codé sur 4 octets permettant d’identifier une machine de façon unique sur le réseau.

Réseau logique

On appelle réseau logique un ensemble d’adresses IP appartenant à une même plage d’adresses. Cette plage est notamment définie par l’adresse de réseau et le masque associé.

Connexion/interconnexion

Ces deux termes sont souvent employés indifféremment, à tort !
On parle de _connexion_ de _machines_ au sein d’un même réseau, et d’_interconnexion_ de _réseaux_ entre eux.
La connexion se rapporte alors à une notion de couche 2, alors que l’interconnexion est une notion de couche 3.

Sous-réseau

On définit un sous-réseau comme un sous-ensemble d’une plage d’adresses réseau. C’est grâce au masque que l’on peut définir un sous-réseau au sein d’un réseau, et ainsi découper un réseau en plusieurs sous-réseaux.

ARP

ARP est un protocole permettant de déterminer une adresse MAC en fonction d’une adresse IP.

Annexes

Ressources utilisées

Je me suis inspiré des connaissances que j’ai pu glaner un peu partout depuis que je fais du réseau, sans m’appuyer sur un document en particulier.
Je dois cependant avouer que j’en ai beaucoup appris depuis que je donne des cours en école d’ingénieur et qu’il faut répondre aux multiples questions de ces petites têtes blondes 🙂
Ça m’a permis de me remettre en question et d’approfondir des sujets que je pensais maîtriser.
La route vers le savoir est encore longue ! 🙂

Pour aller plus loin sur le sujet, je vous conseillerai la lecture du livre de Richard Stevens “Le TCP/IP illustré” qui est une mine d’or pour comprendre les mécanismes TCP/IP.

Et sans oublier l’excellente faq sur les firewalls de Stéphane Catteau dont je me suis inspiré pour la mise en forme.
Disponible sur:
http://fr.comp.securite.free.fr/firewall.txt
N’hésitez pas à la consulter, on y apprend plein de choses.

Remerciements

Je remercie notamment les personnes suivantes pour leur lecture assidue du cours durant sa réalisation et leurs conseils précieux.

  • David Blevin
  • Eric Belhomme
  • Annie D.

Versions HTML, latex, pdf ou doc disponibles

Il n’y a pas encore de version latex, pdf ou doc disponible, mais je ne doute pas qu’une bonne âme va passer par là et aura le courage de s’y coller 🙂
Toute traduction du document est aussi bienvenue !!!

Faq sur la NAT

Si cette faq vous a plu et que vous avez appris des choses, j’en ai fait une autre sur la NAT (traduction d’adresses)

Faq sur les masques de sous-réseau

Si cette faq vous a plu et que vous avez appris des choses, j’en ai fait une autre sur les masques de sous réseau.

Conclusion

Arf… je vois le bout du tunnel…
Je dois bien avouer que j’ai du tourner le problème dans tous les sens afin de trouver une façon cohérente d’aborder les principes de routage.
J’espère que le résultat est à la hauteur de mes attentes, et surtout qu’il vous aura permis de comprendre un peu mieux le fonctionnement d’un des principes majeur d’Internet.
La compréhension en profondeur du routage n’est vraiment pas une chose aisée. D’ailleurs, il me reste un bon nombre de questions en suspend auxquelles je vais essayer de répondre. Peut être dans une suite du cours 🙂
En tout cas, je compte sur vous pour me faire un retour efficace sur ce document. Je manipule beaucoup des concepts abordés tous les jour. Mon oeil sur le sujet n’est donc pas très neuf, et il est probable que je n’explique pas bien certaines notions.
Si des éléments ne vous semblent pas clair lors de la lecture du document, je vous invite à me contacter à l’adresse spécifiée dans l’en-tête du document pour me faire part de vos remarques. Ne négligez pas vos remarques, elles me sont extrêmement utiles pour améliorer ce document, ainsi que ma compréhension personnelle.
Merci de votre attention, vous pouvez éteindre votre ordinateur.

Share

La translation d’adresse (NAT)

Auteur & Source :

Introduction

Objet de ce cours

Avec le développement croissant du monde de l’Internet, et notamment des liaisons à connexions permanentes comme le câble ou l’ADSL, de plus en plus de particuliers utilisent de la NAT pour partager leur accès Internet, parfois même sans le savoir. 😉

Il m’a donc semblé opportun de faire un petit cours rassemblant les idées principales qui tournent autour de la NAT, et d’essayer de les clarifier. Ce cours se limitera à l’étude de la NAT sur le modèle TCP/IP.

Pour comprendre les mécanismes mis en œuvre dans la NAT, vous aurez besoin d’avoir quelques connaissances sur le modèle TCP/IP, et notamment sur les couches 3 et 4 du modèle OSI (IP et TCP/UDP).

Définitions

L’identification des machines

Pour envoyer du courrier à un ami, vous utilisez son adresse postale. Ainsi vous êtes sûr que le paquet que vous envoyez arrivera à la bonne personne. Et bien pour les ordinateurs, c’est pareil. Quand vous connectez votre ordinateur à un réseau (Internet par exemple), il possède une adresse qui l’identifie d’une façon unique pour que les autres ordinateurs du réseau puissent lui envoyer des informations.

L’adressage IP

Nous avons parlé d’adresses pour les machines, il est temps maintenant de définir ces adresses. On parle d’adresse IP (Internet Protocol), car il s’agit du protocole qui permet d’identifier les machines et de router les informations sur Internet. Ces adresses sont codées sur 4 octets, soit 32 bits. Ce qui nous permet d’avoir 232 adresses disponibles (un peu plus de 4 milliards d’adresses).

Même si ce chiffre dépasse de loin le nombre de machines présentes sur Internet, nous allons bientôt manquer d’adresses disponibles, notamment parce qu’un grand nombre de ces adresses sont gâchées.

En attendant un nouveau standard d’adressage qui permette d’avoir plus d’adresses disponibles (IPv6), il a fallu trouver des solutions temporaires. La NAT a notamment été une réponse à cette future pénurie d’adresses.

Nous allons voir en quoi elle consiste, et quels sont ses avantages et inconvénients.

Qu’est-ce que la NAT ?

Le terme barbare NAT représente les initiales de « Network Address Translation », ou « Traduction d’Adresse Réseau » en français. Mais il est souvent utilisé pour représenter différents concepts que nous allons différencier, notamment NAT statique, NAT dynamique, PAT, IP masquerading, etc.

Si l’on s’en tient intrinsèquement à la définition du terme NAT, cela représente la modification des adresses IP dans l’en-tête d’un datagramme IP effectué par un routeur.

On verra par la suite quelles sont les différentes applications possibles.

On parlera de SNAT quand c’est l’adresse source du paquet qui est modifiée, et de DNAT quand il s’agit de l’adresse destination (voir le mini lexique 11.4).

La NAT statique

Le principe

La NAT statique, se base sur l’association de n adresses avec n adresses. C’est-à-dire qu’à une adresse IP interne, on associe une adresse IP externe. Dans ce cas, la seule action qui sera effectuée par le routeur sera de remplacer l’adresse source ou destination par l’adresse correspondante.

Pourquoi ne puis-je pas accéder à Internet avec une adresse privée ?

On prend l’exemple suivant:

           Machine 1
10.0.0.1/24
|
|
Interface interne routeur
10.0.0.254/24
<ROUTEUR>
Interface externe routeur
193.22.35.42/24
|
|
Internet

La machine 1 veut envoyer un paquet sur Internet, vers www.ohmforce.com, par exemple. Donc dans l’en-tête IP, l’adresse en destination est celle de www.ohmforce.com, et en source c’est 10.0.0.1. Si jamais il n’y avait pas de translation d’adresse, le paquet arriverait bien a la machine www.ohmforce.com, mais celle-ci essaierait de renvoyer sa réponse a 10.0.0.1 qui n’est pas une adresse routée sur Internet ! (Elle fait partie d’une classe d’adresses réservées pour les réseaux privés) Et notre machine 1 n’obtiendrait jamais de réponse…

Ainsi, une machine ayant une adresse privée ne pourra pas recevoir de réponse à ses requêtes sans un mécanisme supplémentaire.

Le fonctionnement de la NAT statique

Nous avons vu qu’une machine ayant une adresse privée ne pouvait pas dialoguer sur Internet avec celle-ci, donc pour résoudre ce problème, on va lui donner une adresse publique virtuelle qui va lui permettre d’accéder à Internet.

Ainsi, un routeur (la plupart du temps la passerelle d’accès à Internet) va modifier dans l’en-tête IP du paquet l’adresse source 10.0.0.1 pour mettre une adresse valide sur Internet 193.22.35.43 (dans notre exemple, on choisit volontairement une adresse supplémentaire pour ne pas prendre la même que le routeur, ce qui l’empêcherait, lui, de pouvoir dialoguer sur Internet).

Le paquet va donc arriver à sa destination, et celle-ci va pouvoir le renvoyer à 193.22.35.43 qui est une adresse valide sur Internet. Le paquet va arriver jusqu’au routeur qui a fait l’association entre 193.22.35.43 et 10.0.0.1, il va donc modifier l’adresse destination 193.22.35.43 et mettre à la place 10.0.0.1, et renvoyer le paquet sur le réseau local.

Ainsi, la machine 1 est vue de l’Internet avec l’adresse 193.22.35.43. S’il s’agit d’un serveur web, il suffit d’envoyer une requête HTTP vers cette adresse pour obtenir le site web.

La NAT statique nous a permis de rendre une machine accessible sur Internet alors qu’elle possédait une adresse privée. On a simplement fait une association entre une adresse privée et une adresse publique : 10.0.0.1 <–> 193.22.35.43

Avantages et inconvénients de la NAT statique

En associant une adresse IP publique à une adresse IP privée, nous avons pu rendre une machine accessible sur Internet. Par contre, on remarque qu’avec ce principe, on est obligé d’avoir une adresse publique par machine voulant accéder à Internet. Cela ne va pas régler notre problème de pénurie d’adresses IP…

D’autre part, tant qu’à donner une adresse publique par machine, pourquoi ne pas leur donner cette adresse directement plutôt que de passer par un intermédiaire ?

À cette question, on peut apporter plusieurs éléments de réponse. D’une part, il est souvent préférable de garder un adressage uniforme en interne et de ne pas mêler les adresses publiques aux adresses privées. Ainsi, si on doit faire des modifications, changements, interventions sur le réseau local, on peut facilement changer la correspondance entre les adresse privées et les adresses publiques pour rediriger les requêtes vers un serveur en état de marche.

D’autre part, on gâche un certain nombre d’adresses lorsqu’on découpe un réseau en sous-réseaux (adresse de réseau, adresse de broadcast, etc.), comme lorsqu’on veut créer une DMZ pour rendre ses serveurs publics disponibles. Avec la NAT statique, on évite de perdre ces adresses. Malgré ces quelques avantages, le problème de pénurie d’adresses n’a toujours pas été réglé. Pour cela, on va se pencher sur la NAT dynamique au paragraphe 4.

Les deux paragraphes suivants concernent des détails techniques, sinon vous pouvez directement passer au paragraphe 4.

Problèmes de routage liés à la NAT statique (proxy ARP)

Les problèmes montrés ne sont pas toujours rencontrés lors de l’implémentation de la NAT statique. Si celle-ci est bien faite, tous les mécanismes décrits devraient être implémentés de façon transparente pour l’utilisateur.

Ce qui va suivre demande d’avoir quelques notions sur le fonctionnement de la pile TCP/IP.

Un premier problème rencontré est celui de la redirection d’un paquet vers l’adresse virtuelle de la NAT statique.

On considérera l’exemple précédent auquel on ajoute le premier routeur rencontré sur Internet.

         Machine 1
10.0.0.1/24
|
|
Interface interne routeur
10.0.0.254/24
<ROUTEUR>
Interface externe routeur
193.22.35.42/24 + Adresse IP virtuelle statique pour machine 1 193.22.35.43/24
|
|
Interface interne
193.22.35.254/24
<Routeur Internet>
Interface externe
|
|
Internet

La machine 1 fait une requête vers le site www.ohmforce.com.

Le paquet est NATé au niveau du routeur avec comme adresse source 193.22.35.43, ainsi, le site web www.ohmforce.com renvoie sa réponse vers cette adresse. Le paquet est routé sur Internet et arrive sur le routeur Internet (celui qui précède le routeur de l’entreprise ou du particulier).

Celui-ci regarde l’adresse de destination et observe qu’elle se situe sur le même réseau qu’une de ses interfaces. Ainsi, elle a maintenant besoin de l’adresse MAC de la machine 193.22.35.43 pour lui envoyer le paquet.

Elle fait donc une requête ARP en demandant « Quelle est l’adresse MAC de la machine ayant 193.22.35.43 comme adresse IP ? » Or, sur ce réseau, aucune machine n’a cette adresse puisqu’il s’agit d’une adresse virtuelle. Il faut donc que le routeur (193.22.35.42) réponde lui-même à cette requête ARP. C’est ce que l’on appelle faire proxy ARP.

Quand vous faites de la NAT statique, le proxy ARP est souvent automatiquement implémenté, cependant, il est bon de connaître ce mécanisme si ce n’est pas le cas.

Il y a plusieurs façons de pallier ce problème :

  • soit mettre en place soi-même un mécanisme de proxy ARP sur la machine faisant la NAT statique ;
  • soit ajouter une entrée statique dans la table ARP du routeur Internet (pas le routeur faisant la NAT, mais le premier routeur rencontré après celui-ci sur Internet) ;

Commande arp sous Windows :

  • soit ajouter une route host statique pour chacune des adresses virtuelles.

Sous Windows :

Problèmes de routage liés à l’utilisation de la NAT statique (routage sur la passerelle)

Un second problème peut survenir sur l’équipement qui fait la NAT. Revenons à l’exemple précédent.

Le routeur Internet envoie le paquet au routeur de l’entreprise. Celui-ci reçoit la trame Ethernet, voit que c’est son adresse MAC qui est en destination, il envoie donc le contenu des données à la couche IP. Celle-ci voit que c’est l’adresse 192.22.35.43 (l’adresse virtuelle de notre machine) qui est en destination. Il va voir dans la table de routage, et là, il peut y avoir un problème…

Soit une route spécifique existe pour cette adresse pour rediriger le paquet vers le réseau interne, soit ce n’est pas le cas, et il sera renvoyé sur l’interface externe du routeur, étant donné que l’adresse de destination appartient au même réseau que son interface externe 193.22.35.42 !

Pour que la NAT fonctionne, il faut donc qu’il y ait une route spécifique vers le réseau interne. Ou alors que la règle de NAT inverse soit implémentée avant le routage, comme ça l’adresse destination sera 10.0.0.1 qui sera routée correctement vers le réseau interne.

Dans notre cas :

Ainsi, quand le routeur recevra un paquet à destination de l’adresse virtuelle 193.22.35.43, il le redirigera bien vers l’adresse réelle de la machine, 10.0.0.1.

Et hop, ça marchera. 😉

La NAT dynamique (translation avec ports)

Le principe

La NAT dynamique est aussi appelée IP masquerading. Contrairement à la NAT statique, la NAT dynamique associe une seule adresse à n adresses (ou pour être plus précis, m adresses à n adresses, les adresses pour sortir étant choisies dans un pool). Ainsi, on peut associer une adresse publique à n adresses privées et permettre ainsi à un grand nombre de machines ayant des adresses privées d’accéder à Internet !

Par contre, nous verrons que cette méthode possède quelques inconvénients. Et contrairement à la NAT statique, le routeur qui effectue la NAT devra à la fois modifier les adresses IP mais aussi les ports TCP/UDP (ce que l’on appelle PAT, Port Address Translation).

Le fonctionnement de la NAT dynamique

Le fonctionnement est un peu différent de celui de la NAT statique. Nous allons notamment voir pourquoi il faut faire de la PAT et non pas une simple traduction des adresses IP.

Reprenons l’exemple précédent :

        Machine 1
10.0.0.1/24
|
|
Interface interne routeur
10.0.0.254/24
<ROUTEUR>
Interface externe routeur
193.22.35.42/24
|
|
Internet

Cette fois, c’est l’adresse publique de l’interface externe du routeur 193.22.35.42 qui va être utilisée pour sortir. Ainsi, lorsque le paquet arrive à la machine de destination, www.ohmforce.com par exemple, celle-ci le renvoie vers l’adresse 193.22.35.42. Le routeur reçoit donc ce paquet et voit que l’adresse de destination est lui-même !

Comment peut-il alors savoir si le paquet est pour lui ou une machine en interne ?

C’est grâce aux ports TCP/UDP qu’il va pouvoir faire la différence. Ainsi, si une machine en interne fait une requête avec comme port TCP source 2356, le routeur pourra savoir que lorsqu’il recevra un paquet avec comme port destination 2356, il faut le rediriger vers la machine en interne qui a initialisé la connexion.

Mais je vois déjà pointer les questions :

« Oui, mais si deux machines du réseau interne initialisent des connexions avec le même port TCP/UDP ? hein ? alors ? Comment qu’on fait pour savoir qui est qui ? hein ? alors ? »

Et vous auriez raison de vous les poser !

Mais tout a été prévu pour pallier ce problème. En fait, le routeur remplace le port TCP/UDP source par un nouveau qu’il choisit lui-même. Ainsi, comme c’est lui qui les choisit, il n’en choisira pas deux identiques, et pourra identifier chacune des connexions, magique…

On reprend donc depuis le début le fonctionnement.

La machine 10.0.0.1 veut se connecter au site www.ohmforce.com, elle envoie donc un paquet avec comme adresse source la sienne, 10.0.0.1, et comme port source un port quelconque supérieur à 1024, soit par exemple 5987. Le paquet arrive au routeur qui fait la NAT, il remplace donc l’adresse IP source par la sienne 193.22.35.42, et la PAT en remplaçant le port TCP/UDP source 5987 par un de son choix, 10000 par exemple.

Il garde ces informations de correspondance bien au chaud dans une table NAT.

Le paquet arrive à www.ohmforce.com qui le renvoie à 193.22.35.42. Le paquet arrive au routeur, il voit que l’adresse destination est lui-même, il regarde donc le port destination TCP/UDP qui est 10000. Il va regarder dans la table NAT pour avoir la correspondance, et bingo ! Il sait qu’il faut envoyer ce paquet à 10.0.0.1, tout en ayant modifié le port destination 10000 en 5987 qui est le port sur lequel 10.0.0.1 a initialisé la connexion.

Et voilà.

On peut ainsi masquer autant de machines que l’on veut derrière une seule adresse publique !

Avantages et inconvénients de la NAT dynamique

Comme nous l’avons vu, la NAT dynamique permet à des machines ayant des adresses privées d’accéder à Internet. Cependant, contrairement à la NAT statique, elle ne permet pas d’être joint par une machine de l’Internet.

Effectivement, si la NAT dynamique marche, c’est parce que le routeur qui fait la NAT reçoit les informations de la machine en interne (adresse IP, port TCP/UDP). Par contre, il n’aura aucune de ces informations si la connexion est initialisée de l’extérieur… Le paquet arrivera avec comme adresse de destination le routeur, et le routeur ne saura pas vers qui rediriger la requête en interne.

La NAT dynamique ne permet donc que de sortir sur Internet, et non pas d’être joignable. Elle est donc utile pour partager un accès Internet, mais pas pour rendre un serveur accessible.

De plus, étant donné que l’on peut « cacher » un grand nombre de machines derrière une seule adresse publique, cela permet de répondre à notre problème de pénurie d’adresses.

Par ailleurs, les machines n’étant pas accessibles de l’extérieur, cela donne un petit plus au niveau de la sécurité. 😉

Sans le savoir, si vous avez chez vous un routeur fourni par votre fournisseur d’accès et que votre machine a une adresse en 192.168.X.X, vous n’êtes pas directement joignable par les vilains pirates d’Internet !

Problèmes liés à la NAT dynamique (ICMP)

La NAT dynamique demande l’utilisation des ports TCP/UDP, cependant, tous les protocoles utilisés sur un réseau n’utilisent pas obligatoirement ces ports, notamment les protocoles ICMP, PPTP, Netbios, etc.

Prenons par exemple le protocole ICMP. Se limitant à la couche 3, il n’utilise pas de port TCP ou UDP. Il n’est donc pas possible de faire de la NAT dynamique de façon classique.

Une méthode spécifique doit être implémentée pour permettre la NAT du trafic ICMP.

Pour cela, au lieu de se baser sur les ports TCP/UDP, on peut se baser sur l’identifiant ICMP présent dans l’en-tête du message ICMP.

Ainsi, le mécanisme est exactement le même, mis à part que l’on utilise cet identifiant, plutôt que les ports TCP/UDP.

Il faut donc implémenter spécifiquement ce type de NAT pour le protocole ICMP.

Par ailleurs, certains paquets ICMP contiennent dans leur payload des informations concernant les datagrammes IP qui ont causé l’erreur. Le routeur faisant la NAT doit donc aussi modifier les informations contenues dans le payload pour que l’information apportée à la machine émettrice soit pertinente.

Problèmes liés à la NAT dynamique (FTP)

Le protocole FTP a un fonctionnement un peu particulier (voire carrément dégueulasse…). Il utilise deux connexions en parallèle. L’une pour le contrôle de la connexion, l’autre pour le transfert des données.

Le FTP peut fonctionner selon deux modes différents, actif ou passif. En mode passif, pas de problème, les connexions sont initialisées de l’intérieur pour chacun de ces deux canaux. Par contre, pour le mode actif, la connexion de contrôle est d’abord initialisée de l’intérieur, et quand des données sont demandées, c’est le serveur qui initialise la connexion de données à partir de l’extérieur. Et comme nous le savons, il n’est pas possible d’initialiser de connexion à partir de l’extérieur du réseau avec de la NAT dynamique.

Un autre problème du protocole FTP est qu’il contient des données se rapportant aux adresses des machines. Ainsi quand les adresses sont NATées, cela pose problème…

Donc pour que le FTP puisse fonctionner, on est obligé d’utiliser un module qui soit capable de lire les informations contenues dans les données FTP. Pour faire cela, on utilise un proxy (voir paragraphe 7) qui sera capable de suivre la connexion et de modifier les données FTP pour la rendre possible.

Dans un cas comme celui-ci, ce n’est plus un simple module NAT à ajouter, mais un proxy à part entière

Statique ou dynamique ?

Quand faire de la NAT statique ?

Nous avons vu que la NAT statique permettait de rendre disponible une machine sur Internet, mais qu’il fallait par contre une adresse IP pour que ce serveur soit joignable.

Il est donc utile d’utiliser la NAT statique quand vous voulez rendre une application disponible sur Internet, comme un serveur web, mail ou un serveur FTP.

Quand faire de la NAT dynamique ?

La NAT dynamique permet d’une part de donner un accès à Internet à des machines possédant des adresses privées, et d’autre part d’apporter un petit plus en terme de sécurité.

Elle est donc utile pour économiser les adresses IP et donner un accès à Internet à des machines qui n’ont pas besoin d’être joignables de l’extérieur (comme la plupart des utilisateurs). D’autre part, même quand on possède assez d’adresses IP, il est souvent préférable de faire de la NAT dynamique pour rendre les machines injoignables directement de l’extérieur.

Par exemple, pour un usage personnel de partage de l’ADSL ou du câble, on utilise souvent la NAT dynamique pour partager son accès, étant donné que les machines n’ont pas besoin d’être jointes de l’extérieur.

Puis-je combiner ces deux méthodes ?

Oui, et c’est même souvent la meilleure solution lorsque l’on a à la fois des machines offrant un service, et d’autres qui n’ont besoin que de se connecter à Internet.

Ainsi, on économisera les adresses IP grâce aux machines NATées dynamiquement, et l’on utilisera exactement le bon nombre d’adresses IP publiques dont on a besoin.

Il est donc très intéressant de combiner ces deux méthodes.

Comment rendre joignables les machines de mon réseau local alors que je n’ai qu’une seule adresse publique ?

Explication du problème

Nous avons vu que dans le cas de la NAT dynamique, les machines du réseau local ne pouvaient pas être jointes de l’extérieur. Cela est plutôt un plus pour la sécurité, mais si l’on doit offrir des services comme un serveur FTP ou web, ça devient problématique.

C’est notamment le cas quand on possède un accès ADSL ou câble : une seule adresse publique vous est fournie, et il devient alors compliqué de rendre disponibles plusieurs serveurs du réseau local.

Une solution à ce problème est le port forwarding.

Le port forwarding, qu’est-ce que c’est ?

Le port forwarding consiste à rediriger un paquet vers une machine précise en fonction du port de destination de ce paquet.

Ainsi, lorsque l’on n’a qu’une seule adresse publique avec plusieurs machines derrière en adressage privé, on peut initialiser une connexion de l’extérieur vers l’une de ses machines (une seule par port TCP/UDP).

Prenons l’exemple précédent et disons que la machine 10.0.0.1 possède un serveur web. Maintenant, on configure le routeur pour qu’il redirige les connexions arrivant sur le port 80 vers la machine 10.0.0.1. Et hop, on rend notre machine ayant une adresse privée disponible depuis l’extérieur !

Ainsi, le port forwarding nous a permis de rendre nos machines du réseau local joignables d’Internet, même si l’on ne possède qu’une seule adresse IP publique !

Le port mapping, qu’est-ce que c’est ?

Le port mapping est un peu équivalent au port forwarding. Il consiste simplement à rediriger la requête sur un port différent que celui demandé. Par exemple, si l’on fait tourner un serveur web sur le réseau local sur le port 8080 et qu’on veut le rendre accessible pour les internautes, on redirige le port 80 vers notre serveur sur le port 8080. Ainsi, les clients externes auront l’impression de s’adresser à un serveur sur le port usuel pour le web, 80.

Les limites du port forwarding

Hé oui, le port forwarding ne peut pas non plus répondre parfaitement à toutes les questions qu’amène la NAT dynamique.

Ainsi, on a vu que l’on ne pouvait associer qu’une adresse de machine à un port donné. Si l’on possède plusieurs serveurs web en local et que l’on veut les rendre accessibles, il faudra trouver une autre astuce…

Le gros point fort en sécurité

Disons que j’ai un serveur web sous Windows. Je veux rendre le service web, mais pas que tous les autres ports ouverts par défaut et souvent vulnérables soient accessibles. Et bien avec du port forwarding, seuls les ports que je forwarderai seront joignables. C’est un énorme avantage de sécurité par rapport à la NAT statique.

Les proxys

Qu’est-ce qu’un proxy ?

Un proxy est un mandataire pour une application donnée. C’est-à-dire qu’il sert d’intermédiaire dans une connexion entre le client et le serveur pour relayer la requête qui est faite. Ainsi, le client s’adresse toujours au proxy, et c’est lui qui s’adresse ensuite au serveur. Un proxy fonctionne pour une application donnée, HTTP, FTP, SMTP, etc. Il peut donc modifier les informations à envoyer au serveur, ainsi que celles renvoyées par celui-ci. La contrepartie est qu’il faut un proxy par application.

Cependant, beaucoup de proxys sont en fait des multiproxys qui sont capables de comprendre la plupart des applications courantes.

Ce qu’un proxy n’est pas

Un amalgame est souvent fait entre les fonctionnalités qu’on peut apporter à un proxy, et le proxy lui-même.

Ainsi, on pense souvent qu’un proxy doit faire de la NAT, ou du serveur de cache, mais ce ne sont que des fonctionnalités ajoutées. Effectivement, il est souvent utile d’ajouter des fonctions de cache à un proxy, vu que c’est lui qui centralise l’accès au web. Ainsi, si quinze personnes demandent le même site web, il ne sera chargé qu’une fois puis gardé dans le cache du proxy.

D’autre part, la NAT est elle aussi souvent indispensable pour qu’un proxy fonctionne, vu qu’il est censé être un intermédiaire, il faudra qu’il modifie l’adresse source du paquet pour que la réponse passe par lui. Cependant, même si c’est ce qui est le plus souvent utilisé, ce n’est pas obligatoire.

Si ces fonctionnalités sont souvent utiles et utilisées, ce n’est pas pour autant qu’il faut penser qu’elles sont synonymes de proxy.

Vaut-il mieux faire de la NAT ou avoir un proxy ?

Avantages du proxy

Comme nous l’avons vu, un proxy est dédié à un protocole (une application) particulier. Ainsi, il est capable d’interpréter le trafic et notamment de cacher les informations. On diminue ainsi le trafic et augmente la bande passante par la même occasion. On peut aussi autoriser ou non l’accès à certaines parties d’un site, à certaines fonctionnalités, etc. On a donc un bon contrôle de ce qui transite sur le réseau, et l’on sait quels protocoles peuvent circuler.

Avantages de la NAT

Contrairement au proxy, la NAT est indépendante des applications utilisées. On peut donc faire passer la plupart des protocoles que l’ont veut.

Alors ? NAT ou proxy ?

La réponse est bien sûr… ça dépend ! Vous êtes déçus ? Il ne faut pas, car si vous avez bien lu et compris ce qui précède, vous devriez être en mesure de faire votre choix vous-même en fonction de ce que vous avez (adresses, matériel, etc.) et de ce que vous voulez faire (applications, politique de sécurité, etc.).

Personnellement, j’ai une petite préférence pour la NAT car elle ne limite pas ce que je peux faire sur le réseau, je n’ai donc pas de mauvaises surprises quand j’utilise un nouveau protocole un peu exotique. 😉

La sécurité et la NAT

La NAT dynamique permet-elle d’améliorer ma sécurité ?

La NAT dynamique permet de rendre les machines d’un réseau local inaccessibles directement de l’extérieur, on peut donc voir cela comme une sécurité supplémentaire. Mais cela n’est pas suffisant et il est indispensable d’utiliser un filtrage si l’on veut obtenir un bon niveau de sécurité. La NAT dynamique seule ne peut pas être considérée comme une sécurité suffisante.

Est-ce utile pour la sécurité d’utiliser un proxy ?

Un proxy travaille au niveau 7 du modèle OSI, c’est-à-dire qu’il est capable d’interpréter et de modifier les informations du protocole sur lequel il travaille. Ainsi, il peut vérifier le contenu de ce qui est reçu de la part du serveur et en interdire ou modifier le contenu selon la politique choisie. L’utilisation d’un proxy pour des protocoles critiques est donc souvent utile si on veut avoir une bonne vision de ce qui se passe.

La NAT est elle compatible avec IPSEC ?

Si on veut être précis, la réponse est oui. Cependant, la norme IPSEC ayant différentes implémentations, ce n’est pas toujours le cas. D’ailleurs la plupart des constructeurs ont créé leurs propres solutions IPSEC pour traverser de la NAT.

Le problème vient de l’encryption de l’en-tête IP par les participants au tunnel IPSEC. Si l’adresse IP est modifiée pendant le trajet du paquet, elle ne sera pas la même à l’arrivée que celle qui a été encryptée au départ, et après comparaison, le paquet sera détruit.

Cependant, en se plaçant en mode ESP et en faisant du tunneling, c’est la totalité du paquet qui est encryptée, et un nouvel en-tête est ajouté à celui-ci. Ainsi, la comparaison ne se fera pas sur l’en-tête modifié, mais sur celui contenu dans les données du paquet. Mais cette solution n’est pas toujours possible.

Je ne crois pas qu’il existe de norme pour résoudre ce problème, mais une solution semble apporter une réelle satisfaction au problème cité. Elle est aujourd’hui utilisée par beaucoup de constructeurs, la NAT Traversal ou NAT-T. Il s’agit d’encapsuler les données dans un tunnel UDP. Ainsi, de la même façon qu’en mode tunnel et ESP, l’en-tête modifié par la NAT ne sera pas utilisé pour le test d’authentification.

Ainsi, il est souvent possible de mettre en place un VPN IPSEC, même si on utilise de la NAT.

Utilitaires pour faire de la NAT

Sous Windows

Voici quelques noms de produits qui permettent entre autres de faire de la NAT, une présentation plus précise sera peut-être faite par la suite si cela s’avère utile. Je n’ai pas testé ces produits, vos remarques et expériences sont donc les bienvenues. 😉

WinGate, WinRoute Lite, NAT32, TCPRelay, etc.

Sous UNIX

Ipchains, IPFilter, Netfilter…

 

Mini lexique

IP ou Internet Protocol

IP est un protocole de couche 3 qui permet principalement d’identifier les machines à l’aide d’adresses et de router les informations entre réseaux logiques. Il permet aussi de faire de la fragmentation de paquets.

TCP ou Transmission Control Protocol

TCP est un protocole de couche 4 qui permet d’identifier et de contrôler les connexions entre machines. La gestion des flux et des erreurs est aussi intégrée à ce protocole.

SNAT ou Source NAT

Le Source NAT correspond à la modification de l’adresse source dans un paquet translaté. Il est notamment utilisé pour la NAT dynamique, mais aussi pour la NAT statique lorsqu’on veut sortir du réseau local.

DNAT ou Destination NAT

Le Destination NAT correspond à la modification de l’adresse destination dans un paquet translaté. Il est utilisé pour la NAT statique, lorsqu’on veut accéder à un serveur sur un réseau local.

PAT ou Port Address Translation

Le PAT correspond à la modification du port utilisé par le routeur pour relayer sa connexion. Le routeur « prend la place connectée » du poste émetteur.

En résumé

Le routeur de NAT statique remplace à la volée une adresse (privée) de source par une autre (virtuelle) correspondant dans le réseau local public de celui-ci (pour voir la réponse routée vers son propre réseau, où il lui appartient de la capter par ProxyARP !). Le routeur de NAT dynamique remplace à la volée l’adresse privée de source par sa propre adresse, en modifiant aussi dynamiquement le port de source d’origine (PAT…). Certaines applications gérant plusieurs connexions TCP (cas du FTP) nécessitent alors un proxy application spécifiquement accordé au(x) protocole(s) considéré(s) pour compléter sa gestion.

Annexes

Ressources utilisées

Je n’ai pas utilisé beaucoup de documents aussi bien en ligne que sur papier. Les réponses et connaissances apportées proviennent en majeure partie des informations que j’ai pu glaner en furetant sur le net, et notamment sur les newgroups fr.comp.reseaux.ip et fr.comp.reseaux.ethernet.

Je me suis quand même inspiré de la RFC 1631.

Et notamment de l’excellente FAQ firewalls de S. Catteau dont je me suis inspiré pour la mise en forme.

Autres FAQ

Si cette FAQ vous a plu et que vous avez appris des choses, j’en ai fait une autre sur les masques de sous réseau.

J’en ai fait une autre sur le routage.

Conclusion

La NAT est aujourd’hui un élément important en réseau étant donné son énorme déploiement à travers le monde pour faire suite à l’annonce de la pénurie d’adresses IPv4.

J’ai essayé de rendre la compréhension de cette technique la plus accessible possible. Cependant, il faut impérativement avoir quelques notions en réseau pour pouvoir bien comprendre les points délicats qu’elle comporte.

Il y a et il y aura sûrement encore beaucoup de choses à dire sur le sujet. Vos remarques sont donc encore et toujours les bienvenues, aussi bien pour y ajouter des idées, que pour enlever le superflu. Maintenant, si je revois passer des questions sur la NAT, j’aurai au minimum un droit de flagellation sur les personnes incriminées. 😉

Remerciements Developpez

Vous pouvez retrouver l’article original ici : La NAT. Éric Lalitte a aimablement autorisé l’équipe « Réseaux » de Developpez.com à reprendre son article. Retrouvez tous les articles de Eric Lalitte sur cette page.

Nos remerciements à sevyc64 et mumen pour leur relecture technique et orthographique.

 

Share

Les masques de sous-réseau

Auteur & Source :

Introduction

Objet de ce cours

Dans le monde des réseaux, on utilise souvent des termes inintelligibles pour le commun des mortels n’ayant pas une formation informatique poussée. Les masques en font partie, d’autant plus que leur compréhension et leur utilisation n’est pas toujours simple (au départ)
Le but de ce cours est de présenter de façon la plus compréhensible possible ce que sont les masques, à quoi ils servent, comment bien les utiliser et se familiariser avec.
Pour cela, nous traiterons aussi quelques sujets annexes qui nous permettront de mieux comprendre l’utilité des masques, comme les réseaux logiques, quelques notions de routage, etc.

Votre travail

La seule et unique tâche que je vous demanderai d’accomplir sera de corriger mes erreurs (aussi bien dans la cohérence des éléments avancés que pour l’orthographe), me donner des conseils sur ce qui est mal expliqué pour le rendre plus accessible, ajouter des éléments qui ont trait aux masques et rendent l’exposé plus complet, combler tout manque pour améliorer ce cours. Maintenant que c’est sur un wiki, vous n’avez plus d’excuses pour faire ces modifications facilement !

Définitions

L’identification des machines

Pour envoyer du courrier à un ami, vous utilisez son adresse postale. Ainsi vous êtes sûr que le paquet que vous envoyez arrivera à la bonne personne. Et bien pour les ordinateurs, c’est pareil. Quand vous connectez votre ordinateur à un réseau (Internet par exemple), il possède une adresse qui l’identifie d’une façon unique pour que les autres ordinateurs du réseau puissent lui envoyer des informations.

La segmentation des réseaux

Imaginez un énorme réseau comme Internet où chacune des machines serait obligée de connaître l’ensemble des millions d’autres machines (et notamment leurs adresses) et de savoir comment y accéder. Cela obligerait nos pauvres ordinateurs à avoir des tables énormes contenant l’ensemble de ces informations. Cela induirait aussi des temps de réponses très grands pour parcourir cette table.
Pour répondre à cette problématique, on a segmenté cet énorme réseau en différents petits réseaux. Et c’est au sein de ces petits réseaux que l’on donne des adresses aux machines pour leur envoyer l’information. Ainsi, il suffit de connaître l’adresse du réseau pour envoyer l’information à une machine de celui-ci, et c’est à l’intérieur de ce réseau que l’information sera redirigée vers la bonne machine.
C’est exactement comme lorsque vous envoyez un paquet par la poste, vous mettez le nom de la ville, le paquet arrive à la poste de la ville, et c’est elle qui distribue le paquet à la bonne adresse.

Une seule adresse pour le prix de deux

Comme vous l’avez compris, il nous faut deux adresses pour identifier une machine, une pour le réseau et une pour la machine elle-même. Cependant, l’adressage qui a été choisi pour les machines ne définit qu’une seule adresse. Vous me direz que ce n’est pas suffisant. Et bien si ! Il suffit de segmenter cette adresse en deux parties distinctes, l’une pour le réseau, et l’autre pour la machine. C’est là où le masque entre en jeu, c’est lui qui joue le rôle de séparateur entre ces deux adresses.

Définition empirique du masque

Le masque est un séparateur entre la partie réseau et la partie machine d’une adresse IP.

Pourquoi maîtriser les masques ?

L’utilisation et la maîtrise des masques doit pouvoir vous permettre d’une part, de savoir ce que vous manipulez, et d’autre part d’optimiser le fonctionnement de votre réseau. Effectivement, l’utilisation des masques vous permettra de segmenter de la façon la plus correcte l’adressage de votre réseau, et ainsi de séparer les machines sensibles du reste du réseau, limiter les congestions, et prévoir l’évolution de votre réseau, etc. Malheureusement, la séparation d’un réseau en plusieurs sous-réseaux n’a pas que des avantages. L’un des désavantages majeurs est notamment la complexification des tables de routage étant donné le plus grand nombre de réseaux à router.

Adresse IP et masque

L’adressage IP

Nous avons parlé d’adresses pour les machines, il est temps maintenant de définir ces adresses.
On parle d’adresse IP, car il s’agit du protocole qui permet d’identifier les machines et de router les informations sur Internet. Ces adresses sont codées sur 4 octets (voir chapitre 4 sur le codage binaire) et sont la plupart du temps écrites en numérotation décimale en séparant les octets par des points. Ça donne quelque chose comme ça: 192.168.132.24

Nombre de machines

En y regardant d’un peu plus près, on peut calculer le nombre de machines que l’on peut identifier à l’aide de cet adressage. Ainsi, on utilise 4 octets, soit 32 bits, soit encore 232 adresses. Or 232 = 4 294 967 296, on peut donc définir un peu plus de 4 milliards d’adresses !!!

La séparation grâce au masque

Cependant, nous avons vu qu’il fallait séparer cette adresse en deux parties pour pouvoir identifier à la fois le réseau et l’adresse. Mais comment se fait cette séparation ? En fait, le masque comme l’adresse IP est une suite de 4 octets, soit 32 bits. Chacun des ces bits peut prendre la valeur 1 ou 0. Et bien il nous suffit de dire que les bits à 1 représenteront la partie réseau de l’adresse, et les bits à 0 la partie machine. Ainsi, on fera une association entre une adresse IP et un masque pour savoir dans cette adresse IP quelle est la partie réseau et quelle est la partie machine de l’adresse.

Le couple adresse IP et masque

Le masque servant à faire la séparation en deux parties sur une adresse IP, il est donc indissociable de celle-ci. Une adresse seule ne voudra rien dire puisqu’on ne saura pas quelle est la partie réseau et quelle est la partie machine. De la même façon, un masque seul n’aura pas de valeur puisqu’on n’aura pas d’adresse sur laquelle l’appliquer. L’adresse IP et le masque sont donc liés l’un à l’autre, même si l’on peut choisir l’un indépendamment de l’autre.

Le codage

Le codage binaire

Nous utilisons tous les jours un système de numération décimale. Avec donc 10 symboles (0123456789) qui nous permettent d’énumérer toute sorte de nombres en les plaçant dans un certain ordre. Cette place est primordiale puisqu’elle représente le passage aux dizaines, centaines, milliers, etc. Ainsi, tout nombre peut se décomposer en puissances de 10, par exemple:
324 = 300 + 20 +4 = 3*102 + 2*101 + 4*100
Cependant, il existe d’autres modes selon la base dans laquelle on se place. Lorsque l’on utilise la base 2, on se place en numération binaire où seuls deux symboles sont utilisés (01) On peut, de la même façon, décomposer tout nombre en puissance de 2.
324 = 256 + 64 + 4 = 1*28 + 0*27 + 1*26 + 0*25 + 0*24 + 0*23 + 1*22 + 0*21 + 0*20

Pourquoi un codage binaire pour les ordinateurs ?

Pour les ordinateurs, c’est ce choix du codage binaire qui a été fait. Pourtant, il aurait été plus simple d’utiliser la base 10 avec laquelle nous sommes familiers. Cependant, les informations liées aux ordinateurs circulent sur des fils électriques. Sur ces fils, il est difficile de distinguer plus de deux états pour le signal, on peut par exemple choisir un état à 0 volts, et un autre pour 5 volts. On se retrouve donc avec deux valeurs possibles. C’est pour cela qu’on a choisi un codage binaire avec deux valeurs possibles, 0 et 1.

Qu’est-ce qu’un octet ?

Un octet est une séquence de huit bits. C’est donc un nombre codé avec huit bits. Ainsi, si on transpose sa valeur en décimal, on obtient un nombre qui peut varier entre 0 et 255. Donc, dans une adresse IP, on ne pourra pas trouver d’autres nombres que ceux compris entre 0 et 255. Une adresse comme 192.65.25.428 ne peut pas être une adresse IP valide vu que son dernier octet n’est pas compris entre 0 et 255.

Ecriture binaire de l’adresse IP

Nous avons vu que l’adresse IP était composée de 4 octets écrits en notation décimale, séparés par des points, par exemple: 192.168.25.132
Cette adresse peut aussi bien s’écrire en binaire:

Nous verrons par la suite pourquoi il est utile de revenir à cette notation pour bien comprendre le fonctionnement des masques.

Les masques

Récapitulatif

Nous avons déjà vu plusieurs aspects importants des masques qu’il faudra toujours essayer de garder à l’esprit :

  • Codés sur 4 octets, soit 32 bits,
  • Ils permettent de faire la séparation entre la partie réseau et la partie machine de l’adresse IP,
  • La partie réseau est représentée par des bits à 1, et la partie machine par des bits à 0,
  • Le masque ne représente rien sans l’adresse IP à laquelle il est associé

Comment représente-t-on un masque ?

Comme le masque est codé sur 32 bits, voici un exemple possible de masque:
__________Réseau_________ _Machine
11111111.11111111.11111111.00000000
Ce qui s’écrit en décimal 255.255.255.0
Maintenant, plusieurs questions peuvent se poser.

  • Jusqu’ici je comprends, mais comment je peux associer ce masque à une adresse IP, et quel sera le résultat ?
  • Pourquoi les bits à 1 sont séparés de ceux à 0 ?

Comment le masque et l’adresse IP sont ils associés ?

Prenons par exemple une machine qui a pour adresse IP 192.168.25.147. Il nous faut lui associer un masque pour savoir quelle partie de cette adresse représente le réseau. Associons lui le masque précédent 255.255.255.0. On remarque que les bits des trois premiers octets sont à 1, ils représentent donc la partie réseau de l’adresse, soit 192.168.25, le 147 permettant d’identifier la machine au sein de ce réseau.
Dans cet exemple, on remarque qu’un octet a été réservé pour l’adresse machine, ce qui nous donne 28 = 256 adresses disponibles pour les machines sur le réseau 192.168.25. Les adresses disponibles pour les machines seront donc:
192.168.25.0 (réservée pour le réseau, voir 5.4)
192.168.25.1 à 192.168.25.254
192.168.25.255 (réservée pour le broadcast, voir 5.4)
On observe donc que c’est le masque qui détermine le nombre de machines d’un réseau. Ainsi, on verra par la suite qu’on choisira le masque en fonction du nombre de machines que l’on veut installer.

Adresses spécifiques (réseau, broadcast)

Il existe des adresses spécifiques au sein d’un réseau. La première adresse d’une plage ainsi que la dernière ont un rôle particulier. La première adresse d’une plage représente l’adresse du réseau. Celle-ci est très importante car c’est grâce à elle qu’on peut identifier les réseaux et router les informations d’un réseau à un autre. La dernière adresse d’une plage représente ce que l’on appelle l’adresse de broadcast. Cette adresse est celle qui permet de faire de la diffusion à toutes les machines du réseau. Ainsi, quand on veut envoyer une information à toutes les machines, on utilise cette adresse. Dans notre exemple, l’adresse de réseau sera donc 192.168.25.0, et l’adresse de broadcast 192.168.25.255. On remarque donc qu’il ne nous reste plus que 254 adresses pour identifier nos machines. Ainsi, à chaque fois que l’on choisira un masque en fonction du nombre de machines que l’on veut adresser, il faudra tenir compte de ces deux adresses…

Les bits à 1 et à 0 doivent ils être contigus ?

Dans l’exemple de masque que nous avons choisi, nous avons vu que les bits à 0 et à 1 étaient regroupés. Cela n’est pas une obligation, mais cela facilite énormément l’exploitation du réseau. En conservant la contiguïté des bits, les adresses de nos machines au sein du réseau se suivent. Ce ne serait pas le cas si l’on avait choisi un masque avec des bits non contigus.
Exemple, si on choisit le masque suivant:
11111111.11111111.11111110.00000001
Ici, on a comme précédemment 8 bits qui représentent la partie machine, par contre, ils ne sont plus à la même place. Cela se traduit en décimal par le masque suivant 255.255.254.1. On voit donc que les adresses dont le dernier bit est à 1 ne seront pas dans le même réseau que celles dont le dernier bit est à 0. Ce qui veut dire que les adresses dont le dernier octet est impair ne seront pas dans le même réseau que les adresses paires. Dans cet exemple, cela reste encore facile de différencier les adresses paires et impaires, mais lorsque l’on fait des mélanges plus compliqués entre les bits significatifs, cela devient très vite inextricable. On conservera donc toujours la contiguïté des bits significatifs !!!

Quelles adresses pour les masques ?

Etant donné que l’on conserve la contiguïté des bits, on va toujours rencontrer les mêmes nombres pour les octets du masque.
Ce sont les suivants:

  • 11111111
  • 11111110
  • 11111100
  • 10000000
  • 00000000

Soit en décimal:
255, 254, 252, 248, 240, 224, 192, 128, et 0.
Ainsi, on peut tout de suite dire si un masque semble valide au premier coup d’œil. Un masque en 255.255.224.0 sera correct alors qu’un masque en 255.255.232.0 ne le sera pas (à moins de ne pas vouloir respecter la contiguïté des bits) Vous pouvez aller voir tous les masques possibles dans la RFC suivante: Rfc 1878

Faire fi de l’écriture par octets

L’écriture de l’adresse IP selon 4 octets séparés par un point est facile à utiliser. Mais quand on se penche sur le problème d’un peu plus près, on se rend compte qu’elle n’est pas très adaptée… Elle a deux défauts principaux:

  • Écriture en décimal alors que l’on résonne en binaire
  • Séparation des octets par des points

Ainsi, lorsqu’on utilise des masques où la séparation réseau/machine se fait sur un octet (tous les bits des octets sont soit à 1, soit à 0) cela est simple. Prenons par exemple le réseau 192.168.25.0/255.255.255.0. Toutes les machines commençant par 192.168.25 appartiendront à ce réseau. Si l’on prend le réseau 192.168.25.32/255.255.255.248 et que je vous demande si la machine 192.168.25.47 appartient à ce réseau ? Ça devient plus compliqué…
Pour bien comprendre, il faut alors revenir en binaire. Étant donné que les trois premiers octets du masque ont tous leurs bits à 1, c’est sur le quatrième que va se faire la différentiation. Il s’écrit 248, soit 11111000 en binaire. Donc les 5 premiers bits de cet octet représenteront la partie réseau.
Pour notre réseau, le dernier octet vaut 32, soit 00100000, pour notre machine, il vaut 47, soit 00101111. On voit que les 5 premiers bits de ces deux octets ne sont pas identiques (00100 != 00101) et donc que ces deux adresses n’appartiennent pas au même réseau. Cela peut sembler très compliqué, mais on verra par la suite des méthodes simples pour déterminer rapidement l’appartenance à un réseau.

Quelle est cette notation avec un /, comme /24 ?

Une autre notation est souvent utilisée pour représenter les masques. On la rencontre souvent car elle est plus rapide à écrire. Dans celle-ci, on note directement le nombre de bits significatifs en décimal, en considérant que la contiguïté est respectée. Ainsi, pour notre exemple 192.168.25.0/255.255.255.0, on peut aussi écrire 192.168.25.0/24, car 24 bits sont significatifs de la partie réseau de l’adresse.
De même, les écritures suivantes sont équivalentes:
10.0.0.0/255.0.0.0 = 10.0.0.0/8
192.168.25.32/255.255.255.248 = 192.168.25.32/29
Étant donné que le masque détermine le nombre de machines qu’il pourra y avoir sur un réseau, c’est souvent de cette information que l’on part pour choisir le masque. Étant donné que l’on travail en binaire, le nombre de machines possible au sein d’un réseau sera une puissance de 2. Pour un nombre de machines donné, il faudra donc choisir la puissance de 2 supérieure pour pouvoir adresser les machines. De plus, il faudra prévoir un certain nombre d’adresses supplémentaires pour accueillir de nouvelles machines.
Ainsi, disons que l’on possède le réseau 193.225.34.0/255.255.255.0 et que l’on veut faire un réseau de 60 machines au sein de celui-ci. On veut 60 machines, il faut ajouter deux adresses pour le réseau et le broadcast, ce qui fait 62 adresses au total. La puissance de 2 supérieure à 62 est 64, mais cela ne nous laisserait que 2 adresses pour évoluer, ce qui est un peu juste. On préfèrera donc un réseau de 128 adresses. Pour identifier 128 adresses, il nous faut 7 bits (128 = 27) Donc dans notre masque, 7 bits seront à 0 pour identifier la partie machine, et les 25 bits restants seront à 1. Ce qui donne:
11111111.11111111.11111111.10000000
Et en décimal 255.255.255.128.

Comment bien choisir son masque ?

Partir de l’existant

La plupart du temps, le choix de l’adressage se fait en fonction des besoins exprimés, et des limites de ce que l’on a le droit de faire. Une certaine plage vous est allouée par votre fournisseur d’accès. Vous pourrez alors découper cette plage en différents réseaux, mais ne surtout pas dépasser celle-ci. Ainsi, si vous possédez une plage de 128 adresses et que vous voulez adresser 500 machines, vous aurez quelques petits problèmes…

En fonction du nombre de machines

Etant donné que le masque détermine le nombre de machines qu’il pourra y avoir sur un réseau, c’est souvent de cette information que l’on part pour choisir le masque. Etant donné que l’on travail en binaire, le nombre de machines possible au sein d’un réseau sera une puissance de 2. Pour un nombre de machines donné, il faudra donc choisir la puissance de 2 immédiatement supérieure pour pouvoir adresser les machines. De plus, il faudra prévoir un certain nombre d’adresses supplémentaires pour accueillir de nouvelles machines.
Ainsi, disons que l’on possède le réseau 193.225.34.0/255.255.255.0 et que l’on veut faire un réseau de 60 machines au sein de celui-ci. On veut 60 machines, il faut ajouter deux adresses pour le réseau et le broadcast, ce qui fait 62 adresses au total. La puissance de 2 supérieure à 62 est 64, mais cela ne nous laisserait que 2 adresses pour évoluer, ce qui est un peu juste. On préfèrera donc un réseau de 128 adresses. Pour identifier 128 adresses, il nous faut 7 bits (128 = 27) Donc dans notre masque, 7 bits seront à 0 pour identifier la partie machine, et les 25 bits restants seront à 1. Ce qui donne:
11111111.11111111.11111111.10000000
Et en décimal 255.255.255.128.

Comment déterminer la plage d’adresses à partir du masque et d’une adresse ?

Nous avons vu précédemment que le masque devait être associé à une adresse IP pour avoir une valeur. Le choix de la plage d’adresses sur laquelle il s’applique est donc tout aussi important !! Nous avons choisi un masque qui nous permettra d’identifier 128 machines. Mais nous possédons une plage d’adresses de 256 adresses. Dans laquelle il faut placer nos 128 adresses. Peut-on les placer n’importe où ?
La réponse est bien sûr non. Nous n’avons que deux possibilités pour choisir notre plage, les adresses de 0 à 127, et les adresses de 128 à 255. Choisir une plage de 32 à 160 serait une erreur, et le réseau ne fonctionnerait pas.
Voici l’explication:
La différentiation du réseau va se faire sur le premier bit du dernier octet (vu que nos trois premiers octets sont fixés à 193.225.34). Si ce bit est à 0, cela correspond aux adresses de 0 à 127. S’il est à 1, cela correspond aux adresses de 128 à 255. Ainsi, si l’on choisit une plage d’adresses de 32 à 160, les adresses de 32 à 127 auront le premier bit de leur dernier octet à 0, alors que les adresses de 128 à 160 auront ce même bit à 1, elles seront alors considérées comme étant dans deux réseaux différents !!!
Ainsi, quel que soit le nombre de machines à placer dans une plage, on ne peut pas choisir l’adressage n’importe comment.
PS: Dans notre cas, les deux choix possibles sont identiques, mais l’on verra par la suite que ce n’est pas toujours le cas pour des plages plus petites…

Une méthode simple pour trouver les adresses de réseau possible

Il n’est pas toujours évident de savoir si une adresse correspond bien à celle d’un réseau selon le masque que l’on a choisi. Avec la méthode suivante, vous devriez pouvoir vous en sortir. Il faut avant tout que vous ayez déterminé le masque selon le nombre de machines dont vous avez besoin. Ensuite, selon l’octet significatif (qui n’est pas à 0 ou 255) faites 256-“cet octet”=X. L’adresse de réseau devra alors être un multiple de X. Un petit exemple pour être un peu plus clair.
On veut par exemple 50 machines, on choisit donc un masque en 255.255.255.192. C’est le dernier octet qui est significatif, on fait donc 256-192=64. Il faut donc que le dernier octet de l’adresse de réseau soit un multiple de 64. Si on prend la plage 10.0.0.0/255.255.255.0, on pourra choisir les adresses de réseau suivantes:
10.0.0.0, 10.0.0.64, 10.0.0.128, 10.0.0.192.

Comment découper une plage réseau quelconque comme somme de plusieurs plages ?

Nous avons vu qu’une plage réseau ne pouvait pas être choisie n’importe comment. Étant donné que les masques et les adresses IP se basent sur un codage binaire, les chiffres utilisés dans les adresses résultantes ne pourront être que des multiples de puissances de 2 en accord avec le masque. Ainsi, une plage 70.0.0.0 ne pourra pas avoir un masque qui définisse plus de deux chiffres sur le premier octet, car 70 est un multiple de 2, mais pas de 4. Ce n’est pas clair ? Un exemple devrait vous aider à mieux comprendre. Disons que l’on veut décrire la plage d’adresses allant de 69.0.0.0 à 79.255.255.255.
La question est de savoir quel masque, associé à quelle adresse de réseau, nous permettra de définir cette plage.

Le premier octet varie de 69 à 79. Il prend donc 11 valeurs. 11 n’étant pas une puissance de 2, on sait d’ores et déjà que l’on ne pourra pas définir cette plage avec un seul réseau, mais qu’il va falloir la découper en une somme de plusieurs réseaux. Le but est cependant d’optimiser cette somme de réseaux pour en avoir le moins possible. On pourrait simplement utiliser 11 réseaux avec des masques 255.0.0.0, mais on doit sûrement pouvoir faire plus propre et regrouper plusieurs de ces réseaux en un seul.
La première puissance de 2 inférieure à 11 est 8. Il faut maintenant savoir si l’on peut placer un réseau, dont le premier octet décrira 8 valeurs, dans cette plage. Le seul multiple de 8 de cette plage est 72. On décrirait alors un réseau dont le premier octet varierait de 72 à 79, ce qui est bien compris dans notre plage d’origine. Le réseau 72.0.0.0/248.0.0.0 est donc bien adapté pour décrire notre plage, mais il reste encore à décrire les adresses de 69.0.0.0 à 71.255.255.255.
On effectue le même raisonnement. (Ici le premier octet prend 3 valeurs, la puissance de 2 inférieure à 3 est 2, et le multiple de 2 de cette plage est 70)
On trouve donc le réseau 70.0.0.0/254.0.0.0
Il ne nous reste plus qu’à décrire la plage 69.0.0.0 à 69.255.255.255 qui peut être définie par 69.0.0.0/255.0.0.0.
Et voilà !! Nous avons découpé notre plage d’origine qui allait de 69.0.0.0 à 79.255.255.255 en trois sous-réseaux:
69.0.0.0/255.0.0.0
70.0.0.0/254.0.0.0
et 72.0.0.0/248.0.0.0

Plages réservées (Rfc 1918)

Certaines plages d’adresses ont été réservées pour une utilisation locale. Ainsi, pour configurer un réseau local quand on n’a pas de plage d’adresses publiques à disposition, on doit utiliser ces plages d’adresses privées. Si vous voulez avoir plusieurs réseaux, c’est à vous de faire le découpage au sein de ces plages comme bon vous semble.
Voici ces plages d’adresses:
10.0.0.0/255.0.0.0 soit plus de 16 millions d’adresses
192.168.0.0/255.255.0.0 soit près de 65000 adresses
172.16.0.0/255.240.0.0 soit plus d’un million d’adresses
Si après vous ne trouvez pas votre bonheur, c’est que vous avez un très très très grand réseau, ou que vous vous y prenez mal… Rfc 1918

Comment découper une plage d’adresses en plusieurs sous-réseaux ?

Détermination des masques pour chacun des réseaux

Il est souvent nécessaire de découper une plage d’adresses en plusieurs sous-réseaux. Pour cela, il vaut souvent mieux envisager le découpage des réseaux dans son ensemble plutôt que de les faire chacun séparément et de se rendre compte à la fin qu’ils sont incompatibles…
Ainsi nous allons encore partir du nombre de machines dans chacun des réseaux. Prenons l’exemple précédent du réseau 193.225.34.0/255.255.255.0. On désire comme précédemment faire un sous-réseau de 60 machines, mais aussi un réseau de 44 machines et un dernier de 20 machines. De la même façon que nous l’avons vu précédemment, pour 44 machines, il faudra réserver 64 adresses, soit un masque 255.255.255.192.
Pour 20 machines, il faudra réserver 32 adresses, soit un masque 255.255.255.224.

Détermination des plages réseau

Nous allons donc devoir placer trois plages de 128, 64 et 32 adresses dans une plage de 256 adresses, cela ne devrait pas poser de problème. On commence par la plage la plus grande de 128 adresses. Si on commençait par la plus petite et qu’on la plaçait n’importe où, cela pourrait poser problème. Imaginons que l’on place la plage de 32 adresses de 0 à 31, et celle de 64 adresses de 128 à 192, il ne nous resterait plus de place pour la plage de 128 adresses !!!
On a donc deux choix pour cette plage de 128 adresses, soit les adresses de 0 à 127, soit de 128 à 255. A priori, les deux choix sont possibles et non déterminants. On choisit de 0 à 127. Ainsi, notre sous-réseau sera caractérisé par 193.225.34.0/255.255.255.128.
Pour la seconde plage de 64 adresses, il nous reste deux plages d’adresses possibles, de 128 à 191, et de 192 à 255. Là encore le choix n’est pas déterminant. On choisit de 128 à 191. Ainsi, notre second sous-réseau sera caractérisé par 193.225.34.128/255.255.255.192 (ici, la première adresse de notre plage (l adresse du réseau) est celle en 128 et le dernier octet du masque en 192 nous indique que ce sous-réseau contient 64 adresses)
Enfin, pour la dernière plage de 32 adresses, il nous reste encore deux possibilités de 192 à 223 ou de 224 à 255. On choisit de 192 à 223. Ainsi, notre troisième sous-réseau sera caractérisé par 193.225.34.192/255.255.255.224

Le résultat

Nous avons donc découpé notre réseau d’origine 193.225.34.0/255.255.255.0 en trois sous-réseaux:

  1. 193.225.34.0/255.255.255.128
  2. 193.225.34.128/255.255.255.192
  3. 193.225.34.192/255.255.255.224

Il nous reste même une plage de 32 adresses non utilisées de 224 à 255.

Que sont les classes d’adresses A, B, C, D… ?

Historique

Comme nous l’avons vu dans le paragraphe 2, le masque de sous-réseau permet de segmenter l’ensemble des adresses de l’Internet en différents réseaux. Mais cette segmentation ne s’est pas faite n’importe comment ! On a découpé la plage d’adresses disponible en cinq parties distinctes. Les classes A, B, C, D et E, que l’on appelle aussi adresses globales.

Définition

Classe A: Premier bit de l’adresse à 0, et masque de sous-réseau en 255.0.0.0. Ce qui donne la plage d’adresse 0.0.0.0 à 126.255.255.255 soit 16 777 214 adresses par réseau de classe A
Classe B: Deux premiers bits de l’adresse à 10 (1 et 0), et masque de sous-réseau en 255.255.0.0. Ce qui donne la plage d’adresse 128.0.0.0 à 191.255.255.255 soit 65 534 adresses par réseau de classe B
Classe C: Trois premiers bits de l’adresse à 110, et masque de sous-réseau en 255.255.255.0. Ce qui donne la plage d’adresse 192.0.0.0 à 223.255.255.255 soit 255 adresses par réseau de classe C
Classe D: Quatre premiers bits de l’adresse à 1110, et masque de sous-réseau en 255.255.255.240. Ce qui donne la plage d’adresse 224.0.0.0 à 239.255.255.255 soit 255 adresses par réseau de classe D
Classe E: Quatre premiers bits de l’adresse à 1111, et masque de sous-réseau en 255.255.255.240. Ce qui donne la plage d’adresse 240.0.0.0 à 255.255.255.255
Les classes A, B et C, sont réservées pour les utilisateurs d’Internet (entreprises, administrations, fournisseurs d’accès, etc.)
La classe D est réservée pour les flux multicast et la classe E n’est pas utilisée aujourd’hui.
Ainsi, une entreprise demandant 80 000 adresses se voyait attribuer un réseau de classe A, et gâchait par la même occasion (16 777 214 – 80 000= 16 697 214) adresses !!!
Inutile alors de vous montrer combien d’adresses étaient perdues de la sorte…

Y a-t-il une pénurie d’adresses IPv4 ?

La réponse est non.
Il n’y a pas aujourd’hui de pénurie d’adresses IP. Cependant, il est certain qu’étant donné le développement rapide d’Internet, on va vite arriver à une situation critique. C’est aussi pour cela qu’une nouvelle version d’IP a été créée et sera bientôt déployée.
La pénurie d’adresses est prévue d’ici 2015 si Internet continue de croître avec la même progression qu’aujourd’hui. Il faudra alors passer à IPv6.

Le système d’adressage par classes est-il viable ?

La réponse est encore non, et a déjà été depuis bien longtemps étudié et transformé. Nous avons vu qu’en se basant sur ce système de classes, nous risquons de gâcher un très grand nombre d’adresses. Les classes d’adresses globales se sont donc rapidement avérées obsolètes et on a du créer un nouveau modèle, l’adressage CIDR

Qu’est-ce que l’adressage CIDR ?

Etant donné que l’adressage par classes s’est avéré incompatible avec l’évolution d’Internet, il a fallu imaginer un nouveau modèle qui simplifie à la fois le routage et permette un adressage plus fin. Pour cela, on a créé l’adressage CIDR (Classless Inter-Domain Routing). Cet adressage ne tient pas compte des classes globales et autorise l’utilisation de sous-réseaux au sein de toutes les classes d’adresses. Ainsi, une entreprise désirant 80 000 adresses ne se verra plus attribuer une classe A complète, mais un sous-réseau de cette classe A. Par exemple, on lui fournira non plus 16 millions d’adresses, mais 130 000 (la puissance de deux supérieure à 80 000) Ainsi les 16 millions d’adresses restantes pourront être utilisées pour d’autres entités.
L’adressage CIDR ne tient donc plus du tout compte des masques associés aux classes d’adresses globales. On s’affranchit ainsi du découpage arbitraire et peu flexible en classes. On peut très bien trouver un réseau de classe B avec un masque de classe C, par exemple 164.23.0.0/255.255.255.0.

Trucs et astuces avec les masques

Comment déterminer qu’une machine appartient à mon réseau ?

C’est très simple, pour cela, il va falloir déterminer si l’adresse de la machine appartient à la plage d’adresses définie par mon adresse et mon masque. Pour cela, je fais un ET logique entre mon adresse et mon masque réseau, j’en déduis donc l’adresse de mon réseau (pour une explication du ET logique, regarder le paragraphe 10.4)
Je fais pareil avec l’adresse de l’autre machine et MON masque réseau, et j’obtiens une adresse de réseau. Si les deux adresses de réseau sont les mêmes, ça veut dire que la machine appartient bien au même réseau.
Disons par exemple que ma machine ait pour adresse 192.168.0.140/255.255.255.128 et je veux savoir si les machines A et B ayant pour adresses 192.168.0.20(A) et 192.168.0.185(B) sont sur le même réseau ? Je fais:
192.168.0.140 ET 255.255.255.128 = 192.168.0.128
De même avec les deux autres adresses, pour A
192.168.0.20 ET 255.255.255.128 = 192.168.0.0
Et pour B:
192.168.0.185 ET 255.255.255.128 = 192.168.0.128
On voit ainsi que les nombres obtenus sont les mêmes pour ma machine et B. On en déduit donc que B est sur le même réseau, et que A est sur un réseau différent.

Des machines sur un même réseau peuvent elles avoir des masques différents ?

A priori, la réponse est non. Cependant, il peut y avoir des cas dans lesquels une telle configuration peut être utile.
Pour comprendre cela, il faut comprendre ce qui se passe au niveau de la communication entre machines, et notamment sur le fonctionnement du modèle TCP/IP. Celui-ci ne faisant pas partie de l’objet du cours, nous ne ferons que survoler le sujet.
En fait, ce ne sont pas les mêmes mécanismes qui gèrent une communication entre deux machines sur un même réseau, et deux machines sur deux réseaux distincts. Une communication a lieu dans les deux sens, c’est à dire que pour communiquer ensemble, une machine A doit voir une machine B ET la machine B doit voir la machine A.
Prenons l’exemple de trois machines A, B et C et de la plage d’adresses 192.168.0.0/24. A doit pouvoir communiquer avec B et C, mais B ne doit pas pouvoir communiquer avec C. Pour cela, on peut jouer sur les masques des machines et les plages d’adresses réseau auxquelles elles appartiennent.

Grâce aux masques, on peut découper cette plage en deux, et on obtient ainsi, non plus une plage d’adresses… mais trois !
La 1ere: 192.168.0.0/255.255.255.0 soit de 192.168.0.0 à 192.168.0.255
La 2ieme: 192.168.0.0/255.255.255.128 soit de 192.168.0.0 à 192.168.0.127
La 3ieme: 192.168.0.128/255.255.255.128 soit de 192.168.0.128 à 192.168.0.255
En fait, la première plage englobe les deux autres, ainsi, une machine de la première plage peut voir toutes les autres machines des autres plages, mais une machine de la seconde plage ne peut pas voir toutes les machines de la première plage (seulement la moitié des adresses…)
Ce n’est pas clair ? Regardons alors un exemple:
On donne les adresses suivantes aux machines A, B et C.

  • A: 192.168.0.129/255.255.255.0 Plage 1
  • B: 192.168.0.130/255.255.255.128 Plage 2
  • C: 192.168.0.1/255.255.255.0 Plage 1

D’après ce que l’on a vu précédemment, la plage 2 sera englobée dans la plage 1, et donc A et C considèreront que la machine B est sur leur réseau. A ayant une adresse dans la même plage que B (plage 2), B verra A comme étant aussi dans son réseau. Par contre, B ne considèrera pas que C est dans le réseau car l’adresse de C n’appartient pas à la plage 2. Ainsi, C peut envoyer un paquet à B (C voit bien B comme étant dans son réseau) mais B ne pourra pas lui répondre. Cette configuration correspond donc bien à ce que l’on cherchait à faire. Cependant, une telle configuration n’est pas conseillée et ne doit être utilisée que s’il n’y a pas d’autres solutions. En dehors de cas exotiques comme celui exposé, on ne doit jamais avoir deux machines appartenant à un même réseau ayant des masques différents !

Puis-je utiliser un outil qui calcule pour moi ?

Non !!!
Enfin si, mais bon, vous me décevriez beaucoup. Car après ce que nous avons vu, vous devriez être capable de calculer n’importe quel masque correct aussi vite qu’une machine. Et il est toujours mieux de bien maîtriser ce qu’on utilise. A force d’utiliser des automates, on perd les notions de ce que l’on manipule.
D’autre part, un logiciel ne corrigera pas vos erreurs ! La plupart des logiciels de calcul de masque ne font qu’un calcul bête et méchant qui peut s’avérer faux. Prenons l’exemple du 6.3, ou l’on veut une plage commençant en 192.168.0.32, et une centaine de machines. Un mauvais logiciel vous sortira le réseau 192.168.0.32/255.255.255.128, et hop, ça ne marchera pas…

Tout ça c’est bien, mais quand est ce que je l’utilise ce masque moi ?

Effectivement, quand vous allez sur Internet, vous utilisez un masque sans le savoir. Sous Windows, que vous soyez connecté à un réseau local, ou directement par un modem, vous pourrez voir les propriétés de vos interfaces réseau en allant dans une fenêtre DOS et en entrant la commande “ipconfig /all”
Vous pouvez aussi modifier ces propriétés en allant dans les propriétés de votre carte réseau, puis propriétés TCP/IP, et la, vous devriez voir votre adresse IP, ainsi que le masque associé, et votre passerelle par défaut. Vous pouvez modifier ces informations, mais votre réseau risque de ne plus fonctionner (et en plus il faudra rebooter sous 98…) donc attention !! Le masque définit donc les machines (ou plus précisément, les interfaces) appartenant à un même réseau. Pour dialoguer avec ces machines, vous utiliserez un des mécanismes de couche 2 du modèle OSI, alors que pour dialoguer avec les machines d’un autre réseau, vous aurez besoin d’utiliser des mécanismes de couche 3 qui permettent notamment de faire du routage… Il est donc primordial de ne pas se tromper dans le choix du masque.

Mini lexique

Adresse IP

L’adresse IP est un numéro codé sur 4 octets permettant d’identifier une machine de façon unique sur le réseau.

Réseau logique

On appelle réseau logique un ensemble d’adresses IP appartenant à une même plage d’adresses. Cette plage est notamment définie par l’adresse de réseau et le masque associé.

Sous-réseau

On définit un sous-réseau comme un sous-ensemble d’une plage d’adresses réseau. C’est grâce au masque que l’on peut définir un sous-réseau au sein d’un réseau, et ainsi découper un réseau en plusieurs sous-réseaux.

Le ET logique

La fonction de ET logiques est souvent utilisée dans les masques. Elle se base en binaire sur le principe suivant:

  • 0 ET 0 = 0
  • 1 ET 0 = 0
  • 0 ET 1 = 0
  • 1 ET 1 = 1

On peut donc en déduire au niveau des masques 192.168.0.140 ET 255.255.255.128 décomposé en:

Soit 192 168 0 128
Ici, on voit que les trois premiers octets du masque ont tous leurs bits à 1, donc les trois premiers octets du résultat ne seront pas modifiés par rapport à l’adresse d’origine, et on obtient facilement 192.168.0. Pour le dernier octet, il faut regarder plus en détail.

Annexes

Ressources utilisées

Je n’ai pas utilisé beaucoup de documents aussi bien en ligne que sur papier. Les réponses et connaissances apportées proviennent en majeure partie des informations que j’ai pu glaner en furetant sur le net, et notamment sur les newgroups fr.comp.reseaux.ip et fr.comp.reseaux.ethernet.

Je me suis quand même inspiré de quelques documents:

Et l’excellente faq sur les firewalls de Stéphane Catteau dont je me suis inspiré pour la mise en forme.
Disponible sur:
http://fr.comp.securite.free.fr/firewall.txt
N’hésitez pas à la consulter, on y apprend plein de choses.

Remerciements

Je remercie notamment les personnes suivantes pour leur lecture assidue du cours durant sa réalisation et leurs conseils précieux.

Jad Chantiri, Pierrick Vodoz, Laurent de Soras, Stéphane Catteau, Cédric Blancher, Ohmforce, Franck Bacquet, Olivier Lamer, Diane Guinnepain, JC, Alain Winestel, thierry Bellemare, Alex A, Hubert Quarantel-Colombani, Tony, Bruno Goujon.

Versions latex, doc et pdf disponibles

Une version latex de la faq est maintenant disponible grâce à Tony.
Deux fichiers pdf et doc faits à partir de cette version sont aussi à votre disposition.
Ces trois versions sont un peu plus lisibles de par leur mise en page.
Vous les trouverez là:

Faq sur la NAT

Si cette faq vous a plu et que vous avez appris des choses, j’en ai fait une autre sur la NAT (traduction d’adresses)

Faq sur le routage

Si cette faq vous a plu et que vous avez appris des choses, j’en ai fait une autre sur le routage

Conclusion

J’ai fait de mon mieux pour rendre la notion de masques la plus abordable possible et traiter le sujet de la meilleure façon. Je me rends compte que ce cours est assez fourni en information et pas toujours facile à digérer. Vos remarques sont donc encore et toujours les bienvenues, aussi bien pour y ajouter des idées, que pour enlever le superflu.
Maintenant, si je revois passer des questions sur les masques, j’aurai au minimum un droit de flagellation sur les personnes incriminées 😉

Share