Liste de  cours reseau

Administration RI -ver3 : concepts de base de la gestion de reseau


Télécharger


Initiation aux concepts de base de la gestion de réseau

 Les 5 domaines fonctionnels

  1. L’ISO a classifié les principales activités et fonctions d'administration en groupes homogènes ayant des interactions internes et externes.
  2. Domaines ou aires fonctionnelles
  3. Configuration
  4. Performances

    span>
  5. Alarmes
  6. Comptabilité
  7. Sécurité

Gestion de la configuration

  1. Gestion des ressources physiques et logiques du réseau (identification + contrôles)
  2. Identification, découverte et localisation de chaque ressource (topologie du réseau), nommage
  3. Configuration des équipements et des ressources
  4. Création et activation périodique des scénarii de configuration
  5. Gestion des versions : basculement, MAJ, ...
  6. Définition des relations entre ressources : Composition ou contenance, utilisation,dépendance, secours, groupe, ...
  7. Collecte des informations d’état et traitements

Gestion des alarmes (évenements)

  1. Prise en charge de tous les signes de dysfonctionnements du réseau, les traiter, en évaluer l’impact et le cas échéant, intervenir et réparer.
  2. Collecte et filtrage, journalisation, qualification et corrélation/diagnostic
  3. Reporting aux exploitants selon les règles de diffusion et gestion des acquittements
  4. Prévention des dysfonctionnements (Performance et configuration) et activation de tests à distance
  5. Correction et réparation

Gestion des performances

  1. Maintien du niveau de performance conformément à la QoS (Quality of Service) contractuelle vis à vis des utilisateurs (Gestion temps-réel)
  2. Collecte d’indicateurs et gestion des journaux
  3. Calcul de performances
  4. temps de réponse et temps de transit
  5. temps d'établissement des connexions et libération
  6. temps d'exécution des requêtes et transactions, ...
  7. Statistiques
  8. Fautes et incidents #
  9. Mesure de charges, ...
  10. Production d'histogrammes

Gestion de la sécurité

  1. Veiller à la sécurité (logique et physique) du réseau, des ressources disponibles pour les usagers et protéger les données et le flux d'informations généré par l'activité des utilisateurs.
  2. Gestion des droits d'accès et protection des ressources
  3. Opérateurs d'exploitation
  4. Clients du service
  5. Administrateur du système
  6. Support du service, ...
  7. Ressources informatiques, ...

Gestion de la comptabilité

  1. Mesurer les coûts réels d'utilisation du réseau et des ressources en réseau dans un but de gestion économique
  2. Mise en oeuvre de la politique tarifaire et de la stratégie de communication
  3. Collecte des données de taxation
  4. Information des usagers et conseil pour l'optimisation des dépenses
  5. Elaboration des factures et affectation des coûts
  6. Facturation des usagers et recouvrement

La gestion de réseau : 4 concepts de base

  1. Modèle conceptuel Manager/Agents: Spécialisation des systèmes
  2. Modèle de communication: Echanges des informations
  3. Modèle d’information et MIB :Définition & gestion de données
  4. Modèle d’architectures: Distribution des fonctions

Agents Intelligents ou Agents de médiation

  1. Besoin :
  2. éviter la saturation des systèmes de gestion
  3. réduction du trafic dû à l’échange des informations de gestion
  4. Fonctions:

- réalisation de certains traitements en local (filtrage, corrélation, ...)

- gestion de données en local

Sondes (capteurs, ...)

  1. Besoin : Surveillance et gestion du dialogue sur les liaisons entre équipements réseau (munis d’agents ou non)
  2. Fonctions :
  3. surveillance de la transmission
  4. acquisition et analyse des informations de trafic
  5. notification sur seuils et problèmes

Initiation aux concepts de base de la gestion de réseau

L'ADMINISTRATION réseau, de même que l’administration système d’ailleurs, est une discipline qui ne s’enseigne pas. Ceci peut paraître paradoxal puisque ce document est le support d’un cours d’administration réseau, justement. Relativisons les choses, si l’administration réseau ne s’enseigne pas, en revanche, elle s’apprend et le but de ce cours est de donner aux élèves un minimum d’éléments leur permettant par la suite d’orienter leur apprentissage dans la bonne direction.

Pourquoi l’administration réseau ne s’enseigne-t-elle donc pas? Tout d’abord, parce c’est un domaine bien trop vaste et qui évolue trop rapidement pour que quiconque puisse le dominer de la tête et des épaules. De plus, le nombre de matériels et de logiciels est trop important pour qu’on puisse en faire une étude sérieuse. De toute façon, chaque entreprise a fait ses choix dans ce domaine et les jeunes ingénieurs auront généralement â s’y plier.

