HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > Articles > Introduction à la famille des protocoles TCP/IP
Accéder au : Site HSC des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Equipe
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|Introduction à la famille des protocoles TCP/IP  
> Accès au contenu HTML Début de l'article  
> Description Le monde Unix étant un monde ouvert, il doit fournir des outils d'accès au réseau. Pour cela, un ensemble de protocoles que l'on appelle "la famille des protocoles IP" a été constituée. Nous allons présenter successivement les différents membres de cette famille.  
> Contexte & Dates
février 1997 
> Auteur Tristan Debeaupuis 
> Langue et Nature  
> Résumé &
Table des matières
1. Ethernet
  1.1. Introduction
  1.2. Ethernet
  1.3. Présentation des "gateways"
  1.4. Adresses internet
  1.5. Le protocole ARP (Address Resolution Protocol)
  1.6. Le protocole RARP (Reverse ARP)
  1.7. Le protocole IP (Internet Protocol)
  1.8. Conclusion

2. ICMP
  2.1. Introduction
  2.2. ICMP (Internet Control Message Protocol)
  2.3. Les différents messages d'ICMP
  2.4. Conclusion

3. Routage
  3.1. Introduction
  3.2. GGP (Gateway to Gateway Protocol)
  3.3. EGP (Exterior Gateway Protocol)
  3.4. Les protocoles "privés" : RIP, HELLO et GATED
  3.5. Conclusion

4. TCP
  4.1. Introduction
  4.2. TCP (Transport Control Protocol)
  4.3. Transport sécurisé par TCP
  4.4. Fonctionnement de TCP
  4.5. Conclusion

5. Applications
  5.1. Introduction
  5.2. Connexion à une machine distante
  5.3. Transfert de fichiers
  5.4. Commandes à distance : RSH
  5.5. Le système de messagerie
  5.6. NFS et RFS
  5.7. DNS
  5.8. SNMP
  5.9. Conclusion

ANNEXE A : Liste des fichiers de configuration du réseau
  ANNEXE A.1. : Fichiers de configuration de chaque utilisateur
  ANNEXE A.2. : Fichiers de configuration générale

ANNEXE B : Fichiers de définition des protocoles  

