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.