Ce cours ne se veut donc pas exhaustif. En particulier, nous n’aborderons pas du tout la configuration des équipements actifs (routeurs, commutateurs, etc.). Celle-ci nécessiterait un cours entier â elle seule et obligerait â faire un choix partial pour tel ou tel constructeur.

En revanche, dans ce cours, nous essaierons de dégager des principes généraux sur la bonne façon d’administrer un réseau. Le champ d’application étant plutôt étendu, nous nous limiterons â quelques technologies fondamentales, applicables aux réseaux IP sur Ethernet : les réseaux virtuels (VLAN), sans lesquels on ne peut construire de nos jours un réseau moderne et souple;

Simple Network Management Protocol (SNMP), le protocole d’administration réseau par excellence, que nous étudierons en détail et dont nous discuterons les avantages et les inconvénients;

les annuaires, en particulier le Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP) et Lightweight Directory Access Protocol (LDAP) ;

la messagerie, avec l’étude des logiciels sendmail et Postfix.

Par ailleurs, le langage de programmation Perl, outil indispensable â tout ad-ministrateur réseau, sera rapidement évoqué, son étude pouvant représenter â elle seule l’objet d’un cours entier.

Mais, tout d’abord, il convient de poser les bases sans lesquelles tout travail sérieux est impossible.

...

2.3 Un peu d’administration système

L’administration réseau est rarement totalement découplée de l’administration système, pour la simple raison que le bon fonctionnement d’un réseau repose généralement sur un certain nombre de serveurs. Il n’est donc pas inutile de rappeler un certain nombre de règles élémentaires d’administration système.

Un serveur fiable a toujours au moins deux disques. L’un utilisé uniquement pour le système (donc, grosso modo, contenant /, /usr, /var et du swap), l’autre contenant les comptes des utilisateurs (/home) et surtout les logiciels recompilés (/usr/local) ainsi que les fichiers de configuration de ces logiciels (par exemple /opt), de manière â séparer les fichiers résultant d’installation de logiciels, qui sont dans /usr/local, et les fichiers générés par des humains, qui sont dans /toto. De cette façon, en cas de problème matériel sur le serveur, il est très simple de déplacer le second disque sur une machine installée de la même façon (donc avec un premier disque identique). Une autre approche est de placer /usr/local et /toto sur un serveur NFS mais on préfère généralement les disques locaux pour éviter les dépendances entre machines.

Un serveur est rarement administré par une seule personne. Il est donc nécessaire de gérer l’accès concurrent aux fichiers modifiables par les administrateurs. Une façon élégante de faire est d’utiliser RCS (voir l’annexe A).

2.4 La sécurité est essentielle

Lorsqu’on parle de sécurité, cela recouvre un domaine très vaste, comprenant entre autres le contrôle d’accès, l’intégrité, la confidentialité et la disponibilité.

Parmi ces aspect, la disponibilité a été traitée au paragraphe 2.1, l’intégrité est assurée en partie par les sommes de contrôle de TCP et d’UDP (rien n’interdisant un intrus placé sur le chemin d’un paquet de modifier les paquets et de recalculer les sommes de contrôle en conséquence), la confidentialité est assurée par IPsec ou par des dispositifs de chiffrement spécifiques.

Le contrôle d’accès, quant â lui, doit être imposé sur tous les équipements actifs et les serveurs, afin que seules les personnes autorisées y aient accès. Il est en effet particulièrement désagréable de voir son travail ruiné par un intrus qui aurait modifié, voire effacé, la configuration de ses équipements. Pour s’en prévenir, outre un contrôle d’accès adéquat, il est préférable de conserver en sûreté les configurations de tous les équipements, afin de pouvoir les restaurer rapidement en cas de problème. En particulier, de nombreux équipements actifs acceptent soit d’être configuré en direct (par l’intermédiaire d’une connexion réseau ou d’une connexion sur port série) soit de télécharger leur configuration, généralement par TFTP. Cette dernière approche est â privilégier puisqu’elle permet de conserver la trace de la configuration sur le serveur TFTP.

2.5 Les fichiers de configuration

D’ailleurs, quasiment tous les équipements actifs acceptent de télécharger leur configuration, en totalité ou par morceaux, depuis un serveur (généralement par TFTP). Les mauvais administrateurs réseau s’enorgueillissent de pouvoir générer â la main de nombreux fichiers de configuration plus complexes les uns que les autres, au risque d’y introduire des erreurs de syntaxe ou, plus grave, d’avoir â gérer la redondance des informations entre plusieurs fichiers.