> Documents liés
themeTCP/IP
[Formation]  Sécurité des réseaux TCP/IP
[Outil]  Outil Dns2tcp [Dns2tcp est un outil permettant d'encapsuler des sessions TCP dans DNS. - Anglais]
[Outil]  Outil Net::RawSock [Envoi de paquets IP bruts en Perl - Anglais]
[Cours]  Sécurité des réseaux TCP/IP [25 novembre 1999 - Français]
> Droits d'auteur © 1997, Hervé Schauer Consultants, tous droits réservés.

 


1. Ethernet et la famille IP

1.1. Introduction

1.1.1. Pourquoi les réseaux ?

Un réseau permet d'accéder aux

  • algorithmes,
  • machines,
  • informations.

Le monde Unix étant un monde ouvert, il doit lui aussi fournir des outils d'accès au réseau. Pour cela, un ensemble de protocoles que l'on appelle "la famille des protocoles IP" a été constituée.

Nous allons revenir très rapidement sur la raison d'être de cette famille et présenter sa structure. Nous présenterons ensuite les couches I et II d'Ethernet ainsi que le fonctionnement de la couche IP.

1.1.2. Pourquoi une famille de protocoles ?

Selon le matériel utilisé, on souhaite pouvoir accéder à

  • un réseau local,
  • une ligne point à point,
  • un réseau à commutation de paquets.

Selon les applications, nous avons de plus besoin de différents "services" tels que

  • la session à distance,
  • le transfert de fichiers,
  • la fonction de fenêtrage...

La famille des protocoles IP offrent bien sûr l'accès à ces supports et propose en standard ces outils. Son atout majeur réside cependant dans son ouverture. En effet, une technologie mono-constructeur présente les inconvénients suivants :

  • une seule technologie,
  • un seul constructeur,

En cas d'interconnexion avec d'autres environnements réseau, il est nécessaire

  • de connaître la topologie,
  • d'établir des passerelles d'interconnexion entre les deux mondes que l'on souhaite relier.

Il s'est donc rapidement avéré nécessaire qu'une normalisation soit mise en place afin de réduire les impossibilités d'interconnexion de réseaux hétérogènes. La première notion de normalisation est apparue dans les télécommunications car il s'agissait d'une volonté d'état. On retrouve le même principe pour les liens physiques en informatique. Nous pourrions donner une définition à l'ouverture des solutions informatiques afin de mieux en saisir l'importance :

"L'ouverture représente en fait l'universalité du fonctionnement d'un système quels que soient

  • le matériel (ce qui entraîne l'indépendance vis à vis des constructeurs),
  • la nature des liaisons,
  • la topologie du réseau."

Une solution possible à l'ouverture est "Internet" (inter-network). Le but d'internet est d'être accessible à partir de tout point informatique quelle qu'en soit la topologie. Nous pourrions modéliser l'accès à Internet par ce simple schéma :

Du point de vue fonctionnel, il existe en tout point du réseau une même couche protocolaire permettant un dialogue homogène entre deux sites connectés. Dans ce cas il est fait abstraction

  • des services,
  • des fournisseurs,
  • des utilisateurs,
  • enfin des protocoles.

Il existe en effet une nouvelle boîte logicielle qui retarde la position de la couche apportée par le fournisseur :

Quatre caractéristiques essentielles permettent de cerner la famille de protocoles IP :

  • indépendance de la technologie réseau choisie,
  • interconnexion mondiale,
  • acknowledges de bout en bout,
  • protocole standard supportant beaucoup d'applications.

Ces quatre caractéristiques permettent donc de dire que les protocoles IP sont un bon moyen d'accéder à l'internet.

1.1.3. Rappel des couches OSI

Le modèle OSI comporte sept couches réparties comme suit :

Le modèle de l'internet est quelque peu différent :

1.1.4. l'Internet - Réseau mondial de communication informatique

La création d'Internet résulte d'un projet lancé par la DOD (projet DARPA). Le but de ce projet était de permettre aux militaires américains de partager et recueillir des données stratégiques en tout point du globe quels que soient les supports de télécommunications utilisés.

Il y eut par conséquent une investigation des technologies de transmission : X25, satellite, etc, afin de connecter tous les sites DARPA du monde. Il en résulta la création du réseau ARPANET.

Un deuxième besoin apparut alors : il fallait permettre aux militaires d'accéder aux ressources des co-contractants (données, programmes, calculateurs). Pour communiquer, on décida de créer une famille de protocoles. Cette famille a été mise en place sur ARPANET.

Au début des années 80, ces protocoles ont été inclus dans la version Berkeley (BSD) d'Unix. La présence de ces protocoles sur Unix Système V et sur BSD a provoqué une explosion mondiale du trafic sur ce réseau.

Aujourd'hui, deux organismes fédèrent le fonctionnement d'Internet :

  • l'I.A.B. est chargé de gérer administrativement l'Internet (notamment lors de la définition des protocoles),
  • l'I.E.T.F. est chargé d'implémenter les protocoles.

L'idée d'Internet est simple : interconnecter des réseaux c'est-à-dire des machines et des passerelles :

L'Internet propose des services de deux niveaux :

  • au niveau réseau : transmission de paquets (i.e. les "datagrammes") et les circuits connectés,
  • au niveau applicatif : telnet, FTP et la messagerie (protocole SMTP - Simple Mail Transfert Protocol).

Il existe une certaine dépendance entre les différents niveaux d'IP :

Nous examinerons dans les chapîtres qui vont suivre chaque protocole de cette famille afin d'en décrire tout le fonctionnement.

1.2. Ethernet

Ethernet est une technologie de bus partagé. Ethernet utilise des câbles cylindriques pour transmettre les signaux. Il existe deux supports physiques qui ont donné naissance à deux normes :

  • Ethernet fin (Thin Ethernet) : le câble coaxial est fin. L'avantage de cette solution est le coût d'achat. Par contre, les pertes électriques sont plus importantes et par conséquent ce type de support est considéré comme peu fiable. Il ne devra pas être utilisé si beaucoup de postes sont placés sur ce support. On appelle 5baseT (5bT) la norme électrique associée à ce type de câble.
  • Ethernet "classique" : ce support est un câble coaxial de plus gros diamètre. On appelle 10baseT (10bT) la norme électrique associée à ce type de câble. Ce support offre un débit de 10Mbps.

1.2.1.Utilisation des transceivers

Un transceiver est un montage électronique dont les buts sont les suivants :

  • transformer le signal électrique véhiculé sur le bus en un signal numérique compréhensible par le poste connecté.
  • ne pas filtrer les informations (i.e. tout laisser passer). Il faut comprendre par là que les transceivers n'ont aucune intelligence et qu'ils ne connaissent pas la nature et le fonctionnement des protocoles réseaux. Un transceiver n'est pas conçu pour filtrer des paquets ni pour optimiser les accès réseau. Il n'est pas conçu non plus pour réduire les collisions engendrées par le protocole Ethernet.

1.2.2. Accès au bus

Cet accès est distribué. Il est basé sur une technologie CSMA/CD (Carrier Sense Multiple Access with Collision Detection). Toute machine est autorisée à émettre sur le brin Ethernet à un instant t. Il n'y a pas de notion de priorité d'accès : la machine qui émet à un instant t est celle qui s'est rendu compte en premier que le brin Ethernet était disponible. Pour émettre, l'algorithme est simple :

  • La machine écoute le réseau : s'il n'y a aucun trafic, elle émet sa trame Ethernet. Sinon, elle attend un temps T. Ce temps est calculé de manière à limiter le nombre de tentatives d'émission infructueuses. Nous verrons comment ce temps se détermine.
  • Si une collision se produit c'est-à-dire que plusieurs trames se trouvent au même instant sur le réseau et qu'il y a perte possible de données, la machine est avertie de la collision et recommence alors la première étape.

Deux contraintes découlent de cette technologie :

  • une définition d'une taille maximale de paquets est obligatoire,
  • un temps minimum de latence doit être respecté entre deux transmissions de trames.

Pour réduire les collisions sur le brin Ethernet, un algorithme optimal de calcul des temps d'attente T entre deux transmissions infructueuses a été inventé :

  • attente d'une unité de temps après la première collision,
  • attente de deux unités de temps après la deuxième collision,
  • attente de quatre unités de temps après la troisième collision
  • auxquelles s'ajoute un delta-t calculé aléatoirement pour chaque poste afin de réduire les probabilité de collision.

1.2.3. Mécanisme d'adressage Ethernet

Cet adressage permet l'élimination des trames erronées. On définit une adresse Ethernet par un entier codé sur 48 bits (i.e. un integer en langage C !). C'est une fourniture hardware pouvant être relue par soft. Chaque constructeur de cartes Ethernet possède une plage réservée d'adresse physique de cartes. Ces adresses sont uniques au monde.

Ainsi les adresses physiques des machines sont directement associées avec la carte d'interface hardware. L'inconvénient de cette solution réside dans son évolution : si l'on change la carte Ethernet d'une machine, son adresse physique a changé !

1.2.4. Structure d'une trame Ethernet

Une trame Ethernet

  • est de taille variable mais inférieure à 1526 octets,
  • contient l'adresse Ethernet de l'appelé et de l'appelant

Elle est constituée d'une entête et d'une zone de données :

Le champ "Type de paquets" indique quel protocole de niveau supérieur est employé. Trois valeurs sont à retenir :

  • Protocole IP : TYPE = 0x800h (2048 en décimal),
  • Protocoles ARP et RARP : TYPE = 0x806h (2054 en décimal),

Nous pouvons déduire de cette technique que le protocole Ethernet accepte d'autres protocoles de la couche supérieure que ceux de la famille IP. Ainsi, un brin Ethernet peut véhiculer des paquets IPX/SPX. Toutes les trames se différencient ensuite par leur type.

1.3. Présentation des "gateways"

Dans le réseau Internet, les machines dénommées Gateways offrent toutes les interconnexions à travers le réseau physique (réseau "araignée") => elles sont capables de router tous les paquets.

Les gateways dirigent les paquets vers le réseau destinataire et non pas vers la machine destinatrice. Une gateway pourrait donc être vue comme un transceiver intelligent (ou comme un commutateur de paquets IP).

Nous verrons que les gateways ont des propriétés particulières et agissent sur les modes de fonctionnement des protocoles de la famille IP.

1.4. Adresses internet

Ethernet utilise des adresses physiques pour décrire de manière unique chaque machine. Les couches de niveau supérieur ne se base pas sur cette identification. Aussi IP utilise-t-il des adresses Internet permettant aux couches IP de reconnaître de manière unique une machine.

Il existe trois classes d'adresses internet : il s'agit des classes A, B et C. Chaque classe d'adresse IP désigne une gamme de réseau. Une gamme est définie par le nombre de machines qu'elle comporte. Considérons la modélisation des trois classes A, B et C :

D'après le découpage de ces trois classes, on peut remarquer que

  • la classe A représente des réseaux ayant peu de sous-réseaux (puisque le champ d'identification du sous-réseau est sur 7 bits). Par contre, les réseaux de classes A permettent la définition de nombreuses machines puisque 24 bits sont dédiés à la définition de chaque poste.
  • la classe C représente des réseaux ayant peu de machines à connecter (puisque le champ d'identification des machines est sur 8 bits). Par contre, les réseaux de classes C permettent la définition de nombreux sous-réseaux puisqu'on dispose d'un masque de 21 bits pour les définir.
  • enfin la classe B est un intermédiaire entre les classes A et C. Elle offre une définition aux réseaux de taille homogène.

Le tableau suivant reprend donc les valeurs de masque possibles pour ces trois classes :

Classe d'adresse
Masque Réseau
Masque Machine
Valeur Min
Valeur Max
Valeur Min
Valeur Max
A
1. 126.0.0.1.255.255.254.
B
128.0. 191.255.0.1.255.254.
C
192.0.0. 223.255.255.1.254.

Remarque : les différents champs de l'adresse sont séparés par des points (par convention).

Exemples d'adresse de classe A :

  • 124.112.11.2
  • 1.0.0.1
  • 126.255.255.254

Exemples d'adresse de classe B :

  • 128.0.0.1
  • 191.255.255.254

Exemples d'adresse de classe C :

  • 192.0.0.1
  • 192.0.0.254

Certaines adresses sont toutefois réservées :

  • 127.0.0.1 (et même 127.X.X.X) représente la machine sur laquelle on se trouve. Il s'agit d'un mode d'adressage direct. Souvent, dans le fichier de configuration des adresses IP connues d'une machine ("/etc/hosts"), on retrouve la ligne suivante :

    127.0.0.1 loopback localhost

    Le terme "localhost" indique que l'on s'adresse à cette machine. Le terme "loopback" indique qu'un test en boucle (i.e. un test interne) s'adresse à cette machine. Ce loopback permet par exemple de tester les couches IP de la machine sur laquelle on se trouve.

  • 0.0.0.0 permet également de s'adresser à la machine sur laquelle on agit. Cette adresse est rarement utilisée.

  • 0.X.X.X permet de désigner une machine particulière se trouvant impérativement sur le réseau sur lequel on se trouve.

  • 1.1.1.1 représente un message de type broadcast (diffusé auprès de tous).

  • X.X.1.1permet l'émission d'un message broadcast sur certains réseaux.

1.5. Le protocole ARP (Address Resolution Protocol)

Nous avons vu dans les paragraphes précédents que le protocole Ethernet possédait un adressage physique des machines. À l'inverse, le protocole IP utilise un adressage logiciel. Lorsqu'une machine souhaite émettre une trame IP sur un brin Ethernet, elle doit donc être capable d'associer un couple (@IP appelante - @IP appelée) à un couple (@Ethernet appelante - @Ethernet appelée). Cette équivalence est obtenue par le protocole ARP (Address Resolution Protocol) qui, par des trames Ethernet spécifiques, permet d'interroger les machines quant à leurs adresses.

Comme nous l'avons vu précédemment, une requête ARP s'encapsule dans les trames Ethernet. Pour cela, le champ "Type de paquets" prend la valeur

  • 0x806h lorsqu'il s'agit d'une requête ARP,
  • 0x8035h lorsqu'il s'agit d'une réponse à une requête ARP.

Toute trame appartenant au protocole ARP a la structure suivante :

Une requête ARP n'a pas d'entête fixe. Son codage est le suivant :

Le champ Hardware permet au protocole ARP de spécifier le support réseau sur lequel il s'appuie. La valeur 1 désigne le réseau Ethernet. Puisque ARP indique le protocole des couches 1 et 2, il lui est possible de fonctionner sur d'autres réseaux que des réseaux Ethernet.

Le champ Protocole désigne le protocole de niveau supérieur. Dans le cas qui nous intéresse, il s'agit du protocole IP et par conséquent ce champ prend la valeur 0x800h.

HLEN et ILEN désignent les longueurs des adresses Hardware (HLEN) et des adresses internet (ILEN). De nouveau, on constate la souplesse du protocole ARP puisqu'il peut gérer des adresses de taille variable.

Le type de demande indique s'il s'agit du protocole ARP ou du protocole RARP. S'il s'agit d'ARP, deux valeurs sont possibles :

  • 1 : il s'agit d'une requête ARP,
  • 2 : il s'agit d'une réponse ARP.

Une requête ARP consiste à poser la question suivante : "Quelle est l'adresse Ethernet de la machine dont l'adresse Internet (ou autre suivant le choix du protocole de niveau supérieur) est xxxxx ?". Par conséquent une réponse ARP est : "L'adresse Ethernet (ou autre) de la machine dont l'adresse Internet est xxxx est yyyyy".

Pour réduire le nombre de trames ARP émises, toute machine émettant une requête y inclue sa propre adresse physique. La machine réceptrice stocke alors l'adresse Ethernet de la machine émettrice. Lors d'une connexion par IP, elle ne redemandera donc pas cette valeur.

1.6. Le protocole RARP (Reverse ARP)

Le protocole RARP est l'exact inverse du protocole ARP. Il permet de connaître l'adresse IP d'une machine dont on connaît l'adresse physique.

Intérêt du protocole RARP : une machine sans disque connaît son adresse physique (qu'elle est capable de lire sur sa carte Ethernet). Par contre, elle ne connaît pas son adresse Internet. Par conséquent, elle doit interroger un serveur qui connaît son adresse. Pour ce faire, elle émet donc une trame RARP dans laquelle est spécifiée son adresse physique. Émettre une trame RARP consiste donc à poser la question suivante : "Qui peut me dire quelle est l'adresse Internet correspondant à la machine dont l'adresse physique est xxxx ?". Une machine ayant cette information (typiquement le serveur de réseau local) répond par une trame RARP.

Une trame RARP s'encapsule dans une trame Ethernet de la même manière que ARP :

Une trame RARP a la même structure qu'une trame ARP :

Le type de demande peut prendre deux valeurs :

  • 3 : il s'agit d'une requête RARP,
  • 4 : il s'agit d'une réponse RARP.

1.7. Le protocole IP (Internet Protocol)

Le protocole IP appartient à la couche 3 du modèle OSI. Il fonctionne en mode non sécurisé c'est-à-dire que le transport des données par IP n'est pas fiable. Listons les avantages et inconvénients de ce protocole :

  • Ce protocole est non fiable (pertes possibles de données),
  • Il n'y a pas d'aquittement des données reçues (c'est le travail des couches de transport),
  • Les paquets n'arrivent pas dans l'ordre : la couche transport doit les remettre en forme,
  • IP utilise une méthode de fragmentation et de réassemblage,
  • L'acheminement est lié à la notion de routage : les données passent par des chemins quelconques et hétérogènes.

La couche IP permet d'interfacer une couche d'interface réseau (couches 1 et 2 du modèle OSI) avec une couche de transport (couche 4 du modèle OSI). On retrouve donc le respect du modèle Internet :

La couche IP va donc permettre de s'abstraire de la structure du réseau pour mettre en rapport un émetteur et un récepteur :

Si l'on compare le modèle TCP/IP et le modèle OSI, on remarque que la couche logicielle TCP/IP se décompose suivant 4 axes essentiels :

  • Support applicatif : cet accès de haut niveau permet aux utilisateurs finaux d'écrire des applications pouvant accéder à l'internet. Des librairies C sont mises à disposition sur les machines UNIX afin de concevoir des applications basées sur les protocoles de la famille IP. Ainsi, dans ce modèle, une application agit sur la couche transport pour émettre et recevoir des données quel qu'en soit l'aspect.
  • Couche de transport : Le premier but de cette couche est de permettre la communication (c'est-à-dire l'échange de données) entre deux applications. La couche transport peut de plus
    • effectuer du contrôle de flux,
    • assurer un transport sécurisé.
  • Couche réseau (IP) : Cette couche gère la communication de machine à machine. Elle reçoit un paquet à émettre par la couche transport avec une adresse de la machine destinatrice. Elle encapsule ses données dans un paquet, utilise éventuellement un algorithme de routage pour savoir comment émettre ce paquet puis passe le paquet aux couches physiques.
  • Couche d'interfaçage réseau (ex : Ethernet)

Il faut bien garder à l'esprit qu'IP respecte le modèle en couches. En effet, les protocoles en couches sont prévus pour que la couche n du modèle ISO de la machine destinatrice reçoive le même type d'objet que la couche n de la machine source. Si nous résumons dans un schéma ce que respecte IP (et les protocoles de transport s'appuyant sur celui-ci) :

IP émet donc des datagrammes qui sont composés de deux parties :

  • un paquet de données,
  • une entête.

Un datagramme IP encapsulé dans une trame Ethernet ne peut pas dépasser 1200 octets (contrainte imposée par le protocole Ethernet). Cependant un datagramme IP peut atteindre une taille de 4096 octets au maximum. On préfère ne pas dépasser cette valeur car des paquets volumeux sont plus difficiles à transporter (mais plus simples à perdre !).

1.7.1. Structure d'un datagramme IP

Un datagramme IP a la structure suivante :

Le premier champ d'un datagramme IP désigne le numéro de version de la couche IP de la machine. En effet, il existe de nombreuses versions d'IP. De nos jours, on utilise la version 4 de ce protocole. Tout datagramme issu d'une version récente d'IP commence donc par la valeur binaire 0100b. On déclare la version d'IP utilisée dans les datagrammes afin de vérifier que deux couches IP de deux machines différentes sont capables de dialoguer.

Le champ "Lg entête" indique la longueur de l'entête du datagramme. Celle-ci varie en fonction de la version d'IP employée ainsi que des options choisies.

Le champ "Service" est très important. Il se décompose en plusieurs champs dont chacun représente un bit :

Le premier champ "Précédence" est défini sur trois bits qui permettent de graduer le niveau d'intérêt du datagramme. Le niveau le plus haut concerne les datagrammes de contrôle du réseau (on les dénomme en anglais "Network Datagrams Control"). Ces datagrammes ont une précédence de 7 (le champ précédence prend donc la valeur binaire 111b). Les datagrammes de données sont les moins importants. On dit qu'ils ont une précédence normale. La valeur du champ précédence est alors 000b.

D, T et R sont des drapeaux que le protocole IP passe à 1 ou à 0 suivant leur validation/invalidation. D signifie "Delay", T signifie "Throughput" et R "Reliability". Par conséquent, si

  • D = 1 alors on demande à IP un faible retard de livraison du datagramme,
  • T = 1 alors on demande à IP d'utiliser le chemin le plus rapide pour émettre les données,
  • R = 1 alors on demande à IP d'assurer un transport le plus fiable possible.

Le champ "Time To Live" est une valeur exprimée en secondes. Elle représente le temps pendant lequel le datagramme peut circuler sur le réseau. Il faut donc voir ce champ comme une valeur d'expiration du datagramme. Ce champ est notamment modifié par les gateways : chaque fois que le datagramme passe par une gateway, la valeur du TTL est décrémentée. Ainsi, un paquet dont l'adresse IP n'existe pas ne restera pas indéfiniment sur le réseau.

Le champ "Proto" indique le protocole de plus haut niveau. Ce champ indique donc s'il s'agit d'UDP, de TCP ou de VMTP par exemple.

Le champ CRC calcule un checksum pour l'entête IP. Attention : les contrôles d'erreur d'IP ne concernent que les entêtes !

Le champ "Options" est variable. Toutefois, pour conserver des entêtes IP multiples de 32 bits, on utilise parfois un champ de bourrage dans lequel tous les bits sont mis à zéro. Le champ "Options" se subdivise en plusieurs zones :

Une option est toujours définie sur 8 bits. A cet octet s'ajoutent

  • n octets comprenant la valeur de l'option,
  • un octet indiquant la longueur de cette valeur.

Le bit "Copy" s'adresse aux gateways. Si ce bit est placé à un, lors de la fragmentation de paquets, les gateways devront recopier les options dans tous les fragments. Dans le cas contraire, les options ne sont pas copiées.

Le tableau ci-dessous reprend les classes et numéros d'option les plus courants :

Classe de l'option
Numéro de l'option dans la classe
Longueur de la valeur (octets)
Signification
0
0
1
Fin de la liste des options
0
1
1
Pas d'opération particulière à lancer
0
2
11
Mise en place de la sécurité et restriction d'utilisation
0
3
Variable
Demande le routage d'un datagramme par un chemin spécifique
0
7
Variable
Permet de suivre le chemin emprunté par un datagramme
0
8
4
Permet de transporter un identificateur de champ (utilisé par les couches supérieures).
0
9
Variable
Demande un routage strict des datagrammes par un chemin particulier
2
4
Variable
"Internet Timestamp". Demande le chronométrage de la transmission du datagramme

Chaque classe d'option a une signification particulière :

  • Classe 0 : Contrôle des datagrammes et du réseau,
  • Classe 1 : non utilisée actuellement,
  • Classe 2 : tests et mesures,
  • Classe 3 : non utilisée actuellement.

L'option 7 de la classe 0 est intéressante car elle demande à chaque gateway d'enregistrer les adresses IP utilisées pour véhiculer un paquet. Il est alors possible de mémoriser le chemin emprunté par un datagramme.

L'option 9 de la classe 0 permet d'imposer un chemin particulier pour le transport du datagramme. Cette option est donc directement suivie de la liste des adresses IP par lesquelles il faut passer. L'option 3 est une variante plus souple de la version 9 : il est possible de passer par une adresse IP non spécifiée dans la liste pour joindre deux adresses IP imposées (i.e. le chemin utilisé entre deux adresses IP imposées est laissé libre).

Enfin l'option 4 de la classe 2 contient une liste vide de valeurs lors de l'émission du datagramme. Chaque gateway écrit son adresse IP dans cette liste ainsi que l'heure et la date à laquelle le datagramme lui a été confié. Ainsi, tout comme un road book, la liste contient à l'arrivée du paquet, les passerelles par lesquelles il est passé ainsi que ses heures de passage.

1.7.2. Gestion de la fragmentation des datagrammes

Trois champs des datagrammes IP permettent la fragmentation et le ré-assemblage de ces derniers. Il s'agit des champs "Numéro de paquet", "Drapeaux" et "Numéro de fragment". Le numéro de paquet est codé sur 16 bits (valeur min = 0000000000000000b = 0d, valeur max = 1111111111111111b = 65535d). Les drapeaux comprennent 3 bits. Enfin, le numéro de fragment (ou plus exactement l'offset du fragment dans le datagramme complet) est défini sur 12 bits (valeur min = 000000000000b = 0d valeur max = 111111111111b = 4096d). Cette valeur est une mesure de 8 octets (à partir de 0). Tout datagramme IP peut donc prendre un numéro compris entre 0 et 65535 et être découpé en 4096 fragments.

Le premier de ces trois champs permet donc de numéroter chaque datagramme et le troisième champ indique l'emplacement de celui-ci dans le datagramme complet. Les trois bits utilisés par le champ "Drapeaux" ont chacun une signification particulière :

  • 1er bit : Si celui-ci est à 1, IP indique qu'il n'y a pas eu fragmentation. Dans ce cas, il n'est pas nécessaire de réassembler des données. Le champ "Numéro de fragment" est alors mis à 0 (et non relu à la réception du datagramme).
  • 2ème bit : S'il est placé à 1, IP relit alors le champ "Numéro de fragment".
  • 3ème bit : S'il est placé à 1, il spécifie qu'il s'agit du dernier fragment pour ce datagramme.

1.7.3. Routage des paquets IP

1.7.3.1. Routage à travers un seul réseau

Ce routage s'appuie alors sur le protocole ARP. IP émet une requête ARP pour connaître l'adresse physique de la machine cible. Une fois les adresses physiques connues des deux machines, les datagrammes IP sont encapsulés dans les trames Ethernet et transportées vers la machine cible.

Pour savoir si les machines cible et source appartiennent au même réseau, IP examine les deux adresses Internet des machines. En extrayant le champ "ID du réseau" des deux adresses et en comparant leur valeur, on doit obtenir le même résultat. Dans le cas contraire, il est nécessaire de passer par une gateway et l'on ne peut alors pas utiliser le protocole ARP.

1.7.3.2. Routage à travers plusieurs réseaux

Il est impératif pour IP de trouver la gateway la plus proche pour lui transmettre les datagrammes à envoyer sur un autre réseau. C'est pour cette raison que l'on considère les gateways comme des machines interconnectées dont les connexions permettent de relier tous les points IP du monde. Les datagrammes passent de gateway en gateway jusqu'à atteindre leur destination.

Les gateways utilisent des tables de routage pour établir les points IP qu'elles peuvent atteindre directement. Sur chaque machine ayant la connaissance de destinations externes au réseau physique sur lequel elle se trouve, il existe une table de routage. La machine examine l'adresse du réseau destinataire au lieu d'examiner l'adresse de la machine destinatrice. Ainsi donc, une table de routage est composée de couples (N, G) N désignant une adresse de réseau et G l'adresse de la gateway par laquelle il faut passer pour atteindre ce réseau. Une table de routage contient également les définitions des routages directs. Il est possible également de définir des routages par défaut. Ils permettent de réduire le nombre d'entrées dans la table de routage. Si une adresse n'est pas trouvée dans la table, on utilise alors le routage par défaut. Une autre possibilité est offerte par IP : il est possible de prévoir des chemins spécifiques vers une machine hôte. On garantit ainsi une certaine sécurité de transport en imposant un chemin unique par lequel tous les datagrammes destinés à cet hôte passeront.

1.7.3.3. Algorithme de routage des datagrammes

Route_IP_Datagram(Table de routage, Datagramme)

  • Extraire du datagramme l'adresse IP de la machine cible.
  • Extraire de cette adresse l'identifiant du réseau destinataire.
  • Si cet identifiant est égal à l'identifiant du réseau sur lequel on se trouve,
    • Lancer une requête ARP pour obtenir l'adresse physique de la machine cible,
    • Encapsuler le datagramme IP dans une trame Ethernet et l'émettre sur le réseau
  • Si les réseaux des machines source et cible sont différents,
    • Rechercher dans la table de routage la gateway à atteindre.
    • Par une requête ARP, obtenir l'adresse physique de cette machine.
    • Envoyer le datagramme à la gateway.

Nous verrons dans un autre chapître les protocoles de routage utilisé couramment par les gateways.

1.8. Conclusion

Le monde UNIX offre donc une famille de protocoles permettant de concevoir des applications tournant un réseau local ou un réseau WAN.

Nous avons présenté les protocoles des couches physiques. Pour un réseau local UNIX, on utilise toujours un réseau Ethernet. Ethernet offrent toutes les fonctionnalités des couches 1 et 2 du modèle OSI. Il se base sur une technologie de bus dont l'accès est partagé.

La couche 3 est ensuite occupée essentiellement par le protocole IP. Celui-ci fonctionne en mode datagramme. Il est non sécurisé et nécessite donc l'utilisation d'une couche de transport fiable. IP partage la couche 3 avec les protocoles ARP, RARP, ICMP et les protocoles de routage. Nous avons dans ce document présenté ARP et RARP. Ces derniers permettent d'établir une équivalence bijective entre les adresses physiques des machines (ou adresses Ethernet) et leurs adresses Internet (ou adresses IP).

Nous examinerons dans les prochains chapitres

  • le protocole ICMP qui permet de contrôler le réseau,
  • les protocoles de routage,
  • le protocole UDP (appartenant à la couche transport),
  • le protocole TCP (appartenant également à la couche transport),
  • enfin les principales applications et les protocoles s'appuyant sur TCP/IP ou UDP/IP.


2. Le protocole ICMP

2.1. Introduction

Le protocole IP fournit un transfert non sécurisé de transmission des paquets en mode datagramme. Il existe un mécanisme que les gateways et les machines (que nous appelerons désormais les "hosts") utilisent pour échanger des informations de contrôle et/ou d'erreurs pouvant être nécessaires durant le transfert des datagrammes IP.

Les gateways utilisent ce mécanisme pour remonter ce que l'on appelle des "delivery problems" et les hosts les emploient pour tester si les destinations peuvent être atteintes.

2.2. ICMP (Internet Control Message Protocol)

Le protocole IP en lui-même ne contient rien pour aider l'émetteur de datagrammes à tester la connexion de bout en bout ou de s'informer de pannes sur des noeuds du réseau. Pour permettre aux machines de l'Internet de remonter des erreurs ou de fournir des informations concernant des anomalies, un mécanisme spécial de comunication par messages a été ajouté à la famille des protocoles IP. Ce protocole est ICMP (Internet Control Message Protocol).

Les messages d'ICMP sont encapsulés dans les datagrammes IP tout comme les données des couches protocolaires s'appuyant sur IP (i.e. TCP et UDP). La destination du message n'est par contre pas un host mais la couche logicielle de la machine à laquelle on souhaite envoyer le message IP.

Puisque les messages ICMP sont véhiculées dans des datagrammes IP, ils ont le format suivant :

La seule différence avec les autres données encapsulées dans le datagramme IP réside dans la gestion des erreurs : si ce paquet provoque une erreur IP lors de son cheminement sur le réseau, il n'y a pas création d'une trame d'erreur pour le signaler. Il n'est en effet pas intéressant de créer une trame d'erreur concernant un message d'erreur !

Tous les messages ICMP ont un format particulier permettant de reconnaître - dès lecture des premiers octets qui les composent - le type de message. Ainsi la structure du datagramme est découpée comme suit :

Il existe plusieurs types de messages que nous allons examiner dans ce document :

Valeur décimale du champ type
Signification du message ICMP
00
Echo Reply
03
Destination Unreachable
04
Source Quench
05
Redirect (change of route)
08
Echo Request
11
Time Exceeded for a Datagram
12
Parameter Problem for a Datagram
13
Timestamp Request
14
Timestamp Reply
15
Information Request
16
Information Reply
17
Address Mask Request
18
Address Mask Reply

Le champ CODE fournit des informations complémentaires sur le type de message. Enfin, le CheckSum, calculé selon le même algorithme qu'IP, représente le CRC des données ICMP (il n'inclut pas lors de sa détermination les octets de l'entête IP).

2.3. Les différents messages d'ICMP

2.3.1. Test d'une destination

Ce test correspond à l'émission d'un message ICMP du type "Echo Request". Ce message entraîne le renvoi d'un message ICMP du type "Echo Reply". Le message "Echo Request" est émis par un host pour vérifier si le host qu'il souhaite atteindre est présent sur le réseau et est capable de répondre aux messages ICMP. Si tel est le cas, on vérifie par ce mécanisme que la machine distante est bien connectée sur le réseau mais on vérifie également que sa couche protocolaire IP répond correctement.

Le message ICMP correspondant à l'Echo Request a cette structure :

Le champ "CODE" prend toujours la valeur 0 quand il s'agit d'un message ECHO. Les champs "Identifiant ICMP" et "Numéro de séquence ICMP" sont deux numéros établis par les machines afin de reconnaître les trames ICMP entre elles (il est en effet possible d'envoyer plusieurs requêtes d'écho - il est par conséquent nécessaire de les numéroter pour l'émetteur et le récepteur).

Un champ optionnel est réservé pour l'écriture d'un message. Ce message doit être retourné sans aucune modification par la machine dont on teste la connexion IP. Ce champ est donc une sécurité supplémentaire. Le Checksum des messages ICMP d'écho tiennent bien sûr compte de ces données optionnelles.

La structure du message "Echo Reply" est la même ; seule la valeur du champ TYPE est modifiée :

2.3.2. Réponse d'une destination injoignable

Le message ICMP "Destination Unreachable" est envoyé par une gateway qui ne peut pas expédier correctement un datagramme IP vers un host. Ce message est bien évidemment envoyé à l'émetteur du datagramme.

La structure d'un tel message est la suivante :

Dans le cas présent, le code peut prendre plusieurs valeurs (car l'on peut déterminer de manière présente la cause de ce rejet de trame) :

Valeur décimale du champ code
Signification précise du message ICMP
00
Network Unreachable
01
Host Unreachable
02
Protocol Unreachable
03
Port Unreachable
04
Fragmentation Needed and flag DF (Don't Fragment) set
05
Source Route Failed

Nous constatons qu'il est possible à ICMP de signaler des erreurs induites par les couches protocolaires s'appuyant sur IP ("Protocol Unreachable" pourrait signifier que le protocole TCP de la machine distante ne répond pas). Il en est de même pour les protocoles s'appuyant sur TCP et UDP. Ces derniers sont définis sur des ports spécifiques de la machine. Là encore, ICMP peut indiquer à l'émetteur que le port 21 du FTP distant ne répond pas correctement.

La trame ICMP contient en plus du statut d'erreur l'entête IP de la trame ayant déclanché ce message ainsi que les 64 premiers bits du datagramme. Ces informations permettent à l'émetteur de retrouver quel datagramme il ne peut pas envoyer ou éventuellement quel datagramme il doit ré-émettre.

2.3.3. Contrôle de flux des datagrammes IP

Si un host (ou une gateway) reçoit les datagrammes trop vite (et que par conséquent il en perd !) il émet un message ICMP "Source Quench" pour que l'émetteur résuide le débit d'émission des trames IP.

N.B. : Un message de ce type est émis pour toutes les trames engorgées : elles seront donc toutes ré-émises correctement.

Algorithme de ré-émission des datagrammes IP : la machine qui reçoit l'ordre de réduire le débit de transmission des datagrammes IP diminue progressivement ce rythme de transfert jusqu'à ce qu'il ne reçoive plus aucun message "Source Quench" de la part du récepteur.

Un message "Source Quench" se décompose comme suit :

Comme nous l'avons expliqué, on retourne un message "Source Quench" pour chaque datagramme engorgé. Par conséquent, le moyen de l'authentifier auprès de l'émetteur consiste à retourner l'entête IP du datagramme.

2.3.4. Requêtes de reroutage émis par une gateway

Les tables de routage sont en général statiques. Les machines les chargent en mémoire à partir d'un fichier disque (/etc/hosts) lors de leur démarrage. Ce routage peut pourtant évolué dans la journée (arrivée d'une nouvelle machine sur le réseau, panne d'une gateway...).

Les gateways échangent régulièrement leurs tables de routage pour rester à jour. Si une gateway constate qu'un host n'est pas à jour (i.e. qu'il n'utilise plus un plan de routage correct), elle envoie un message "Redirect" vers le host concerné.

Une restriction réside dans ce mécanisme : une gateway ne peut informer que les hosts situés sur le même réseau qu'elle. Un protocole de couche supérieur est nécessaire pour diffuser des informations de routage sur plusieurs réseaux.

Un message "Redirect" se présente comme suit :

Le message contient donc l'adresse Internet de la gateway par laquelle l'émetteur devra désormais passer. Afin qu'il reconnaisse le datagramme qu'il doit ré-expédier, l'entête IP de ce datagramme ainsi que les 64 premiers octets qui le composait lui sont retournés.

Le champ code peut prendre plusieurs valeurs car il est possible que le nouveau plan de routage concerne un réseau, une machine ou même un service :

Valeur décimale du champ code
Signification précise du message ICMP
00
Redirect Datagram for the Network
01
Redirect Datagram for the Host
02
Redirect Datagram for the type of service and Network
03
Redirect Datagram for the type of service and Host

2.3.5. Détection de bouclage ou de cheminement trop long

Ce message est basé sur la notion de TTL (Time To Live) du protocole IP. Lorsqu'un datagramme IP est construit, un temps de vie lui est accordé sur le réseau. Ce temps est le champ TTL du datagramme IP.

Chaque gateway décrémente le TTL au passage d'un datagramme IP jusqu'à ce que ce datagramme atteigne soit sa destination (et dans ce cas tout va pour le mieux dans le meilleur des Unix) soit la valeur 0 et c'est alors que les ennuis commencent pour lui ! La famille de protocoles IP considère qu'un paquet dont le temps de transit est dépassé ne doit pas rester sur le réseau. Un message annonçant sa destriction est retourné à l'émetteur. Ce message est du type "Time Exceeded".

Les messages ICMP "Time Exceeded" se construisent de la manière suivante :

Le champ code peut prendre deux valeurs :

  • valeur 0 : "TTL Exceeded".
    Le champ TTL du datagramme IP est passé à zéro. On retourne l'entête de ce datagramme afin que l'émetteur sache quel datagramme sera perdu.
  • valeur 1 : "Fragment ReAssembly Time Exceeded".
    Quand il y a eu fragmentation de données, le host destinataire déclenche un timer dès qu'il reçoit le premier datagramme de données. Il émet ensuite une erreur si le timer passe à zéro alors que les paquets n'ont pas été reconstitués. Le récepteur est alors à l'inititiative du message ICMP.

2.3.6. Retour d'une entête incorrecte

Il est possible que l'entête d'une trame IP soit incorrect (un code d'option est faux par exemple). Dans ce cas, la machine réceptrice retourne un message ICMP à l'émetteur de cette trame érronée. La structure du message ICMP "Parameter Problem" est la suivante :

Le champ pointeur indique la position de l'octet erroné. Le début du datagramme est retourné pour que l'émetteur ré-émette correctement son datagramme IP.

2.3.7. Synchronisation d'horloge et estimation du temps de transit

Le message "Timestamp Request" permet de demander à un host son heure et sa date système (attention, les machines Unix se basent sur un horaire universel). Tout message "Timestamp Request" correspond à un message réponse "Timestamp Reply".

La structure d'un message "Timestamp Request" est la suivante :

Les champs "Identifiant ICMP" et "Numéro de séquence ICMP" permettent à l'émetteur de reconnaître le message ICMP.

Chaque temps donné par les machines sont définis en millisecondes à partir de minuit (respect de l'heure universelle). Le premier temps est écrit par l'émetteur au moment où il émet ce message. Le deuxième temps est fourni par le récepteur au moment où il a reçu le message. Enfin le troisième temps est inscrit par le récepteur au moment où il retourne le message à l'expéditeur. Ainsi donc, l'émetteur du message est capable de déterminer :

  • le temps de transit sur le réseau entre les deux machines (à partir des deux premières données temporelles),
  • le temps nécessaire à un aller-retour de datagramme IP entre ces deux machines.

Les hosts peuvent déduire de ces valeurs les temps estimés de transmission de leurs données et par conséquent

  • positionner correctement les paramètres TTL des datagrammes IP,
  • lors d'une émission de datagrammes fragmentés, établir un timer correct afin de vérifier la bonne reconstitution des datagrammes.

La structure d'un message "Timestamp Reply" est identique : seul le champ TYPE change de valeur :

2.3.8. Demande d'une adresse réseau

Cette demande est une alternative aux requêtes RARP (Reverse Address Resolution Protocol). Un message "Information Request" permet de demander au réseau l'adresse IP dont il a besoin. Dans l'entête IP de ce message, il met donc à 0 l'adresse IP de destination et construit un message ICMP comme suit :

La valeur 15 du champ TYPE correspond à un message "Information Request". En réponse à ce message est construit un nouveau message ICMP "Information Reply" dont le champ TYPE prend la valeur 16. L'adresse IP recherchée est écrite dans le dernier champ de ce message :

2.3.9. Demande d'un masque de sous-réseau

Ce type de message est similaire à la demande d'une adresse réseau. Nous n'expliquerons donc pas son fonctionnement.

Le message émis par le demandeur est du type "Address Mask Request" et se présente comme suit :

En réponse à ce message est retourné un message "Address Mask Response" défini ainsi :

2.4. Conclusion

Nous avons donc constaté que le protocole ICMP permettait de véhiculer des messages informatifs ou bien des messages d'interrogation.

Il faut bien garder à l'esprit qu'ICMP est un complément indispensable au protocole IP qui ne propose pas de mécanisme d'émission/réception de messages.

ICMP est toujours fourni avec les protocoles de la famille IP car il est indispensable : il est utilisé par d'autres protocoles des couches supérieures pour gérer au mieux les échanges de données via TCP/IP.


3. Les protocoles de routage

3.1. Introduction

Nous avons constaté que le monde UNIX était très hétérogène ; beaucoup de machines d'architecture différente utilisent l'Internet. Ce réseau modial étant très fortement maillé, il est nécessaire d'établir des mécanismes de routage des paquets de données. Nous avons appris qu'IP était capable d'envoyer directement des données sur un réseau local. Il n'est par contre pas prévu pour router des datagrammes sur un réseau mondial.

On se base alors sur des machines ayant une connaissance partielle du réseau WAN. Cette connaissance partielle est suffisante pour diriger les flux de données vers la bonne destination. Ainsi, les données passent par ces machines jusqu'à atteindre leur destination finale. Ces machines sont appelées des passerelles ou gateways.

Les gateways hébergent donc des protocoles leur permettant d'établir les plans de route des datagrammes IP qu'elles reçoivent. Il faut pour comprendre leur fonctionnement imaginer un gigantesque carrefour possédant un grand nombre de branches. La passerelle reçoit un datagramme par l'une de ces branches, recherche la branche qui convient le mieux au trajet qu'il doit suivre, enfin l'oriente et l'envoie dans la bonne direction.

Les gateways se basent sur une table de routage pour établir les plans de route. Ainsi donc, une table de routage est composée de couples (N, G) N désignant une adresse de réseau et G l'adresse de la gateway par laquelle il faut passer pour atteindre ce réseau. Une table de routage contient également les définitions des routages directs. Il est possible également de définir des routages par défaut. Ils permettent de réduire le nombre d'entrées dans la table de routage. Si une adresse n'est pas trouvée dans la table, on utilise alors le routage par défaut. Une autre possibilité est offerte par IP : il est possible de prévoir des chemins spécifiques vers une machine hôte. On garantit ainsi une certaine sécurité de transport en imposant un chemin unique par lequel tous les datagrammes destinés à cet hôte passeront.

Chaque gateway doit se poser deux questions :

  • Comment puis-je initialiser ma table de routage (ou aller chercher les informations) ?
  • Comment mettre à jour cette table en fonction de l'évolution des réseaux que je peux atteindre ?

Pour une machine UNIX, la première question possède une réponse simple : le réseau local de la gateway (ou même sur la machine qui sert de gateway), il existe une table de configuration statique dans le répertoire /etc. Cette table est issue de trois fichiers système :

  • "/etc/hosts" qui contient les noms des machines connues. En général, ce fichier contient à 95% les adresses IP des machines du réseau local.
  • "/etc/networks" qui contient la liste des réseaux connus par la machine.
  • enfin "/etc/gateways" qui contient la liste des gateways que l'on peut atteindre.

Deux daemons différents gèrent ensuite le problème du routage statique et du routage dynamique. Nous verrons lors de la présentation concrète sur machine UNIX les daemons "routed" et "gated".

Il existe de par le monde deux types de gateways :

  • les "Core Gateways". Ces machines sont officiellement responsables du routage des datagrammes IP dans le monde. Elles sont gérées par un organisme américain qui est l'INOC (Internet Network Operations Center). Ces machines ont pour rôle de garantir le routage autorisé des datagrammes IP entre différents réseaux. Ces machines agissent donc "en haut" du réseau Internet. Toutes les core gateways communiquent entre elles. Par conséquence, la vision qu'elles ont de l'Internet est homogène ce qui garantit la cohérence du réseau.
  • les "Non-Core Gateways". A l'inverse des core gateways, elles ne présentent aucun caractère officiel. Il s'agit typiquement de la passerelle qu'une société met en place entre deux brins Ethernet dans l'un de ses bâtiments.

Nous allons donc décrire tous les mécanismes internes à ces machines ainsi que les protocoles qui en permettent le fonctionnement.

3.2. GGP (Gateway to Gateway Protocol)

Ce protocole a été créé à l'origine pour les Core Gateways de l'Internet afin d'échanger des informations de routage entre ces entités. Les messages du protocole GGP sont encapsulés dans des datagrammes IP.

GGP gère l'ajout d'une Core Gateway dans le réseau. Quand une gateway de ce type est ajoutée, on lui définit un ensemble de voisins proches avec lesquels elle peut communiquer. Ces voisins se chargeront de diffuser l'arrivée de la nouvelle passerelle.

Les gateways échangent en fait des couples (N,D) où N représente l'adresse d'un réseau et D la distance nécessaire pour l'atteindre. Attention toutefois : il ne s'agit pas d'une distance en kilomètres mais d'une distance en nombre de gateways à passer. On dit que D = 0 quand une gateway peut atteindre directement un réseau ou une machine.

Il est donc possible - pour chaque passerelle - d'optimiser le chemin de routage d'un datagramme. Dans ce cas, la passerelle modifie sa table de routage en fonction de cette information.

Il existe quatre types de messages GGP qui ont chacun un format particulier. Les huit premiers bits d'un message GGP permettent de déterminer le type du message émis.

3.2.1. Message de mise à jour d'un routage

Un message de mise à jour d'un routage se compose des champs suivants :

Le champ Type prend la valeur 12 pour spécifier qu'il s'agit d'une mise à jour de configuration de routage. Le numéro de séquence permet à GGP d'utiliser des aquittements dès réception des messages de mise à jour. Le champ "Mise à jour" permet de différencier le sens de la demande :

  • si l'émetteur souhaite obtenir des informations de mise à jour, il place à 1 ce champ. Par conséquent, le reste du message n'est pas complété,
  • si l'émetteur souhaite fournir des informations de mise à jour, il passe ce champ à 0.

Enfin le champ "Nb Distance" indique le nombre de distances Dx dont on remet à jour le routage. Il est donc possible comme le montre l'exemple de remettre à jour en même temps les routages D1 et D2.

3.2.2. Message d'aquittement

Quand une gateway a reçu un message de mise à jour de routage, elle retourne un message d'aquittement dont la structure est très simple :

Le type vaut toujours 2 pour l'aquittement d'un message. A l'inverse, il vaut 10 si le message a mal été transmis. Dans les deux cas, le numéro de message désigne le numéro du dernier message correctement reçu.

3.2.3. Message Echo

Il est possible qu'une gateway souhaite vérifier la présence d'une autre gateway (par exemple si celle-ci ne répond pas ou si elle ne route plus de datagrammes IP). Dans ce cas, on émet un message "Echo Request" auquel la machine interrogée devra répondre par un message "Echo Reply" :

Le type de message prend la valeur 8 pour un message "Echo Request" et la valeur 0 pour un message "Echo Reply".

3.2.4. Message bouclé

Le dernier type de message permet à une gateway de tester ses couches locales d'interface réseau. Elle teste ainsi si sa connexion au réseau est correcte et que par conséquent si une autre gateway peut la joindre. Le message se présente comme suit :

Le type du message est égal à 9.

Inconvénients de GGP :

Ce protocole nécessite une mise à jour général des routes. Ainsi, il est possible d'engorger le trafic si les gateways se remettent régulièrement à jour les unes les autres. De plus, les informations de mise à jour occupent beaucoup d'octets car l'on définit tout le trajet (Dx) pour atteindre un point du réseau. Par conséquent, les messages de mise à jour par GGP peuvent saturer rapidement un réseau. Le dernier inconvénient de GGP est qu'il n'est autorisé que sur les Core Gateways : une passerelle quelconque peut interroger ces Core Gateways mais ne peut pas les mettre à jour. L'ensemble de ces inconvénients obligent à recourir à d'autres protocoles.

3.3. EGP (Exterior Gateway Protocol)

Un protocole complémentaire à GGP est nécessaire pour pallier deux problèmes :

  • Un mécanisme est nécessaire pour permettre aux passerelles n'appartenant pas à l'INOC d'apprendre de ces dernières les routes optimales de cheminement des datagrammes IP.
  • Comme Internet est un réseau mondial immense, les core gateways ne peuvent pas connaître toutes les connexions qu'il renferme. Aussi, un mécanisme est nécessaire afin qu'une passerelle quelconque puisse informer une core gateway d'un changement de réseau.

Il est important de noter qu'Internet considère qu'un réseau d'entreprise ayant un ensemble complexe de réseaux et de gateways forme une unique entité et est administrativement considérée comme un système autonome. Ce système autonome possède son propre protocole de routage (ce n'est pas forcément EGP !). Ce système a donc pour responsabilité de

  • collecter les informations nécessaires pour atteindre les machines de son réseau
  • choisir les machines sur lesquelles ces informations seront diffusées (ce qui implique des problèmes de sécurité).

Nous verrons donc qu'il est possible d'utiliser des protocoles tels que RIP pour collecter ces informations. Le choix du protocole de routage au sein même d'un site ne concerne que les administrateurs de ce site. Dans tous les cas, il est nécessaire d'utiliser EGP entre deux systèmes autonomes pour échanger les informations de routage. EGP est de plus le seul protocole permettant de dialoguer avec les core gateways.

3.3.1. Entête des messages EGP

Les 9 messages d'EGP présentent la même entête :

Le premier champ indique le numéro de version d'EGP employé. La dernière version d'EGP est la version 3. Le champ type du message peut donc prendre neuf valeurs différentes. Celles-ci sont présentées dans le tableau ci-dessous :

Type de message EGP
Signification
Acquisition RequestDemande à une gateway de devenir voisin (acceptation de voisinage).
Acquisition ConfirmRéponse positive à un message Acquisition Request
Acquisition RefuseRéponse négative à un message Acquisition Request
Cease RequestDemande de fin de voisinage (arrêt du dialogue EGP entre deux voisins).
Cease ConfirmRéponse positive à un message Cease Request
Hello RequestDemande à un voisin de signaler s'il fonctionne.
I-Heard-YouRéponse à un message "Hello Request"
Poll RequestDemande d'update d'une configuration de routage
Routing UpdateInformation de mise à jour du routage
ErrorAnnonce un message incorrect

Le champ Code vient en complément du champ type car il existe des variantes de ces messages. Pour certains messages, il est également nécessaire de transporter une valeur de status.

EGP utilise le même algorithme qu'IP pour calculer le CRC de son message. Celui-ci est codé sur 16 bits.

Le champ "Numéro de système autonome" désigne le site. Enfin, le numéro de séquence représente le numéro du message EGP pour ce site.

3.3.2. Demande de relation de voisinage

Pour que deux gateways échangent des informations de routage par EGP, il faut qu'elles se soient chacune accorder le droit de le faire. Pour cela, on utilise les messages "Acquisition Request" dont la structure est la suivante :

Le champ "code" peut prendre cinq valeurs différentes :

  • Code = 0 message "Acquisition Request"
  • Code = 1 message "Acquisition Confirm"
  • Code = 2 message "Acquisition Refuse"
  • Code = 3 message "Cease Request"
  • Code = 4 message "Cease Refuse"

D'autre part, lors de la demande de collaboration des deux gateways, chacune d'elles transmet une valeur d'intervalle pour

  • l'émission des requêtes "Hello" (afin de tester régulièrement si les gateways fonctionnent),
  • l'émission des requêtes "Poll" pour la mise à jour régulière des tables de routage. Il est possible d'avoir des intervalles de temps différents pour un dialogue Gateway1 - Gateway2 et pour un dialogue Gateway2 -nbsp;Gateway1.

3.3.3. Message de vérification de fonctionnement (Hello

Ce type de message permet de tester si une gateway est toujours connectée et qu'elle assure le routage. Pour cela, un message de question/réponse permet de vérifier, à intervalle régulier, s'il n'y a pas de rupture de service. Un message "Hello Request" se présente comme suit :

Le champ "code" peut prendre deux valeurs différentes :

  • Code = 0 message "Hello Request"
  • Code = 1 message "I-Heard-You"

3.3.4. Demande de mise à jour du routage

Contrairement au protocole GGP, EGP n'émet qu'une partie du plan de routage des réseaux. Ce protocole demande donc dans les messages de demande de mise à jour, les modifications de routage concernant telle adresse Internet. Les messages "Poll Request" se présentent donc ainsi :

Le champ "Adresse Internet demandée" comprend donc l'adresse d'un réseau auquel les deux gateways ont la possibilité d'accéder (d'après le respect des droits de voisinage).

3.3.5. Message de mise à jour d'un routage

A la demande de mise à jour d'un routage est retourné un message "Routing Update". Il est important de noter qu'EGP permet aux non-core gateways d'avertir uniquement les systèmes anonymes dont elles ont un entier accès.

Un message de mise à jour est très complexe :

3.4. Les protocoles privés : RIP, HELLO et GATED

Les protocoles RIP et HELLO doivent donc être propres à un site. Ils ne peuvent pas remplacer le protocole EGP. Pour ces deux protocoles, on parle de voisinage interne (en opposition avec le voisinage externe d'EGP). Une gateway peut donc être amenée à utiliser deux protocoles de routage en même temps : elle utilise d'une part EGP pour communiquer à l'externe du système qu'elle gère ; d'autre part, elle emploie indifféremment RIP ou HELLO pour son routage interne.

Nous verrons que GATED est multi-protocoles.

3.4.1. RIP (Routing Information Protocol)

3.4.1.1. Présentation du protocole

RIP est le protocole le plus utilisé. RIP utilise des messages Broadcast pour diffuser les informations de routage et les mettre à jour partout en même temps. "Routed" est le nom de baptème de ce protocole (créé par Rank Xerox). Il prit le nom de RIP lorsque son utilisation fut étendu à des machines d'autres constructeurs. RIP n'est pas un protocole très performant. Cependant, parce qu'il a été fourni en standard avec le système UNIX BSD 3.XX, il s'est imposé comme un standard de fait.

Le principe de fonctionnement de RIP est simple : les gateways émettent régulièrement par broadcast la mise à jour de leur routage. Les destinataires sont là encore des voisins au sens EGP du terme. Contrairement à EGP, le décompte des distances est calculé par rapport à la table de routage courante de la machine (la mesure est donc un delta et non plus un indice absolu).

Trois problèmes ne sont pas traités par le protocole :

RIP ne vérifie pas le bouclage des routages. On considère alors que les administrateurs vérifient la cohérence de leur routage.

Si une distance est infinie (attention, il s'agit d'un delta), la valeur du champ distance vaut 15. Le problème est donc simple : s'il est nécessaire de passer par 15 gateways supplémentaires pour atteindre une machine, le protocole assimile ce chemin à un parcours infini et considère donc la machine comme injoignable.

La mise à jour du routage d'un réseau est lente car chaque gateway peut atteindre 14 gateways voisines (au delà, on atteind l'infini). Le rayon d'action de chaque passerelle étant restreint de la sorte, couvrir l'ensemble du réseau implique l'émission de nombreux messages à partir de toutes les gateways.

3.4.1.2. Structure des messages RIP

Il existe deux types de messages RIP :

  • les messages broadcast de diffusion des mises à jour,
  • les messages de contrôle et de debbuggage.

Bien sûr, les messages broadcast sont les plus importants. Nous n'examinons que ces derniers. Ces messages comprennent une entête fixe suivie d'une liste des routes :

Le champ "Commande" prend la valeur 1 lorsque le message est une demande de mise à jour et la valeur 2 lorsqu'il s'agit d'une mise à jour. Toutefois, les gateways émettent régulièrement des messages de mise à jour sans avoir été sollicitée par un message d'interrogation.

RIP présente un avantage très intéressant par rapport aux autres protocoles de routage : il peut gérer différents types de réseau (pas uniquement Internet donc). En effet, le champ "Famille du réseau n" permet de spécifier le type de réseau. Il est par conséquent possible de transmettre des informations de routage de réseaux hétérogènes. Pour ce faire, les adresses de réseau sont codées sur 14 octets comme le montre le message ci-dessus. Internet n'en utilise que 4 ; les autres octets sont donc mis à zéro.

3.4.2. HELLO

3.4.2.1. Présentation du protocole

Le protocole HELLO diverge d'EGP et de RIP pour une unique raison : les distances entre deux points du réseau ne sont pas calculées en fonction du nombre de gateways qu'il est nécessaire de traverser mais en fonction du temps de trajet.

HELLO est utilisé sur le backbone NFSNet d'Internet ce qui lui donne un certain poids. Par conséquent, ce protocole ne doit pas être trop vite oublié.

HELLO offre deux fonctionnalités :

  • il permet la synchronisation des horloges de différentes passerelles.
  • il offre la possibilité à chaque passerelle de calculer le délai le plus court pour atteindre une destination.

Par conséquent, les messages du protocole HELLO contiennent des informations de routage et des données temporelles (des timestamps dans le jargon UNIX). Avant de transmettre un message, une machine ajoute son "timestamp" dans le message HELLO. La technique est simple : puisque les passerelles sont synchronisées, poser un "timestamp" consiste à inscrire dans le message l'heure courante.

L'algorithme de calcul des routes les plus rapides est celui du protocole EGP. La seule différence entre les deux calculs résident dans les unités employées : EGP travaille en nombre de passerelles alors qu'HELLO travaille en nombre de secondes.

3.4.2.2. Structure des messages HELLO

Un message HELLO se décompose suivant les champs suivants :

Le champ "Date" contient la date d'émission du message (c'est-à-dire la date système de la première machine). De la même manière, le champ "Heure" représente l'heure système de la première passerelle. Le champ "Timestamp" est constitué lors de l'envoi du message et est utilisé pour le calcul des temps de transport.

Le champ "Nb machines" est augmenté par chaque passerelle dès réception du message. Elle permet de connaître le nombre de couples (DTi - Offseti) contenus dans le message. La passerelle j qui reçoit ce message écrit la valeur j dans ce message et écrit ces données dans la zone j.

Chaque temps DTi représente le temps nécessaire pour joindre une autre passerelle. Son calcul est simple : dès réception du message, la passerelle déterminet la différence entre sa date et son heure système avec celles de la machine émettrice. Suivant son heure courante, elle peut en déduire le temps qui s'est écoulé durant le transport du message. Afin que chaque passerelle puisse réaliser ce calcul, la passerelle écrit dans le champ Offset la différence de temps existant entre son heure système et celle de la machine émettrice.

3.4.3. Le protocole GATED

GATED est plus exactement un programme UNIX. Il combine les protocoles RIP, HELLO et EGP pour offrir une seule interface logicielle de gestion de routage. Gated gère des messages de type RIP et HELLO et modifie les tables de routage locales comme le fait le programme ROUTED. Pour avertir le réseau externe d'une modification de son routage, GATED utilise le protocole EGP ; à l'inverse, s'il souhaite mettre à jour des données de routage en interne, il utilise soit HELLO soit RIP.

3.5. Conclusion

Le routage des datagrammes IP est essentiel dans le monde de l'Internet. Sur un réseau local, les protocoles ARP et IP suffisent pour transmettre des données entre deux machines. Sur un réseau WAN hétérogènes, on utilise des passerelles qui se chargent de transporter "intelligemment" les données vers leur destination finale. Il existe dans le monde deux types de passerelles : les core gateways et les noncore gateways. Les core gateways sont des machines officiellement administrées par l'INOC alors que les noncore gateways n'ont pas de caractéristisques particulières.

Plusieurs protocoles permettent le transport des datagrammes à travers ces passerelles. GGP est le seul protocole utilisé par les core gateways. Entre deux sites différents (ou deux réseaux privés différents), les gateways utilisent le protocole EGP. A l'interne d'un réseau privé, on utilise souvent le protocole RIP mais il existe à cet usage (HELLO est le plus connu après RIP).


4. Le protocole TCP

4.1. Introduction

Le protocole IP fournit un transfert non sécurisé de transmission des paquets en mode datagramme. Ce protocole assure la fonction de la couche 3 du modèle OSI. La couche transport (couche 4 selon la représentation OSI) comprend - dans le monde UNIX - trois protocoles essentiellement : UDP, TCP et VMTP. UDP et TCP sont les plus utilisés.

Le protocole TCP est plus complexe que le protocole UDP mais il offre un transport sécurisé des données ainsi qu'un certain nombre de contrôle comme nous allons le voir.

4.2. TCP (Transport Control Protocol)

Le protocole TCP peut fonctionner sur d'autres couches 3 que la couche IP (contrairement au protocole UDP). TCP offre une couche simple et harmonieuse pour interfacer une application et la couche IP.

L'interface entre les applications et la couche TCP (que l'on nomme en anglais "The Internet Stream Delivery Service") présente cinq caractéristiques essentielles :

4.2.1. Fonctionnement par flux (stream orientation)

Deux applications échangeant de gros volumes de données s'échangent en fait des flux de bits. TCP est le service protocolaire permettant une transmission sécurisée de ces flux.

4.2.2. Connexion par circuit virtuel

Quatre étapes ponctuent le fonctionnement d'une connexion par TCP :

Avant le transfert des données, émetteur et récepteur échangent des données nécessaires à leur couche protocolaire. On utilise la notion de "Call Accept" (comme par le protocole X25).

Les couches protocolaires échangent des messages pour vérifier que le transfert est possible et autorisé.

Une fois les vérifications faites, la couche transport informe l'application qu'elle peut utiliser la connexion qui vient d'être établie. La couche applicative voit donc la connexion comme un tuyau bi-directionnel dans lequel les données (structurées ou non) vont être véhiculées.

Durant le transfert, les couches transport poursuivent leur dialogue indépendamment des dialogues des couches applicatives (ou plus exactement de manière transparente pour ces couches 7 du modèle OSI). Ce dialogue a pour but de

  • vérifier que les données arrivent vers la bonne destination, sans déterioration et sans engorgement du réseau.
  • rétablir la connexion si celle-ci est "tombée" durant le transfert.

4.2.3. Transfert bufferisé

L'application émet et reçoit les données au rythme et suivant les volumes qu'elle souhaite. La couche transport découpe de manière transparente ces buffers pour les passer à la couche IP. Ce découpage entraîne la création de paquets. TCP optimise ce découpage afin de garantir le meilleur débit possible. Pour ce faire, il lui est possible de temporiser l'émission de données en attendant le remplissage complet d'un paquet à transmettre à la couche IP.

Il est possible pour certaines applications d'utiliser une méthode "push" pour envoyer les données au rythme de l'application : on peut par exemple envoyer les données octet par octet. Le contrôle de flux offert par TCP est alors inintéressant.

4.2.4. Flux non structuré

La couche TCP n'impose pas une structure particulière aux données véhiculées : il considère les données applicatives comme des boîtes noires. Cette technique donne une certaine souplesse d'utilisation.

4.2.5. Connexion bi-directionnelle (ou mode full duplex)

Les transferts peuvent s'effectuer simultanément dans les deux sens. Il n'y a pas de contrainte spécifique.

4.3. Transport sécurisé par TCP

TCP se base sur des ACKnowledges "positifs" avec retransmission possible des paquets invalidés. Cette solution implique la possibilité de transmettre des messages d'aquittement.

L'émetteur conserve un enregistrement des paquets émis et attend un ACKnowledge pour émettre le paquet suivant :

Il arme également un timer et retransmet le paquet si ce timer est expiré (i.e. s'il est revenu à zéro).

Inconvénient de cette méthode : l'émission se déroule paquet par paquet. TCP introduit donc la notion de fenêtre glissante : l'émetteur peut envoyer plusieurs paquets avant réception d'un aquittement (cf schéma ci-dessous).

4.4. Fonctionnement de TCP

Comme le protocole UDP, TCP peut s'encapsuler dans les datagrammes IP :

Nous allons détailler plusieurs caractéristiques essentielles propres au protocole TCP.

4.4.1. Taille de fenêtre variable et contrôle de flux

Le protocole TCP autorise la modification de la taille de la fenêtre d'aquittement des paquets. TCP utilise une technique de fenêtre glissante dont la taille pourrait être quelconque. En voici un exemple :

Ce déplacement de fenêtre a été autorisé grâce à l'émission dun paquet ACK. Dans ce paquet TCP, on retourne le nombre d'octets ayant été reçus ainsi que le nombre d'octets supplémentaires que la machine réceptrice est capable d'accepter. Par exemple, si 400 octets ont été reçus correctement et que la machine réceptrice pourrait en recevoir 800 selon le même débit, elle avertit l'émetteur qu'elle peut accepter 400 octets supplémentaires. Ainsi donc, l'émetteur modifiera la fenêtre d'aquittement en conséquence. De la même manière, si la machine réceptrice reçoit des buffers trop gros, elle utilise ce mécanisme pour que l'émetteur réduise la fenêtre d'aquittement. Si les buffers de réception sont pleins, le récepteur peut mettre la taille de sa fenêtre de réception à zéro. Dans ce cas, l'émetteur arrête le trafic TCP jusqu'à ce que le récepteur autorise de nouveau le dialogue. Aucune donnée n'est donc perdue par engorgement.

Cette technique permet donc

  • d'optimiser les transferts selon le débit qui convient le mieux aux machines mises en jeu,
  • assure un transport fiabilisé puisque TCP vérifie par un mécanisme d'aquittement précis si les données sont correctement véhiculées.

Un problème de contrôle de flux n'est toutefois pas résolu par cette solution. En effet, les paquets TCP peuvent être amenés à passer par des gateways. Ces dernières ont un débit qui peut être différent de celui de la machine destinatrice : le contrôle de flux ne concerne pas uniquement les machines émettrice et réceptrice). Pour palier ce problème, TCP s'interface avec le protocole ICMP et gère les paquets de type "source quench" définis par ce protocole.

4.4.2. Structure des paquets TCP

Dans le langage UNIX, les paquets TCP sont appelés des segments. Il existe plusieurs types de segments :

  • des segments de données (les données applicatives y sont encapsulées de manière transparente),
  • des segments d'aquittement (i.e. des ACK),
  • des segments d'établissement de connexion (lors de l'initialisation du dialogue entre émetteur et récepteur),
  • des segments de changement de taille de fenêtre ("Window advertising segment"),
  • enfin des segments de fermeture de connexion.

Remarque : il est important de noter qu'un aquittement peut être transporté dans un segment de données (ce qui réduit le nombre de segments transmis).

La structure d'une trame TCP est la suivante :

Tout comme le protocole UDP, TCP utilise des numéros de ports pour différencier les connexions dont il a la charge. Les champs "Port Origine" et "Port Destination" désignent donc deux entiers correspondant aux ports sur lesquels les applications émettrice et réceptrice tournent.

Le numéro de séquence désigne le numéro de segments de données de l'émetteur. Le numéro d'aquittement représente le dernier segment reçu par le récepteur (nous verrons plus loin qu'il s'agit en fait d'un offset).

Le champ "offset" représente l'offset des données dans le segment. Ce champ est obligatoire car le champ options est de taille variable.

Le champ "res" est réservé par le protocole mais non utilisé de nos jours.

Le champ "code" permet de différencier les types de segments TCP. Il se découpe en bits. Chaque bit prend la valeur 0 ou 1 pour invalider/confirmer l'utilisation des autres champs du segment. Le champ "code" se lit donc de la manière suivante :

Désignation du bit Signification
URG Valeur = 0 le champ "niveau d'urgence" ne doit pas être pris en considération
Valeur = 1 le champ "niveau d'urgence" doit être pris en considération
ACK Valeur = 0 le champ "numéro d'aquittement" ne doit pas être pris en considération
Valeur = 1 le champ "numéro d'aquittement" doit être pris en considération
PSH Valeur = 0 ce segment ne fonctionne pas suivant la méthode "PUSH"
Valeur = 1 ce segment fonctionne suivant la méthode "PUSH"
RST
Valeur = 0 pas de demande de reset de la connexion
Valeur = 1 demande de reset de la connexion
SYN
Valeur = 0 n'annonce pas un numéro de séquence de synchronisation.
Valeur = 1 annonce un numéro de séquence de synchronisation.
FIN
Valeur = 0 pas d'annonce de fin de transmission
Valeur = 1 annonce de fin de transmission

Lorsque le bit URG est positionné à la valeur 1, le segment TCP contient des valeurs urgentes. Il est possible que celles-ci soient véhiculées avec d'autres données qui ne le sont pas. Dans ce cas, les données urgentes sont toujours placées au début de la zone de données dans le segment TCP. Le champ "Pointeur d'urgence" représente la position - dans la zone de données - à laquelle les données urgentes se terminent. A partir de cette position et ce jusqu'à la fin du segment, les données sont standard.

Le champ "Fenêtre" spécifie le nombre d'octets que le récepteur souhaite recevoir (cf §4.4.1).

Le champ "Option" peut par exemple désigner une taille maximale de segment TCP. Cela peut être utile pour des machines qui ont de petits buffers.

4.4.3. Calcul du Checksum

Le champ CRC contient sur 16 bits le résultat du calcul de checksum des paquets TCP. TCP se base sur le même calcul que le protocole UDP : UDP utilise le même algorithme qu'IP pour calculer ce checksum. Le calcul du CRC utilise un pseudo-header c'est-à-dire un deuxième ensemble de champs. Le pseudo-header et l'ensemble (entête TCP - Zone de données TCP) interviennent donc dans le calcul du CRC.

La structure du pseudo-header est la suivante :

4.4.4. Aquittements et retransmission

Puisque TCP émet des segments de données de longueur variable, les aquittements sont des offsets et non pas des numéros de segments. Chaque aquittement représente le numéro du dernier octet reçu depuis le début du transfert auquel on ajoute 1. Par exemple, si le récepteur a reçu 34568 octets depuis le début des échanges, l'aquittement prendra alors la valeur 34569.

Ainsi, on pourra retenir la règle suivante : "les aquittements désignent le numéro du prochain octet que la machine destination souhaite recevoir". On parle dans ce cas d'aquittements cumulatifs : chaque aquittement dépend de l'historique du transfert.

Avantages :

  • Les aquittements sont uniques et faciles à générer,
  • Si un paquet d'aquittement est perdu, cela n'implique pas une retransmission complète : on se base sur le dernier aquittement pour poursuivre.

Inconvénient :

  • L'émetteur ne reçoit pas un aquittement complet : l'aquittement est relatif par rapport au dernier octet reçu sans déterioration.

4.4.5. Timeout et retransmission

Chaque fois qu'un segment TCP est envoyé, un timer est armé par l'émetteur et TCP attend un aquittement. Si le timer passe à zéro alors que cet aquittement n'est pas reçu, TCP considère AUTOMATIQUEMENT que le segment a été perdu ; il le retransmet donc.

Comme les segments TCP passent par des gateways et des machines dont les performances sont variées, TCP doit adapter les timers suivant la topologie du réseau physique par lequel les données circulent. Pour ce faire, il utilise un algorithme adaptatif. Il enregistre les temps auxquels les paquets sont émis et les temps auxquels il a reçu les aquittements leur correspondant. TCP en déduit alors un temps moyen d'émission. Ce temps est perpétuellement réajusté en fonction du trafic.

4.4.6. Gestion de l'engorgement

Si un engorgement se produit sur un point du réseau, les délais de transmission augmentent. Les gateways ou les machines hôtes qui sont engorgées émettent des messages ICMP pour avertir les machines émettrices que des segments vont être perdus. Ces messages sont remontés par la couche IP jusqu'au protocole TCP qui automatiquement identifie les données perdues.

Si toutefois ICMP n'émettait pas ces messages d'avertissement, TCP constaterait un problème de transmission à l'aide du temps moyen d'émission : celui-ci augmenterait sans cesse. Toutefois, cette solution ne permet pas de diagnostiquer la raison de cet accroissement. L'interfaçage avec le protocole ICMP est donc préférable.

4.4.7. Etablissement d'une connexion par TCP

Trois segments TCP suffisent à établir une connexion comme le montre le synoptique suivant :

4.4.8. Arrêt d'une connexion

TCP place le bit FIN à 1 pour signaler la fin d'un transfert. Attention toutefois : cette fin de transfert peut n'être valable que pour une direction donnée. En effet, puisque TCP fonctionne en full-duplex, il est possible qu'un transfert se poursuive dans un sens alors que dans l'autre sens la connexion est close.

4.4.9. Reset d'une connexion

Si un problème réseau survient, TCP est capable de lancer le reset d'une connexion. Les machines émettrice et réceptrice émettent alors un segment de RESET en plaçant le bit RST du champ CODE à 1.

4.4.10. La méthode PUSH

Le découpage des données par TCP peut être génant pour certaines applications. Aussi, il est possible de forcer l'émission des données en positionnant le bit PSH du champ CODE à 1. Il est de plus possible de demander un envoi urgent de ces données en plaçant à 1 le bit URG du champ CODE : non seulement les données sont émises dès qu'elles sont transmises à la couche TCP mais elles sont envoyées en priorité.

4.4.11. Numéros de ports réservés par des applications standard

Comme UDP, TCP utilise des ports pour les principaux services qu'il gère. Ainsi, on retrouvera dans le fichier /etc/services les applications suivantes :

rje		7/tcp
ftp-data	20/tcp
ftp		21/tcp
telnet		23/tcp

4.5. Conclusion

TCP est donc un protocole de la couche 4 du modèle OSI. Ses segments ont une entête de 40 octets lui permettant d'assurer différents contrôle de trafic. TCP est donc un protocole sécurisé contrairement au protocole UDP.

TCP est utilisé par 90% des applications réseau sous UNIX car il offre une certaine souplesse d'utilisation mais surtout parce qu'il garantie l'émission des données.


5. Protocoles et applications s'appuyant sur TCP et UDP

5.1. Introduction

Nous avons, dans les chapitres précédents, constaté que le monde UNIX basait ses applications réseau sur la famille des protocoles IP. Sur un réseau local, les couches 1 et 2 du modèle OSI sont occupées par le protocole Ethernet. Sur celui-ci on retrouve plusieurs protocoles :

  • le protocole IP (Internet Protocol), qui véhicule des datagrammes en mode non sécurisé,
  • les protocoles ARP et RARP qui permettent d'établir une relation bi-univoque entre les adresses Internet et les adresses Ethernet des machines,
  • les protocoles de routage GGP, EGP, RIP et HELLO qui permettent de router des datagrammes IP sur le réseau mondial Internet,
  • enfin deux protocoles de transport : UDP - protocole non sécurisé - et TCP - protocole sécurisé.

Sur ces deux derniers protocoles reposent d'autres protocoles et applications permettant d'accéder au mieux aux ressources du monde UNIX. Les principaux concernés sont représentés sur le modèle suivant :

Nous allons dans ce chapitre présenter ces principaux modules ainsi que les commandes UNIX et les fichiers de configuration les concernant. Nous ne parlerons toutefois que brièvement des modules SNMP, DNS et SMTP dont le fonctionnement et la configuration sont très complexes.

5.2. Connexion à une machine distante

Il existe deux commandes de connexion à une machine distante : telnet et rlogin.

5.2.1. TELNET

Telnet est une application permettant d'établir une connexion sur un terminal distant. Lancer telnet revient à visualiser en local un environnement UNIX que l'on a lancé à distance. Telnet s'appuie sur le protocole TCP pour établir cette connexion entre deux machines. Il peut être utilisé pour se connecter sur une machine du même réseau local ou sur une machine d'un réseau distant. Telnet met donc en jeu deux processus :

  • un processus local qui gère la connexion Telnet,
  • un processus distant équivalent.

Ces processus sont des démons. Ils peuvent être dupliqués n fois grâce au super-démon inetd. Le démon correspondant à telnet est telnetd. Le service telnet est défini sur le port 23.

Un contrôle d'accès est nécessaire pour vérifier qu'un système UNIX n'est pas piraté par une connexion telnet non souhaitée. Pour cela, telnet utilise la procédure standard de login. Quand le démon telnetd est activé, l'utilisateur doit entrer son nom et son mot de passe. Une vérification à partir du fichier "/etc/passwd" provoque l'arrêt de la connexion si l'utilisateur ne possède pas de droits d'accès sur cette machine.

Il existe deux syntaxes pour lancer la commande telnet :

  • $telnet zebulon
  • $telnet 192.1.1.64

Dans la première syntaxe, telnet reçoit comme argument un nom symbolique de machine. Le fichier "/etc/hosts" est consulté pour déterminer l'équivalence entre le nom symbolique et l'adresse Internet de la machine. Dans la deuxième syntaxe, on entre directement l'adresse de la machine.

Telnet permet de travailler en mode local tout en conservant la connexion distante. Les commandes en mode local doivent être précédées d'un point d'exclamation. Pour passer dans l'application telnet, on utilise le caractère "Escape ]". Une fois ce caractère tapé, l'utilisateur peut solliciter l'aide de telnet en tapant "?" ou lancer d'autres commandes de telnet.

Remarque : telnet n'est pas une application spécifique à UNIX (elle existe par exemple dans les environnements DEC).

Objets impactés par telnet :

  • démons : inetd et telnetd,
  • fichiers système : /etc/passwd, /etc/services, /etc/inetd.conf et /etc/hosts.

5.2.2. RLOGIN

rlogin est un autre outil de connexion à distance. Son principe est similaire à telnet. rlogin fait partie d'une famille de commandes que l'on appelle les "r-commandes", r désignant le terme remote. Toutes les commandes appartenant à cette famille sont lancées à partir d'un poste pour agir sur un autre poste. La commande rlogin n'échappe pas à cette règle : rlogin permet de lancer un login sur une machine distante. rlogin utilise le démon rlogind. Celui-ci est dupliqué par le super-démon inetd.

La syntaxe d'appel de rlogin est unique :

$rlogin nenuphar [-ec] [-8] [-l nom_utilisateur]

où nénuphar est un nom symbolique de machine. Le fichier /etc/hosts est donc consulté pour établir l'adresse Internet de la machine.

L'option -l permet de se connecter sous un autre nom que le nom de l'utilisateur courant. Si par exemple vous êtes connecté sous le nom "colas", il est possible de vous connecter à distance sous le nom "lafuma". Dans ce cas, la syntaxe d'appel est :

$rlogin nenuphar -llafuma

L'option -e permet de spécifier un caractère d'échappement Il doit alors directement suivre ce caractère e. Enfin l'option -8 permet de demander une communication en 8 bits (au lieu de 7 bits par défaut).

Tout comme telnet, rlogin impose un certain niveau de sécurité. Deux fichiers systèmes sont employés : ".rhosts" et "/etc/hosts.equiv". Le fichier ".rhosts" est propre à chaque utilisateur. Il est donc placé dans le répertoire de travail de chacun. Ce fichier contient la liste des utilisateurs pouvant se connecter sous le nom de l'utilisateur courant à partir d'une rcommande.

Exemple :
Soit l'utilisateur Dupont. La machine sur laquelle il travaille porte le nom joconde. Son répertoire de travail est /home/users1/dupont. Ce répertoire contient le fichier /home/users1/dupont/.rhosts suivant :

machine1 durand
machine2 léopold

Chaque ligne de ce fichier contient un couple (machine, utilisateur). Dans notre exemple, l'utilisateur durand peut se connecter à partir de machine1 sur la machine nommée joconde et ce sous le nom d'utilisateur dupont. Dans ce cas, l'utilisateur durand possède les droits d'accès de l'utilisateur dupont.

Le fichier "/etc/hosts.equiv" contient la liste des machines qui sont considérées - du point de vue protection - comme équivalente à la machine locale.

Exemple :

Sur la machine joconde, on trouve le fichier /etc/hosts.equiv suivant :

machine1
machine2

La commande rlogin se base donc sur ces fichiers pour vérifier la demande de connexion. Si les définitions ne sont pas faites sur la machine sur laquelle on se connecte, la session n'est pas établie.

Remarque : les "r-commandes" ont été développées par BSD.

Objets impactés par rlogin :

  • démons : inetd et logind,
  • fichiers système : /etc/passwd, /etc/services, /etc/inetd.conf, /etc/hosts, /etc/hosts.equiv et .rhosts.

5.3. Transfert de fichiers

Il existe quatre applications permettant de lancer un transfert de fichiers entre deux machines : FTP, TFTP, UUCP et rcp.

5.3.1. FTP

FTP (File Transfert Protocol) est une application de transfert de fichiers sécurisé. Par conséquent, il s'appuie sur le protocole TCP. FTP se lance en spécifiant comme paramètre le nom de la machine distante :

ftp nom_machine

Exemple : $ftp nenuphar

FTP demande ensuite un nom de login ainsi qu'un mot de passe. Le fichier /etc/passwd est donc consulté pour vérifier les droits de connexion. FTP autorise l'automatisation de la séquence de connexion si le fichier .netrc est constitué. Ce fichier est présent dans les répertoires de travail des utilisateurs (son principe est similaire à celui du fichier .rhosts).

Le fichier .netrc possède une syntaxe propre. Il contient trois mots clefs : machine, login et passwd.

Exemple de fichier .netrc :

machine zebulon login durand passwd fjdls
machine nenuphar login dupont passwd gjdf

FTP fonctionne en mode full-duplex : il permet le transfert de fichiers dans les deux sens. FTP intègre des commandes permettant par exemple de se déplacer dans les répertoires pour chercher les fichiers voulus. La liste ci-dessous reprend les principales commandes de FTP :

  • dir affiche le contenu du répertoire (dir est équivalent à la commande ls),
  • cwd change de répertoire de travail (Change Working Directory),
  • put envoie un fichier,
  • get récupère un fichier,
  • bye termine la connexion FTP,
  • ~! lance une commande en local (le nom de la commande suit le caractère !),
  • ~. termine la connexion.

FTP utilise deux ports pour fonctionner. Ces ports sont définis dans le fichier /etc/services. Le port numéro 20 est utilisé par FTP pour effectuer du contrôle de flux et transmettre des messages entre les deux services FTP des machines mises en jeux. Le port numéro 21 est réservé par ftp-data. Ce port est donc dédié aux transferts (bi-directionnels) de données.

Le démon ftp est défini dans le fichier /etc/inetd.conf. Ce démon est activé par inetd.

Objets impactés par FTP :

  • démons : inetd et ftpd,
  • fichiers système : /etc/passwd, /etc/services, /etc/inetd.conf, /etc/hosts et .netrc.

5.3.2. TFTP

TTFP (Trivial FTP) est une version simplifiée (et peu sécurisée) de FTP. Les différences entre FTP et TFTP sont les suivantes :

  • TFTP est basé sur le protocole UDP alors que FTP s'appuie sur le protocole TCP. Ceci implique que le transfert de fichiers par TFTP est effectué en mode datagramme sans vérification de bonne transmission.
  • les noms de fichiers que l'on souhaite copier doivent être donnés suivant le chemin absolu dans l'arborescence disque (il n'y a pas de notion de répertoire de travail).
  • TFTP n'effectue pas de contrôle d'accès. Pour qu'un fichier puisse être transféré par TFTP, il faut que le fichier soit en lecture pour tous les utilisateurs (on dit que les fichiers que l'on souhaite copier doivent être publics).
  • TFTP peut être utilisé par des machines diskless lors de leur boot : puisqu'elles reçoivent rapidement des fichiers de configuration à partir d'un serveur proche, les données ont peu de chance d'être erronées.

Une session TFTP est semblable à une session FTP. Elle est lancée par l'activation d'un démon tftpd défini dans les fichiers /etc/services et /etc/inetd.conf.

Objets impactés par TFTP :

  • démons : inetd et tftpd,
  • fichiers système : /etc/services et /etc/inetd.conf.

5.3.3. UUCP

UUCP (Unix to Unix CoPy) est un logiciel standard permettant à deux sites de communiquer. Il est notamment utilisé par les réseaux de messagerie (Fnet par exemple). UUCP intègre des fonctions de transfert de fichiers, de messagerie et de lancement de commandes à distance.

Il est important de noter que UUCP ne fonctionne pas en mode interactif. Ses fichiers de configuration permettent d'automatiser entièrement le fonctionnement de ce logiciel. Enfin, une caractéristique essentielle de UUCP est qu'il fonctionne en mode Client/Serveur.

5.3.3.1. Fonctionnement de UUCP

Le déroulement d'opérations par UUCP est comme nous l'avons dit automatique :

  • Les utilisateurs lancent des requêtes vers le serveur UUCP.
  • UUCP stocke ses requêtes dans la file d'attente /usr/spool/uucp.
  • Le démon uucico exécute en mode différé ces requêtes.
  • uucico prévient les utilisateurs par messagerie (mail) du résultat de son travail.

Un module UUCP commence toujours par "uu" :

  • uusched est le scheduler de UUCP,
  • uutry est une commande de tentative de connexion...
5.3.3.2. Fonctionnement de UUCICO

Déroulons le fonctionnement de ce programme :

  • Recherche des requêtes à lancer (dans la file d'attente /usr/spool/uucp).
  • Vérification des heures autorisées d'appel (plages horaires pendant lesquelles il est possible de se connecter sur la machine distante).
  • Vérification du site distant : est-il libre et existe-t-il une voie d'accès libre ?
  • Établissement d'une connexion en fonction de la configuration fournie dans le fichier "Systems".
  • Lancement sur le site distant d'un processus uucico qui sera esclave du processus uucico à l'initiative de l'appel.
  • uucico esclave et maître s'accorde sur le choix d'un protocole de communication (car UUCP possède ses propres protocoles de dialogue : g, e, f et t).
  • Le processus uucico maître envoie les requêtes à exécuter à l'esclave (avec possibilité de reprise sur erreur). Une fois toutes les requêtes envoyées, les rôles sont inversés entre les deux processus.
  • Rupture de la connexion et mise à jour des fichiers d'activité en créant des processus uuxqt pour exécuter les requêtes demandées par le site distant.
5.3.3.3. Définitions nécessaires à UUCP

Définitions :

  • Une machine configurée par UUCP est appelée un site.
  • Un site est actif s'il est capable d'établir une connexion. A l'inverse, on dit qu'il est passif s'il doit être scruté par un site actif pour fonctionner.

Un ensemble de fichiers de configuration sont placés dans le répertoire /etc/uucp et sont utilisés pour automatiser les tâches du logiciel. Tous appartiennent au groupe d'utilisateurs uucp. Ils ne sont accessibles qu'en lecture pour le groupe uucp (aucun droit pour les autres utilisateurs). Il s'agit des fichiers :

  • Devices :
    Ce fichier contient la liste des voies d'accès utilisables par un site distant. Chaque ligne de ce fichier respecte la syntaxe suivante :
    type voie voie2 classe DTP
    Chaque champ doit être séparé des autres par des espaces.
    • Le champ type spécifie s'il s'agit d'un accès direct (mot clé "direct") ou d'un accès modem (mot clé "acu") ou encore d'un accès local par TCP/IP (mot clé "tcp"). Dans ce cas, il est nécessaire d'ajouter un démon uucp (in.uucpd) dans le fichier /etc/inetd.conf.
    • Le champ voie donne le nom du périphérique (i.e. le nom du device dans le jargon Unix). Le champ voie2 n'est utilisé que pour les modems d'un type particulier. Dans tous les autres cas, ce paramètre est remplacé par un tiret. Le champ classe indique la vitesse de transmission. Enfin le champ DTP (Dialer Token Pairs) représente la chaîne de commandes à lancer pour un modem.

  • Systems :
    Il donne toutes les informations nécessaires à l'établissement d'une connexion sur un site distant. Chaque ligne définit une possibilité de connexion à un site.
    Pour joindre un site distant, il faut que celui-ci possède également une définition du site courant (uucp oblige à une réciprocité de déclaration entre deux sites s'interconnectant).
    Une ligne du fichier Systems est déclarée ainsi :
    nom_du_site_site horaire type classe téléphone connexion
    • Le champ horaire indique les heures et jours d'appel sachant que le mot clé Never indique qu'un site est passif. Un mécanisme de ré-émission à intervalles de temps incrémentales est intégré au logiciel et tient compte de ces plages horaires.
    • Le champ type reprend le premier champ du fichier Devices.
    • De même le champ classe reprend la classe de débit de la liaison.
    • Le champ téléphone ne contient pas un numéro à appeler mais une mnémonique que l'on définira ensuite dans le fichier Dialcodes. Le mnémonique est suivi de la fin du numéro de téléphone.
    • Le champ connexion contient une liste des messages attendus par le site lors de la connexion. Si ces messages n'arrivent pas, on considère que la connexion ne s'établit pas correctement.

  • Dialers :
    Il contient la séquence de déroulement lors d'une connexion entre deux sites. La syntaxe de ce fichier est limitée à trois champs :
    dialer substitutions attendu-émis
    • Le champ substitutions établit des équivalences de caractères (et sert rarement).
    • Le champ attendu-émis indique la séquence de données attendues et celles que l'on émet alors.

  • Dialcodes :
    Il contient les numéros de téléphone. Sa syntaxe est simple :
    mnémonique téléphone
    Le champ téléphone ne contient que le début du numéro de téléphone. La fin de ce numéro est contenue dans le fichier Systems.

  • Permissions :
    Il donne la liste des droits d'accès aux fichiers et d'exécution des commandes pour les sites se connectant par UUCP. Ce fichier est composée des options que l'on souhaite positionner. Les plus importantes sont READ et WRITE. READ permet de préciser l'arborescence disque que UUCP peut lire (idem pour WRITE !). Il existe de plus les options NOREAD et NOWRITE.
    Il est important de connaître également l'option "COMMANDS" qui liste l'ensemble des commandes pouvant être exécutées. Chaque commande est séparée des autres par le symbole ':'.

  • Poll :
    Il contient la liste des sites passifs à scruter ainsi que les heures de scrutation. Périodiquement, la cron de la machine lance le shell uudemon.poll afin de scruter ces sites. La syntaxe du fichier poll est simple :
    nom_site liste des heures de scrutation
    Les caractères de séparation doivent impérativement être des tabulations.

  • Sysfiles :
    Ce fichier permet de définir une liste d'autres fichiers utilisés par uucp. Nous n'en dirons pas plus à son sujet.

Hormis ces fichiers de configurations, on trouve trois fichiers essentiels qui sont :

  • le fichier Maxuuxqts : contient le nombre maximal de processus uuxqt pouvant être exécutés en même temps.
  • le fichier Maxuuscheds : contient le nombre maximal de processus uusched pouvant être exécutés en même temps.
  • le programme remote.unknown qui est exécuté lorsqu'un site non déclaré se connecte.
5.3.3.4. Répertoires réservés par UUCP

/etc/uucp contient tous les fichiers de définition que nous venons de citer. Il comprend également les 4 shells d'administration de UUCP :

  • uudemon.poll (déjà présenté),
  • uudemon.hour : appelle le programme uusched (scheduler de uucp) pour traiter les requêtes en cours et le programme uuxqt pour exécuter les commandes demandées par un site distant. Par défaut, uudemon.hour est activé toutes les heures.
  • uudemon.admin : Il appelle le programme uustat pour connaître l'activité de uucp. Le résultat de cette analyse est envoyé par mail à l'utilisateur uucp.
  • uudemon.cleanup : il archive le travaille de uucp dans un fichier de log (répertoire /etc/uucp/.Log). Il supprime les fichiers temporaires de plus de x jours et retourne ensuite un message à l'utilisateur uucp pour l'informer de l'état des répertoires uucp.

/usr/lib/uucp contient tous les programmes de uucp :

  • uuclean purge les zones de spool. Il est déclenché par la cron régulièrement.
  • uucleanup purge les zones de spool de UUCP en avertissant par mail les utilisateurs.
  • uucheck vérifie la cohérence du système UUCP (présence des répertoires et des fichiers de configuration).
  • uucico qui est le logiciel de communication. Il est activé par les commandes uucp, uux, uuto, uusched et Uutry.
  • uuxqt : il est activé par le démon uudemon.hour.
  • uusched : ce scheduler est activé lors du démarrage de la machine (cf /etc/rc ou /etc/rc.tcpip) puis est relancé régulièrement par uudemon.hour.
  • Uutry : c'est un shell de test permettant de tester une connexion UUCP.
  • remote.unknown,
  • uudemon.crontab : il contient la définition de la cron de uucp.

/usr/spool/locks contient les fichiers de verrouillage pour éviter des accès simultanés sur les voies de UUCP. Chaque fichier de verrouillage a pour nom LCK..xxx où xxx désigne le nom de la voie. Ces fichiers sont utilisés par uucico :

  • Si le fichier de verrouillage LCK..xxx existe, uucico termine immédiatement la connexion et tentera de nouveau la connexion ultérieurement.
  • Sinon, il crée ce fichier en mode lecture, exécute ses traitements puis détruit le fichier.

/usr/spool/uucppublic est le répertoire par défaut des utilisateurs se connectant par UUCP.

/usr/spool/uucp contient tous les fichiers temporaires de travail de UUCP. Il contient notamment les files d'attente des travaux pour chaque site.

5.3.3.5. Commandes mises à disposition des utilisateurs

uux demande l'exécution à distance d'une commande. La syntaxe de uux est la suivante : uux [-options] commande
Exemple : uux nenuphar!qprt /home/siep/colas/.profile demande l'impression sur la machine merlin du fichier home/siep/colas/.profile.

uuto permet de copier des fichiers dans un répertoire spécifique. Les fichiers sont copiés dans une sous-arborescence du répertoire /usr/spool/uucppublic.

uupick permet de récupérer des fichiers émis par uuto. uupick intègre donc une procédure de recherche des fichiers reçus.

uuname affiche tous les sites accessibles par uucp.

uulog affiche l'activité du service uucp du site.

uustat affiche l'état de UUCP : requêtes en instance, accessibilités des sites, travaux en exécution pour un site...

5.3.4. RCP

rcp (remote copy) est une rcommande. Elle permet de copier un ensemble de fichiers d'une machine à une autre. La syntaxe de cette commande est très simple : $rcp [-p] [-r] source cible
où les champs source et cible se découpent suivant la même syntaxe : nom_machine[.nom_utilisateur]:fichier.

Exemple : $rcp zebulon.colas:/home/siep/users1/.rhosts nenuphar:/home/siep/.rhosts

L'option -r permet de copier récursivement les sous-répertoires. L'option -p demande la modification des dates des fichiers copiés sur la machine cible.

La commande rcp utilise les fichiers .rhosts et /etc/hosts.equiv pour vérifier les droits de copie.

Objets impactés par rcp :

  • démons : inetd et rshd,
  • fichiers système : /etc/hosts.equiv et .rhosts.

5.4. Commandes à distance : RSH

rsh (remote shell) permet de demander l'exécution d'une commande shell sur une machine distante sans avoir besoin de s'y connecter (par un rlogin). rsh se comporte comme un rlogin.

La syntaxe de rsh est la suivante : rsh machine [-l utilisateur] [-n] commande
L'option -n permet de dire au shell distant d'utiliser /dev/null comme fichier standard d'entrée.

Exemple : $rsh zebulon -lcolas -n ls -ail;

rsh est lancé par le démond rshd définit dans le fichier /etc/services.

5.5. Le système de messagerie

Dans le monde Internet, il est nécessaire de pouvoir véhiculer des messages à travers le monde entier. L'utilitaire permettant ce routage est appelé sendmail. Sendmail récupère des messages déjà constitués pour les transmettre (il n'est donc jamais directement en contact avec les utilisateurs). A partir des adresses qui sont fournis dans les entêtes des messages, sendmail est capable d'assurer la livraison des ces données.

Sendmail est en contact avec deux interfaces :

  • les programmes de construction et de lecture des messages (mail en est l'exemple le plus courant),
  • les agents de transport du courrier :
    • /usr/mail qui poste le courrier localement,
    • /usr/bin/uux qui communique avec les machines distantes,
    • et SMTP (Simple Mail Transfert Protocol) le protocole ouvert de messagerie s'appuyant sur TCP.

Sendmail prend en compte :

  • les alias et listes de diffusion (pour diffusion générale de messages par exemple),
  • la gestion des files d'attente des messages,
  • le renvoi automatique de messages,
  • le routage vers les passerelles.

La configuration et le fonctionnement de sendmail est délicate et impose beaucoup de rigueur car il doit permettre d'envoyer et de recevoir des messages du monde entier.

5.6. NFS et RFS

5.6.1. Introduction

NFS (Network File System) et RFS (Remote File Sharing) permettent le partage des fichiers suivant un mécanisme de fichiers répartis. NFS a été conçu par SUN mais est désormais très largement utilisé (il est même devenu le plus utilisé !). RFS par contre a été écrit par AT&T pour Unix System V. Nous ne présenterons pas dans ce document RFS car il est de nos jours rarement utilisé.

5.6.2. Caractéristiques de NFS

NFS est réalisé au-dessus de deux couches logicielles : les RPC (Remote Procedure Call) et XDR (eXternal Data Representation). La première couche permet de réaliser des appels de procédures à distance et la couche XDR permet à la couche RPC un échange de données entre deux machines hétérogènes (la représentation des caractères pouvant différer d'une technologie hardware à une autre).

Ces services sont basés sur des démons que l'on active à distance pour exécuter les requêtes NFS. NFS s'appuie sur UDP et offre les fonctionnalités suivantes :

  • partage de fichiers entre machines hétérogènes,
  • accès aux ressources Unix à partir de PC clients,

NFS est structuré de la manière suivante :

Remarque : toute machine possédant un disque peut être serveur NFS.

NFS utilise une méthode simple pour accéder aux fichiers distants : par la commande mount, on déclare un file system de type NFS. On lie par mount les arborescences des machines rendant transparent l'emplacement réel des fichiers. Voici un exemple de partage des fichiers par NFS :

Remarques :

  • Si une partie de l'arborescence d'une machine est accessible par montage, on dit qu'elle est exportée.
  • La vérification des autorisations d'accès se fait par identifications locales de la machine.
  • Il n'y a pas de transformation de numéro d'utilisateur ou de numéro de groupe lors des accès distants.

5.6.3. Configuration du serveur de fichiers

Les parties exportables des machines sont définies dans le fichier /etc/exports. Ce fichier est utilisé par le démon mountd (démon de montage des ressources fichiers). Ce démon est activé par inetd).

Remarque : sur les stations SUN, il existe un fichier intermédiaire /etc/xtab qui contient la liste des parties exportables définies par la commande exportfs. Il ajoute le contenu de ce fichier au fichier /etc/exports qui ne contient donc que les ressources à monter localement.

Le fichier /etc/exports contient des lignes ayant la structure

chemin local -options

le champ options permettant de paramétrer l'accès aux ressources (ex : -ro signifie accès en lecture seulement).

La commande showmount permet de consulter le fichier /etc/rmtab dans lequel NFS inscrit toutes les opérations de montage ayant correctement abouti. La syntaxe de cette commande est la suivante :

/usr/etc/showmount [-ade] [hostname]

Les démons nécessaires aux serveurs NFS sont

  • portmap ( /usr/etc/portmap). Ce démon est nécessaire aux RPC et doit être lancé en premier.
  • nfsd : il s'agit des démons répondant aux requêtes NFS. Au lancement de ce démon, on spécifie en paramètre le nombre maximum de requêtes pouvant être prises en parallèle.
  • rpc.mountd pour monter l'arborescence.

Ils sont lancés à partir du shell de lancement rc.local.

5.6.4. Configuration du client NFS

Le but d'un client est de déclarer un point de montage distant. Pour ce faire, le client doit également utilisé la commande mount en spécifiant en arguments que le point de montage est sur une machine distante. La syntaxe de la commande mount est

mount [-r] [-ttype] [-ooptions] filesystem directory

Dans le cas d'un montage par NFS, le champ type vaut "NFS". Il existe des options de la commande spécifiques à NFS dont nous citons les principales :

  • bg|fg (concerne la partie cliente) : précise si les tentatives de montage doivent être lancées en arrière-plan (bg = BackGround) ou en premier-plan (fg = ForeGround) si un échec se produit.
  • noquota : demande une non-vérification des quotas disque (les quotas seront uniquement vérifiés par le serveur NFS).
  • soft|hard : en cas de panne du serveur NFS, l'option hard demande l'émission des demandes du client NFS jusqu'à ce que le serveur réponde. Par contre, l'option soft permet de retourner une erreur au client.
  • intr : permet d'interrompre un processus client sollicitant un serveur en panne (si l'option hard du client était positionnée).
  • rsize=... ou wsize=.... spécifient des tailles de tampons en lecture ou en écriture.

La commande mount consulte le fichier /etc/fstab pour connaître la liste des systèmes de fichiers à monter. Les systèmes de fichiers NFS distants sont donc définis dans ce fichier.

NFS utilise un mécanisme de cache fichiers local pour l'accès aux fichiers du serveur. Ce cache est géré par les démons biod (qui sont en quelque sorte les correspondants des démons nfsd). Les démons biod doivent également être lancés au démarrage de la machine après avoir activé le démon portmap.

5.7. DNS

Le DNS (Domain Name Server) permet de définir une hiérarchie de machines. Il permet à une machine ayant une adresse officielle sur Internet de trouver le numéro Internet d'une autre machine ayant une adresse officielle.

DNS pour cela utilise une base de données répartie dans le monde entier. La consultation est libre. Chaque partie de la base de données est laissée à la charge de l'administration (la responsabilité est donc importante).

Le DNS utilise un mécanisme similaire au service offert par /etc/hosts. Il offre la possibilité de mise à disposition des informations Internet d'un site pour des sites distants. Il permet aussi de puiser des informations à partir d'autres sites de manière à pouvoir accéder à des machines sans avoir à tenir à jour leur numéro Internet. Un cache est employé par le DNS pour sauvegarder les données reçues des autres DNS (et par conséquent minimiser les échanges d'informations sur le réseau).

Le DNS est constitué de deux entités : les serveurs de noms et les méthodes de résolution des noms appelées resolver. Ces méthodes sont implémentées dans la librairie libresolv.a. Il existe plusieurs types de serveurs de noms suivant la responsabilité qui leur est confiée. On parle donc de serveurs primaire, secondaire, cache et forwarder. Les serveurs primaires ont l'autorité d'administration sur une zone et définissent les numéros Internet des machines appartenant à cette zone. Les serveurs secondaires récupèrent les informations des serveurs primaires (ils servent de backup). Les serveurs cache contiennent les données du cache. Enfin, un serveur forwarder permet d'appeler un serveur de niveau supérieur pour connaître les données d'une autre zone. Un forwarder connaît donc plusieurs DNS.

DNS est pris en charge par le processus named ou bind (Berkeley Internet Name Domain server). La commande nslookup permet de connaître la configuration d'un serveur de noms.

5.8. SNMP

SNMP (Simple Network Management Protocol) est un protocole d'administration de réseaux basé sur l'interrogation d'agents. Un agent agit sur une entité administrée du réseau. Chaque agent est associé à une MIB (Management Information Base) qui décrit les objets administrés par l'agent ainsi que les variables associées à ces objets. Une norme (SMI : Structure and identification of Management Information for TCP/IP based Internets) a permis la mise en place et le déploiement des MIB.

Une station du réseau peut être chargée de récupérer les éléments retournés dans les MIB par les agents SNMP. La commande snmpget permet d'obtenir une information à partir d'une MIB d'un agent. La commande snmpnext permet d'obtenir des informations de la sous-arborescence d'une MIB (car les structures des MIB sont arborescentes).

Sur les machines administrables SNMP, il est nécessaire d'avoir un démon snmpd lancé par inetd pour que la collecte des informations soit possible.

5.9. Conclusion

Les outils réseaux occupent une place d'autant plus importante dans le monde UNIX qu'Internet nécessite des mécanismes d'interconnexion de réseaux puissants. Nous avons examiné les principales couches de produits et protocoles venant se poser sur les protocoles TCP et UDP mais il est possible de concevoir ces applications en mode réseau à l'aide des bibliothèques C fournies en standard avec le système d'exploitation UNIX.


ANNEXE A : Liste des fichiers de configuration du réseau

ANNEXE A.1. : Fichiers de configuration de chaque utilisateur

Nom du fichier
Rôle de ce fichier
~/.rhosts Définition des utilisateurs équivalents par compte
~/.netrc Descriptions permettant d'automatiser les connexions par FTP

ANNEXE A.2. : Fichiers de configuration générale

Nom du fichier
Rôle de ce fichier
/etc/ethers Contient les informations nécessaires au protocole RARP
/etc/gateways Décrit les réseaux distants et les passerelles à utiliser
/etc/hosts Contient les numéros Internet des machines, leur nom officiel et leurs alias
/etc/ftpusers Liste les utilisateurs non autorisés à se connecter par FTP
/etc/hosts.equiv Décrit les machines équivalentes à la machine locale pour rlogin, rcp et rsh
/etc/inetd.conf Permet au super-serveur de l'Internet (inetd) de savoir quel démon lancer pour une requête reçue
/etc/netgroup Permet d'étendre la sémantique des machines équivalentes à des groupes
/etc/netmasks Contient les masques correspondants à des sous-réseaux
/etc/networks Contient des numéros de réseau ou sous-réseau et leur association avec un nom
/etc/protocols Contient les numéros des protocoles utilisateurs de la couche IP
/etc/services Liste les services Internet connus de la machine
/etc/exports Contient la liste des parties exportables d'une machine par NFS
/etc/shells Liste les shells adminissibles sur la machine (en particulier pour le produit FTP).


ANNEXE B : Fichiers de définition des protocoles

Il est possible d'écrire de nouveaux logiciels s'appuyant sur les protocoles TCP, UDP, IP, ICMP et ARP car UNIX met à disposition les fichiers de définition de ces protocoles ainsi que les fonctions C permettant de les manipuler. Ces fichiers de définition sont fournis avec le système d'exploitation.

Nom du fichier
Rôle de ce fichier
/usr/include/net/route.h Déclarations des structures de routage (pour les gateways).
/usr/include/net//if_arp.h Définition des messages ARP et des fonctions C permettant de les utiliser.
/usr/include/net/inet/in.h Déclaration des constantes de définition des protocoles basés sur IP (ex : IPPROTO_TCP). Définitions des structures et constantes pour la configuration d'IP, les masques, les datagrammes.
/usr/include/net/inet/if_ether.h Définition des trames Ethernet et des fonctions C correspondantes (ex: ether_sprintf()). Définition des constantes d'Ethernet et des messages ARP transportés par Ethernet.
/usr/include/net/inet/if_802_3.h Définition des constantes pour la norme 802.3 (déclarations pour Ethernet et Token Ring)
/usr/include/net/inet/if_802_5.h Définition des constantes pour la norme 802.5 (déclarations pour Ethernet et Token Ring)
/usr/include/net/inet/icmp_var.h Déclaration de toutes les structures d'ICMP
/usr/include/net/inet/ip.h Définition de toutes les structures et constantes d'IP.
/usr/include/net/inet/ip_icmp.h Définition des constantes et structures d'ICMP lorsqu'il s'appuie sur IP.
/usr/include/net/inet/ip_var.h Contient la définition des ip_queues, des ip_headers, des ip_overlays, des ip_stat et des ip_options.
/usr/include/net/inet/tcp.h Contient la définition des entêtes TCP et des constantes. Est utilisé quand TCP ne s'appuie pas sur IP.
/usr/include/net/inet/tcpip.h Contient la définition des entêtes TCP et des constantes. Est utilisé quand TCP s'appuie sur IP.
/usr/include/net/inet/tcp_debug.h Contient les structures de données permettant le debuggage de programmes conçus avec TCP.
/usr/include/net/inet/tcp_fsm.h Contient les structures de données permettant à TCP de gérer ses flags.
/usr/include/net/inet/tcp_seq.h Contient la définition de la gestion des séquences TCP.
/usr/include/net/inet/tcp_timers.h Contient la définition des timers TCP et de leur méthode de mise à jour.
/usr/include/net/inet/tcp_var.h Contient la définition des blocs de contrôle et des variables de statistiques.
/usr/include/net/inet/udp.hContient la définition d'une entête UDP.
/usr/include/net/inet/udp_var.h Contient les définitions des structures UDP s'appuyant sur IP.

Remarque : Au-dessus de ces outils bas niveau sont mis à disposition des programmeurs des objets tels que les sockets, les TLI et les RPC permettant de concevoir rapidement et simplement des applications. C'est pourquoi les fonctions d'accès directes aux protocoles sont très rarement utilisées.

Dernière modification le 10 juin 2002 à 14:15:20 CET - webmaster@hsc.fr
Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants