Nous allons étudier dans ce chapitre quelques principes fondamentaux que tout administrateur réseau doit constamment avoir à l’esprit.
Le but d’un réseau informatique est d’assurer le transport des données de manière automatique. Tout l’art de l’administrateur est de faire en sorte que le réseau puisse fonctionner de manière autonome, de façon à minimiser les interventions manuelles. Par exemple, l’utilisation de protocoles de routage dynamique, tels que RIP ou OSPF, permet de pallier aux défaillances d’un petit nombre d’équipements actifs pour peu que des chemins alternatifs existent. L’utilisation de DHCP permet de simplifier la configuration des ordinateurs et offre plus de souplesse pour modifier le plan d’adressage IP. Il faut absolument prendre en considération tout ce qui permet de simplifier le travail de l’administrateur réseau.
Dans le même ordre d’idées, de nombreux services réseau permettent soit l’utilisation simultanée de plusieurs serveurs soit la mise en place d’un serveur de secours, voire de plusieurs, prenant automatiquement la place du serveur principal en cas d’incident sur ce dernier. Il est essentiel de profiter de ces possibilités afin d’améliorer la disponibilité du réseau et de diminuer les interventions d’urgence. À cet effet, il est préférable de placer le serveur de secours dans un autre local, voire dans un autre bâtiment que celui qui héberge le serveur principal. Si cela n’est pas possible, il faut au moins le relier à une alimentation électrique et à un équipement actif du réseau différent de ceux du serveur principal.
Par ailleurs, il convient néanmoins de rester prudent face à ce qui peut simplifier la vie de l’administrateur réseau. Un système qui fonctionne correctement lorsqu’il s’agit de gérer quelques dizaines de machines ou de connexions peut se révéler inadapté pour un nombre plus important. Malheureusement, seules l’expérimentation
(Quitte à en payer les pots cassés) et l’expérience d’autres administrateurs réseau (qui ne coûte pas cher et permet souvent d’éviter les écueils) permettent d’en avoir le cœur net.
Enfin, on aura beau avoir tous les systèmes redondants du monde, il est néanmoins nécessaire d’effectuer une surveillance rapprochée de son réseau afin d’être au courant des incidents et de pouvoir réagir en conséquence. Parmi les logiciels de surveillance, on peut citer Nagios 1 qui, outre sa gratuité, a l’avantage d’être particulièrement polyvalent.

• Le matériel
  • Méfiance face aux fournisseurs

C’est bien connu, les fournisseurs sont là pour vous faire acheter leurs matériels. Ils sont en revanche beaucoup plus discrets lorsqu’il s’agit de résoudre les problèmes que leur utilisation pourrait entraîner. Le souci le plus commun survient lors de la mise à jour des logiciels (en particulier les systèmes d’exploitation des matériels actifs) vers une version plus récente. Certains constructeurs poussent même le vice jusqu’à sortir des versions mineures de leurs logiciels chaque semaine. Dans ces conditions, il est bien évidemment impossible d’effectuer des mises à jour aussi fréquemment.
La démarche la plus sage consiste à bloquer son parc sur une version particulière des logiciels, dont on aura constaté la stabilité, et de ne les mettre à jour que pour de bonnes raisons (cela peut être la disponibilité de nouvelles fonctionnalités, l’amélioration des performances, la correction d’un problème de sécurité, etc.).

• • La maintenance

Les équipements tombent en panne un jour ou l’autre, c’est dans l’ordre des choses.
En conséquence, tous les matériels doivent disposer d’une maintenance permettant de faire remplacer les pièces défectueuses. Il existe différents délais de remplacement, plus ou moins rapides, et c’est à chacun de définir ce qui convient le mieux à son réseau, en fonction de ses contraintes de fonctionnement et de ses moyens financiers, les délais de remplacement les plus courts étant évidemment les plus coûteux.
Une option intéressante, pour les parcs d’une taille suffisante et suffisamment homogènes, est de disposer d’un équipement supplémentaire de chaque type et de souscrire la maintenance la plus lente possible lorsque ceci est rentable. Il est très improbable d’avoir deux pannes en même temps donc, en cas de défaillance, c’est l’équipement supplémentaire (ou l’un de ses composants) qui remplacera dans un délai très court l’équipement défaillant. Celui-ci sera alors remplacé au titre de la maintenance par un équipement qui deviendra le nouvel équipement de secours.

• •   La valorisation des vieux équipements

Il existe des entreprises spécialisées dans la vente et l’achat d’équipement informatique d’occasion, dont le matériel réseau. Lors de la réforme d’anciens appareils, il peut être intéressant d’envisager leur revente à l’une de ces entreprises, certains matériels pouvant avoir une valeur résiduelle non négligeable.

• •   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).

• •   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 aspects on peut citer :

• La disponibilité traitée au paragraphe au début de la section ‘‘les fondements’’,
• L’intégrité 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.
• La non répudiation, permettant de garantir qu'une transaction ne peut être niée ; La non répudiation de l'information est la garantie qu'aucun des correspondants ne pourra nier la transaction
• L'authentification, consistant à assurer que seules les personnes autorisées aient accès aux ressources. A ce titre, elle permet de vérifier l'identité d'un utilisateur, c'est-à-dire de garantir à chacun des correspondants que son partenaire est bien celui qu'il croit être. Un contrôle d'accès peut permettre (par exemple par le moyen d'un mot de passe qui devra être crypté) l'accès à des ressources uniquement aux personnes autorisées.

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.

• •   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 programmes 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 (Domaine Name Service), comme vous ne le savez peut-être pas encore 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 :
 

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 :
 

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.

• •   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