En revanche, l’administrateur réseau futé et qui de plus applique le principe des doigts de pied en éventail adopte plutôt un autre principe lorsque cela est possible (attention, ce n’est pas toujours le cas). Il met au point un certain nombre de pro-grammes qui permettent, â partir d’informations élémentaires et non redondantes, de générer les différents fichiers de configuration qui en découlent.

Prenons un exemple concret tiré d’une situation réelle. Le DNS, comme vous ne le savez peut-être pas encore (dans ce cas, vous pouvez vous référer au paragraphe 5.1) permet de connaître l’adresse IP associée â un nom de machine et vice versa. Pour cela, le serveur a besoin de deux fichiers de configuration, l’un contenant, pour chaque nom, l’adresse IP correspondante, et l’autre contenant, pour chaque adresse IP, le nom correspondant. Ceci est une vision un peu simplifiée de ce que permet de faire le DNS mais elle couvre son utilisation habituelle. Il est évidemment idiot de gérer ces deux fichiers â la main (sauf lorsqu’on n’a qu’une dizaine de machines â y enregistrer), puisqu’ils contiennent somme toute les mêmes informations. De plus, leur format est adapté â leur interprétation par un logiciel mais pas vraiment â leur rédaction manuelle. Il est plus simple de ne gérer qu’un seul fichier, contenant par exemple des lignes de la forme :

nom_de_machine          adresse_IP

et de générer â partir de celui-ci les deux fichiers de configuration du DNS au moyen d’un programme maison. Non seulement cette méthode est plus simple et plus rapide (principe des doigts de pied en éventail) mais elle permet également d’avoir des fichiers de configuration exempts d’erreurs de syntaxe (pour peu que le programme maison soit bien conçu). Le programme maison peut également en profiter pour redémarrer le serveur DNS après avoir généré les fichiers de configuration, ce qui évite une manipulation supplémentaire.

Mais on peut aller plus loin. De nos jours, on ne configure plus les paramètres réseau des ordinateurs (adresse IP, masque de sous-réseau, routeur par défaut...) manuellement, on utilise DHCP en attribuant â chaque machine soit une adresse prise au hasard dans un ensemble donné soit une adresse fixe choisie en fonction de l’adresse Ethernet de la machine (cette dernière méthode est d’ailleurs préférable car elle permet de suivre les incidents plus facilement). Pour cela, le serveur DHCP a besoin d’un fichier de configuration contenant un certain nombre d’informations dont, pour chaque machine, son adresse Ethernet et son adresse IP ou son nom (dans ce cas, le serveur DHCP utilise le DNS pour faire la conversion). En étendant le format du fichier unique utilisé pour le DNS â quelque chose du genre :

nom_de_machine adresse_IP adresse_Ethernet

on peut continuer â utiliser ce fichier pour le DNS (il suffit d’ignorer le dernier champ) et également pour générer le fichier de configuration du serveur DHCP â l’aide d’un deuxième programme maison.

J’arrêterai cet exemple ici, mais on peut encore l’étendre â la configuration des commutateurs.

2.6 Perl

Nous venons de voir que l’administrateur réseau futé est celui qui se simplifie la vie en mettant au point de petits programmes lui permettant de générer des fichiers de configuration complexes â partir de fichiers beaucoup plus simples. Ceci peut, bien entendu, être réalisé au moyen de n’importe quel langage de programmation mais l’un d’eux se révèle particulièrement adapté â ce type de travail, il s’agit de Perl.

Perl, également très utilisé en administration système, est incontournable dès qu’il est question d’analyser et de générer des fichiers au format texte parce que les outils le permettant sont intelligemment inclus dans le langage lui-même. Sorte de mélange de nombreux autres langages, reprenant â chacun ce qu’il sait bien faire, Perl dispose de plus d’une immense bibliothèque de modules permettant de réaliser très simplement â peu près tout ce â quoi l’on peut penser.

Ici n’est malheureusement pas la place pour un cours détaillé sur Perl. Une présentation très rapide est fournie dans le cours B1-3.

...

4.2 Sécurité

Le protocole permettant la gestion des équipements actifs du réseau devrait logiquement être le plus sécurisé de tous les protocoles avec, en particulier, un contrôle d’accès et une confidentialité irréprochables.

Tous les documents décrivant SNMP (avant la version 3) se contentaient, au paragraphe Security Considerations, d’un commentaire laconique :

Security issues are not discussed in this memo.

Et, en effet, le contrôle d’accès était approximatif et la confidentialité inexistante. SNMPv3, quant â lui, accorde enfin une large part de sa spécification au contrôle d’accès, la confidentialité étant naturellement laissée â IPsec.

4.3 Principes

4.3.1 Les agents

Chaque équipement ou logiciel pouvant être interrogé par SNMP comporte un serveur appelé agent. Celui-ci écoute sur le port UDP 161.

4.3.2 Les MIB

Les paramètres pouvant être examinés ou modifiés par l’agent sont définis dans une MIB (Management Information Base), qui est un document décrivant ces différents paramètres, leur type (nombre entier, chaîne de caractères...), s’ils sont modifiables ou non (dans l’absolu, indépendamment des droits d’accès), etc.

La MIB la plus utilisée est certainement la MIB-II, décrite dans le RFC 1213, qui définit un ensemble cohérents de paramètres communs â tous les équiments. C’est cette MIB que nous étudierons par la suite.

Chaque élément d’une MIB est défini par un nom et un numéro (comme d’ha-bitude, on retrouve cette dualité, les noms étant plus faciles â manipuler pour nous, pauvres humains, et les nombres plus faciles â manipuler par les ordinateurs). Ainsi, dans la MIB-II, l’objet sysContact, indiquant le nom de la personne responsable d’un équipement, est défini ainsi :

...

SYNTAX indique le type de l’objet selon la syntaxe ASN.1 (Abstract Syntax Notation One).

ACCESS indique le mode d’accès â l’objet. Les valeurs suivantes sont possibles :

– read-only

– read-write

– write-only

– not-accessible

STATUS indique si l’objet doit obligatoirement être présent dans toute implémenta¬tion de la MIB ou pas. Les valeurs suivantes sont possibles :

– mandatory – optional – obsolete

DESCRIPTION est un texte destiné â l’administrateur et qui décrit l’objet.

La dernière ligne de la définition attribue â l’objet sysContact le numéro 4 dans le groupe system. En effet, les MIB sont hiérarchisées â la manière des répertoires dans un système de fichiers. Le nom complet de cet objet au sein de la MIB-II est donc system.sysContact (le point est utilisé comme séparateur) ou bien system.4 ou bien 1.sysContact (system a pour numéro 1) ou, encore moins lisible, 1.4.

La MIB-II fait elle-même partie d’une hiérarchie plus large :

.iso.org.dod.internet.mgmt .1.3.6.1.2

– La racine de la hiérarchie n’a pas de nom et est désignée simplement par un

point.

– iso (1) désigne l’International Organization for Standardization.

– org (3) a été créé par l’ISO â l’intention de divers organismes.

– dod (6) a été attribué au ministère de la Défense des États-Unis (Department of

Defense).

– internet (1) regroupe tout ce qui touche â l’Internet.

– mgmt (2), enfin, est utilisé pour les standards de l’IAB.

Sous .iso.org.dod.internet.mgmt, la MIB-II a pour nom mib-2 et pour numéro

1, de telle sorte que l’objet sysContact a pour nom absolu:

.iso.org.dod.internet.mgmt.mib-2.system.sysContact .1.3.6.1.2.1.1.4

En pratique, cet objet est d’un type discret (ce n’est pas un tableau et il ne contient donc qu’une valeur) donc on lui ajoute un .0 final, ce qui donne comme nom absolu:

.iso.org.dod.internet.mgmt.mib-2.system.sysContact.0 .1.3.6.1.2.1.1.4.0

Les objets pouvant contenir plusieurs valeurs se voient ajouter â leur nom un .1 pour la première valeur, .2 pour la deuxième et ainsi de suite. Somme toute, SNMP est simple!

4.3.3 Les opérations

Sans rentrer dans le détail du protocole et des formats de paquets, il est néan-moins intéressant de savoir un minimum comment fonctionne le dialogue entre un agent SNMP et un logiciel d’administration.

Il existe grosso modo quatre types de messages :

Get permet de récupérer un objet bien précis.

Get next renvoie l’objet suivant (dans l’ordre lexicographique) celui passé en para-mètre. Ceci est particulièrement utile pour passer en revue toute une MIB.

Set permet de modifier la valeur d’un objet.

Trap permet â un agent d’envoyer un signal au logiciel d’administration et ce de son propre chef. Les trois types de messages précédents étaient envoyés par le logiciel d’administration â l’agent, celui-ci fonctionne en sens inverse. Il est très utile pour effectuer une surveillance passive du réseau, les équipements se plaignant si nécessaire.

4.3.4 Les communautés

Dans SNMPv2, le contrôle d’accès est fait en fournissant dans chaque message un mot de passe appelé communauté. Il existe généralement deux communautés, l’une utilisée pour les accès en lecture (c’est par défaut la chaîne de caractères public), l’autre utilisée pour les accès en écriture (c’est par défaut la chaîne de caractères private). Il est évidemment essentiel de modifier ces valeurs et de les tenir secrètes.

4.4 net-snmp

La plupart des équipements réseau intègrent un agent SNMP. Certains logiciels également, de même que les systèmes d’exploitation commerciaux. Les UNIX libres, quant â eux, utilisent la suite logicielle net-snmp. Celle-ci regroupe un agent, divers outils d’interrogation ainsi qu’une bibliothèque de fonctions C permettant de construire des agents SNMP ou d’intégrer des capacités d’interrogation dans d’autres logiciels.

Nous étudierons dans ce paragraphe l’agent net-snmp ainsi que les outils qu’il fournit.

...

Les annuaires

ON DÉSIGNE sous le terme générique annuaire tout service permettant d’obtenir des informations à partir d’une base, centrale ou répartie (de même que l’annuaire téléphonique permet d’obtenir le numéro de téléphone à partir du nom de quelqu’un).

Les annuaires sont rarement indispensables mais ils apportent un confort non négligeable soit aux utilisateurs (c’est le cas du DNS) soit à l’administrateur réseau (c’est le cas de DHCP).

Les annuaires peuvent généralement être gérés soit par plusieurs serveurs simulta¬nément soit par un serveur principal et par un ou plusieurs serveurs secondaires qui en prennent le relais en cas de défaillance. Étant donné l’importance que prennent les annuaires dès qu’on commence à les utiliser, il est indispensable de profiter de ces capacités de redondance.

5.1 Domain Name System (DNS)

Le DNS est l’annuaire le plus ancien et certainement le plus utilisé. En effet, dans un réseau IP, chaque machine est repérée par une adresse, qui est un nombre sur 32 bits pour IPv4 et sur 128 bits pour IPv6. Autant les ordinateurs sont plutôt doués pour gérer des nombres, autant nous autres humains le sommes bien moins et il est plus facile pour nous de mémoriser des noms (faites donc l’essai avec vos amis, vous souvenez-vous plus facilement de leurs noms ou de leurs numéros de téléphone?). Le DNS est un moyen d’associer un nom à chaque adresse IP et vice versa (ceci est une vision réductrice mais elle correspond à l’utilisation principale du DNS).

Le DNS est décrit dans les RFC 1033 à 1035 (datant de novembre 1987). De nombreux autres RFC décrivent des extensions au DNS.

Le DNS utilise les ports UDP et TCP 53.

5.1.1 Un peu d’histoire

Dans les temps anciens, à l’époque où l’Internet n’était composé que d’une poignée de machines sur des sites qui se comptaient sur les doigts des deux mains, on disposait déjà d’un système permettant d’associer des noms aux adresses IP. Il était

basé sur un fichier, très semblable â l’/etc/hosts des systèmes UNIX d’aujourd’hui, qui devait être présent â l’identique sur toutes les machines de l’Internet. Pour illustrer ce retour aux sources, considérons le fichier suivant, dont nous utiliserons les informations par la suite :

                147.250.14.1      guinness

                147.250.14.2      blanche

Évidemment, l’ajout d’une nouvelle machine impliquait la recopie du nou¬veau fichier sur toutes les autres et ce système a très vite montré ses limites, d’où l’invention du DNS.

5.1.2 Principes de fonctionnement

Le DNS est une base de données répartie. Par rapport au système précédent, on ne dispose plus d’un fichier unique de correspondances entre adresses IP et noms mais de plusieurs et chaque site maintient les informations correspondant â ses machines et les met â la disposition du reste de l’Internet par un protocole approprié. Pour savoir quel serveur interroger, le système de nommage a été hiérarchisé. À cet effet, l’Internet a été découpé en domaines. Un domaine correspond â un ensemble de machines dépendant administrativement de la même entité.

5.1.2.1 Le système de nommage

Toute hiérarchie commençant quelque part, la racine du DNS s’appelle « . ». Sous cette racine ont été créés des top-level domains (TLD) permettant d’effectuer un premier rangement des niveau inférieurs. Parmi les TLD, on retrouve :

des domaines fonctionnels créés â l’origine par et pour les américains, ce qui explique leur vision un peu réduite des choses :

– com pour les entreprises,

– edu pour les universités,

– gov pour les institutions gouvernementales,

– int pour les organismes internationaux,

– mil pour les organismes militaires (l’Internet ayant été inventé par les

militaires américains),

– net pour les fournisseurs d’accès â l’Internet,

– org pour les autres organisations;

des domaines nationaux créés par la suite selon la norme ISO 3166-1 :

– au pour l’Australie, – de pour l’Allemagne, – fr pour la France, – etc.

48