Rapport de Stage de M2 Informatique Opti
Rapport de Stage de M2 Informatique Opti
Rapport de Stage de M2 Informatique Opti
__________________________________________________________________
Résumé
Dans les entreprises dont les services reposent en grande partie sur leur système informatique, la
performance du réseau et la haute disponibilités des différents services applicatifs sont
primordiaux. Une panne de quelques minutes est punie par une perte se chiffrant en milliers d'euros,
une lenteur des services par le mécontentement des clients.
Vivetic est une de ces entreprises. En tant que société de sous-traitance informatique et
d'externalisation, ses services nécessitent un système informatique disponible en permanence,
propre de tout problème de lenteur. C'est dans ce cadre que je l'ai intégré pour mon stage de fin
d'études, en me plaçant au cœur du projet de restructuration de son réseau pour mieux répondre aux
exigences de performance et de continuité de service.
Summary
In companies whose services are largely based on their computer system, network performance and
high availability of the different applications are crucials. A failure of few minutes is punishable by
a loss amounting in thousands of euros, a slowness of services by customer dissatisfaction.
Vivetic is one of those companies. As a society of IT outsourcing, its services require a computer
system continuously available, clean of any problems of slowness. During the time I worked there
for my end-of-studies internship, I was the main actor of the restructuring of its network to better
meet the requirements of performance and service continuity.
Remerciements
Je remercie tout d'abord les différents responsables du Master Informatique et de l'ESIROI pour
m'avoir donné l'opportunité de faire ce double cursus et présenter maintenant ce rapport.
Je remercie ensuite la société Vivetic pour m'avoir accueilli en son sein pendant ces plusieurs mois
de stage. Je remercie Bruno RAHARIVOLA pour m'avoir donné la chance d'intégrer la société à
travers la Direction Technique qu'il dirige. Je remercie Iandry RAKOTOZAFY, responsable du
département Réseaux et Systèmes et aussi mon maître de stage, pour la confiance qu'il m'a accordée
dès les premiers contacts ainsi que pour l'encadrement qu'il m'a donné sans quoi le projet de stage
n'aurait pas abouti. Je remercie tous les autres membres du département Réseaux et Systèmes pour
la collaboration fructueuse que j'ai pu faire avec eux. Je remercie tous les informaticiens de
maintenance pour l'accueil très chaleureux qu'ils m'ont offert ; parmi eux, je remercie
particulièrement Mamy RAKOTOARIMANANA qui m'a assisté pendant toute la phase de test du
projet.
Je remercie enfin toutes les personnes qui ont contribué de près ou de loin à la bonne réalisation de
ce stage et à l'écriture du présent rapport.
Introduction
Ces stages permettent de découvrir et connaître le monde professionnel afin d'être directement
opérationnel à l'issue de la formation. Pour mieux renforcer l'intégration dans le monde
professionnel, j'ai en plus réalisé, toujours dans le cadre scolaire, un projet avec la Direction du
Système d'Information et des Usages du Numérique (DSIUN) de l'Université de la Réunion et un
autre avec l'association Immersion La Réunion.
Pour couronner toutes ces expériences, je désirais effectuer un stage dans lequel je serai affecté à un
projet de grande envergure. Après quelques recherches, je suis rapidement entré en contact avec la
société Vivetic implantée à Madagascar, mon pays natal. Vivetic est la plus grande société
d'externalisation et de sous-traitance informatique présente à Madagascar.
Le projet qu'elle propose, à savoir restructurer son réseau local comptant plus de mille deux-cents
machines, est de taille et effectuer mon stage de fin d'études à Madagascar honorerait le contrat que
j'ai signé avec mon école d'origine, l’École Supérieure Polytechnique d'Antananarivo (ESPA
Madagascar), qui m'a envoyé à l'ESIROI à ma deuxième année du cycle Ingéniorat.
• Traitements de Données,
• Modération de Contenus,
• E-Commerce,
• Centre de Contacts,
• Traitements d'Emails,
• Marketing Direct.
Vivetic est une entreprise française. Ainsi, bien qu'ouvert à l'international, Vivetic traite des dossiers
essentiellement francophones. Leader dans son domaine, Vivetic offre/a déjà offert ses services aux
plus grands grands noms : ebay, DHL, cadreemploi.fr, cadresonline, Le Monde, Société Générale,
Samsung, le Parisien, Nokia, Nestlé, Honda, ...
Implantée à Madagascar depuis 1995, Vivetic est actuellement le leader du traitement offshore dans
la Grande Île. Elle possède deux sites principaux :
• Le site de Madagascar, au sein duquel j'ai effectué mon stage, qui abrite le Centre de
Traitement.
• une Direction Qualité, Vivetic étant une entreprise certifiée ISO 9001, engagée dans le
système de management de la qualité pour assurer la satisfaction client,
Au cours de ces trois mois, j'ai échangé avec chaque personne de ce département (une dizaine de
personnes environ), notamment avec :
• Mon sus-cité maître de stage, pour son fil directeur et l'étroite collaboration que j'ai eu avec
lui,
• Des informaticiens de maintenance, pour leurs aides sur les configurations logicielles des
postes clients.
Structurellement j'ai été rattaché au responsable LAN mais comme mon projet de stage était un
enjeu majeur de l'entreprise, j'ai été pratiquement sous la supervision directe du Responsable
Réseaux et Systèmes.
• Comité de Direction,
• Planning et Méthodes,
• Informatique et Méthodes,
• Bureau Marketing,
• Bureau Avant-Vente,
• Production texte.
2. Missions confiées
Vivetic compte plus d'un millier d'employés. Elle possède donc un très vaste parc informatique : on
compte actuellement environ mille deux-cents postes clients. Comme la société est en pleine
croissance, ce chiffre peut potentiellement croître très rapidement. La gestion de son réseau peut
donc vite devenir complexe et fastidieuse si les bonnes solutions ne sont pas prises.
De plus, le réseau doit faire face aux exigences de disponibilité des ressources (les postes clients, les
serveurs, les imprimantes, les équipements réseau…) et de continuité des activités. Toute
interruption ou perturbation au niveau du réseau impacte directement sur la qualité des prestations
de Vivetic et donc sur ses engagements clients.
2.1. Problématique
L'architecture actuelle du réseau local de Vivetic est une architecture très simple, où tout le monde
se trouve dans le même domaine de diffusion 1, sur la même plage d'adresse IP. Bien qu'adaptée au
début, du temps où le nombre des machines n'était pas aussi important, les limites de cette
architecture commencent désormais à se faire sentir et il est absolument nécessaire d'y remédier
avant qu'elles ne soient atteintes.
En termes de performance, cette architecture est loin d'être optimale à cause du nombre très
important de broadcast transmis. Ci-dessous la liste des protocoles rencontrés au sein du réseau de
Vivetic qui émettent le plus de paquets en broadcasts :
• NBNS pour NetBIOS Naming System qui est un protocole utilisé pour la résolution des
noms NetBIOS (noms des machines sous Windows) : si aucun serveur WINS n'est spécifié
(c'est un serveur similaire au DNS mais utilisé pour la résolution de noms NetBIOS) alors
une requête NBNS est envoyé en broadcast à toutes les machines du réseau afin que le
possesseur du nom réponde par lui-même. Comme il n'y a pas de serveur WINS spécifié sur
la plupart des postes clients de Vivetic alors que les noms NetBIOS sont très sollicités, un
nombre très important de requêtes NBNS est généré à chaque seconde,
• ARP lors de la recherche de l'adresse MAC correspondant à une adresse IP non présente
dans la table d'adresse MAC.
1 La notion de domaine de diffusion est rappelée dans la section 3.1.1. Domaine de diffusion
En plus de ces problèmes de performances, l'architecture actuelle est également assez limitée en
termes de gestion :
• Problème de gestion des accès : tous les postes clients peuvent se voir. Des échanges entre
postes qui n'ont aucune raison de communiquer entre eux sont constatés. C'est le cas du
centre BPO et le centre SMS par exemple. Une considération plus grave encore se trouve au
niveau sécurité : une personne malveillante aura l'intégralité du réseau comme champ
d'attaque potentiel !
Le projet était censé être réalisé en 2013 même. Malheureusement, cela coïncidait avec un autre
projet très important qui était l'aménagement d'un nouveau local de la société. Ne voulant pas
apporter de modifications trop importantes au niveau du réseau pendant cette phase de peur de
rencontrer des problèmes qui couperaient la continuité du service, et avec les ressources
manquantes car toutes concentrées sur l'aménagement du nouveau local, le projet a été
intégralement reporté, depuis la phase de recherche de solutions jusqu'à la phase d'implémentation.
Ce projet de restructuration était l'objet principal de mon stage. J'en étais le principal acteur.
• Phase d'étude
C'est la phase d’identification des différentes solutions possibles, en adéquation avec les différents
outils déjà à disposition ainsi qu'avec les différentes contraintes de la société. Seront mis en exergue
le coût, la disponibilité de la documentation, l'existence de support, la régularité des mises à jour
ainsi que tout autre critère conditionnant la pérennité de la solution.
• Phase de test
C'est la phase permettant de mettre la solution à l’épreuve en environnement virtuel de test et/ou
dans un laboratoire de test afin d'avoir un prototype de la solution.
• Phase de déploiement
C'est la phase ultime du projet, consistant à déployer la solution sur une unité de production pilote.
A l'heure où ce rapport est écrit, la phase de déploiement n'est pas encore prévue être réalisée.
Seule la phase de test l'est, et elle a été effectivement bien réalisée.
3. Approfondissements
Comme un switch répète sur tous ses autres ports tout paquet broadcast qu'il reçoit d'un de ses ports,
les hôtes interconnectés par un ou des switches appartiennent au même domaine de diffusion. Les
broadcasts sont utiles et essentiels pour le bon fonctionnement d'un réseau, mais dans un réseau de
switches trop grand, les paquets broadcastés deviennent trop nombreux et ralentissent le réseau.
C'est pourquoi on divise les grands réseaux en des réseaux plus petits, possédant chacun son propre
domaine de diffusion, interconnectés entre eux par des routeurs. En effet, un routeur ne permet pas à
un paquet en broadcast de passer d'un réseau à un autre. On dit qu'un routeur casse un domaine de
diffusion.
• VLAN de niveau 1 ou VLAN par port : on y définit les ports du commutateur qui
appartiendront à tel ou tel VLAN. Cela permet entre autres de pouvoir distinguer
physiquement quels ports appartiennent à quels VLAN.
• VLAN de niveau 2 ou VLAN par adresse MAC : on indique directement les adresses MAC
des cartes réseaux contenues dans les machines que l'on souhaite voir appartenir à un
VLAN.
• VLAN de niveau 3 ou VLAN par adresse IP : même principe que pour les VLAN de niveau
2 sauf que l'on indique les adresses IP (ou une plage d'IP) qui appartiendront à tel ou tel
VLAN.
Pour déployer des VLAN, cela sous-entend que le commutateur utilisé soit gérable et qu'il gère les
VLAN du niveau désiré ; à savoir également que plus le niveau de VLAN est élevé, plus le
commutateur sera cher à l'achat.
L'utilisation des VLANs permet une optimisation de la bande passante car les broadcasts, multicasts
et unicasts sont restreints dans le VLAN associé. De plus, elle offre une couche sécurité car un hôte
d'un VLAN ne peut pas communiquer directement avec celui d'un autre.
La suite présente les différents types de VLANs avec leurs avantages et inconvénients.
Les VLANs par port associent un port d'un switch à un numéro de VLAN. On dit alors que le port
est tagué suivant le VLAN donné. Le switch entretien ensuite une table qui lie chaque VLAN au
port associé.
Avantages :
• L'avantage principal du VLAN par port est qu'il permet une étanchéité maximale des
VLANs. Une attaque extérieure ne pourra se faire qu'en branchant le PC pirate sur un port
tagué. Le pirate a donc besoin d'avoir un accès physique pour pénétrer le VLAN.
• Le VLAN par port offre une facilité de configuration dans le sens où l'administrateur peut
sans difficulté choisir les ports à taguer sans avoir d'information de la part des machines
auxquelles sont reliés les ports.
Inconvénients :
• Le principal inconvénient du VLAN par port est qu'il nécessite une configuration lourde et
contraignante sur chaque switch. A chaque déplacement de poste, il faut modifier les
switches.
• Le mécanisme de VLAN par port ne possède pas d'architecture centralisée qui pourrait
Avantages :
• Les VLANs de niveau 2 permettent une sécurité au niveau de l'adresse MAC, c'est à dire
qu'un pirate souhaitant se connecter sur le VLAN devra au préalable récupérer une adresse
MAC du VLAN pour pouvoir entrer.
• Les VLANs de niveau 2 offrent des possibilités de centralisation des tables VLANs adresses
MAC. Chaque switch interroge ensuite cette table pour connaître les informations
nécessaires à une adresse MAC donnée.
Inconvénient :
Le VLAN de niveau 2 offre une sécurité moindre que le VLAN par port de par la possibilité de
spoofer l'adresse MAC.
Les VLANs de niveau 3 permettent de regrouper plusieurs machines suivant le sous-réseau auquel
elles appartiennent. La mise en place de VLAN de niveau 3 est conditionnée par l'utilisation d'un
protocole routable (IP, autres protocoles propriétaires ...).
L'attribution des VLANs se fait de manière automatique en décapsulant le paquet jusqu'à l'adresse
source. Cette adresse va déterminer à quel VLAN appartient la machine.
Avantage :
L'avantage du VLAN niveau 3 est qu'il permet une affectation automatique à un VLAN suivant une
adresse IP. Par conséquent, il suffit de configurer les clients pour joindre les groupes souhaités. Il
est aussi possible de séparer les protocoles par VLAN.
Inconvénients :
• Les VLANs de niveau 3 souffrent de lenteur par rapport aux VLANs de niveau 1 et 2. En
effet, le switch est obligé de décapsuler le paquet jusqu'à l'adresse IP pour pouvoir détecter à
quel VLAN il appartient. Il faut donc des équipements plus coûteux (car ils doivent pouvoir
décapsuler le niveau 3) pour une performance moindre.
• La sécurité est beaucoup plus faible par rapport aux VLANs de niveau 1 et 2. En effet,
l'analyse de l'adresse IP rend le spoofing IP possible. Or le spoofing IP est beaucoup plus
simple à réaliser que le spoofing MAC.
• Les VLANs de niveau 3 sont restreints par l'utilisation d'un protocole de routage pour avoir
l'identifiant niveau 3, et ainsi se joindre au VLAN correspondant.
Toutes les machines de Vivetic se trouvent dans le même domaine de diffusion, dans la même plage
d'adresse IP. La passerelle de sortie vers l'extérieur est un cluster WatchGuard XTM-810.
WatchGuard est une solution de sécurité tout-en-un à prix abordable pour les réseaux et les
contenus afin d'offrir aux entreprises une protection en profondeur lors de leurs activités. Il
implémente à la fois un pare-feu, un VPN et des services de sécurité pour protéger les réseaux
contre les spams, les virus, les logiciels malveillants et les intrusions.
Toutes les communications vers l'extérieur passent par WatchGuard. Une politique de filtrage y est
implémentée : filtrage par adresse IP source/destination, liste noire des sites interdits, maîtrise des
applications web autorisées…
WatchGuard est un point unique de défaillance.
Un point unique de défaillance, ou en anglais SPOF pour Single Point of Failure, est un élément
d'un système informatique dont le reste du système est dépendant et dont la panne entraîne l'arrêt
complet du système.
Les commutateurs utilisés dans l'entreprise sont des switches HP 1810. Ce sont des switches
manage-ables supportant le Fast Ethernet et le Gigabit Ethernet. Le modèle est proposé en 8 ports,
24 ports et 48 ports. Ceux de Vivetic ont 48 ports. Ci-dessous la liste des fonctionnalités proposées
qui influent sur le choix de la solution :
• Port mirroring,
L’architecture proposée ci-dessus ne tient compte que de la taille du parc actuel. Toute extension
entraînant un dépassement de la plage d’IP prévue fera l’objet d’une révision. Elle décrit de façon
synthétique la segmentation des IP utilisateurs en plusieurs VLANs, sans forcément décrire ou
refléter la topologie physique finale et les mesures de sécurisation adoptées (redondance…).
Le réseau actuel sera subdivisé selon les pôles d’activités (SMS, Voix IP, on-line, back-office,
serveurs, presse…). Chaque VLAN utilisateur ne pourra communiquer qu’avec le VLAN des
serveurs. Ces échanges vont donc se limiter aux services de partage de fichiers, aux FTP, aux
applications web, aux accès aux bases de données, à la messagerie électronique, à la résolution de
nom et à l’authentification LDAP. Le cluster Watchguard (également dans le VLAN des serveurs)
constitue le point de sortie unique vers internet.
• Le réseau d'accès : c'est la bordure du réseau, c'est ici que sont connectées les différentes
ressources réseau comme les postes de travail, les imprimantes, … Les ressources courantes
sont mises à disposition à ce niveau. Les requêtes vers toute autre ressource sont envoyées
vers le réseau de distribution.
• Le réseau de distribution : c'est l'interface entre le réseau cœur et le réseau d'accès, il a pour
fonction de router les paquets, filtrer les paquets, fournir l'accès au réseau étendu / réseau
cœur. Le réseau de distribution est le point de convergence des switch d'accès, c'est donc ici
que sont implémentées la plupart des politiques du réseau.
Pour la segmentation du réseau, le choix du niveau de VLAN à utiliser est en lien avec les
possibilités des switches à disposition. Les switches HP 1810 ne supportent que le VLAN par port.
L'utilisation des VLANs par port est contraignant en cas de déplacements très fréquents mais offre
l'avantage d'être facile à configurer, car ne requérant aucune information venant des postes
connectés, et d'être le plus sécurisé par rapport aux deux autres niveaux de VLANs (par adresse
MAC et par protocole). C'est donc la technique du VLAN par port qui a été choisie.
Le nombre de VLANs à créer est aussi un paramètre à prendre en compte. Plus y a des VLANs
créés, plus il y a de VLANs à administrer. Après concertation avec le responsable du département
Réseaux et Systèmes, le réseau sera sectionné en six VLANs.
Sur le choix des matériels à utiliser, la solution sera d'abord testée en production pendant un certain
temps. Une métrologie sera faite dessus, en utilisant les équipements déjà à disposition. Cela
permettra de calibrer la solution et d'avoir une idée précise de la configuration matérielle à utiliser.
Cette phase de métrologie peut potentiellement modifier les considérations énoncées ici.
Deux autres aspects importants dans le choix de la solution sont les répercussions budgétaires et en
ressources humaines :
• une solution peut être idéale techniquement parlant, mais si l'entreprise ne peut pas investir
dedans, elle ne pourra pas être déployée,
• une solution peut être idéale techniquement parlant, mais si son utilisation requiert beaucoup
trop de travail supplémentaire aux administrateurs, elle pourrait être plus une charge qu'autre
chose une fois déployée.
Le tableau suivant présente les différentes solutions que j'ai proposé. Celle qui a été retenue est la
solution Linux dans un premier temps d'abord, afin de la calibrer et de voir réellement ses
répercussions tant sur le plan technique que sur le plan ressources humaines. A l'issue de cette
première phase, sera décidé s'il faut des équipements plus adaptés (comme des équipements CISCO,
Juniper ou autres) et/ou s'il faudra, entre autres, embaucher une ressource humaine supplémentaire
pour la gestion du réseau.
En tant que tel, son premier avantage est de fournir des simulations plus proches de la réalité. Une
simulation marchant sur GNS3 a de fortes chances de marcher sans trop de problèmes inattendus en
implémentation physique.
Son deuxième avantage est sa souplesse et sa richesse. GNS3 permet d'utiliser un large éventail de
matériel sur lesquels on peut installer les images appropriées. Cela va des routeurs CISCO aux
routeurs Juniper, en passant par les traditionnelles machines x86-64. La version 0.8 de GNS3
permet l'utilisation de machines virtuelles créées sous Virtualbox et les simulations faites avec
peuvent être intégrées à un environnement physique existant !
Pour toutes toutes ces raisons, j'ai choisi GNS3 pour produire une preuve de concept de la solution
que j'ai proposée.
Une preuve de concept, ou en anglais proof of concept, est une réalisation courte ou incomplète
d'une idée pour démontrer sa faisabilité. Dans le cas présent, il s'agit de créer une simulation de la
solution pour montrer qu'elle marchera.
Architecture simulée
La figure 3 « Simulation GNS3 de la solution Linux » présente l'architecture que j'ai simulé sous
GNS3.
2 Cependant nous continuerons à utiliser les termes « simulation » et « simulateur » pour plus d'aisance.
Contraintes :
• Les machines du centre de contact (V50) et celles du centre SMS (V30) ne doivent pas
pouvoir se communiquer entre eux,
Internet (ou tout réseau extérieur) est ici modélisé par un réseau privé non défini dans le LAN de
Vivetic ne contenant qu'un seul hôte d'adresse 172.20.1.101. Pour les besoins de la simulation, le
routeur par défaut de ext01 est aussi WatchGuard pour qu'il puisse retourner les paquets. En
implémentation réelle, les machines et routeurs d'internet sont déjà configurés et ne relèvent pas de
notre responsabilité.
Le routeur Linux (ulr) doit se trouver dans chacun de ces VLAN et doit posséder une adresse dans
chacune de ces plages d'adresses : ulr se trouve donc dans V10, V30, V50 avec comme adresse
respective 192.168.10.254, 10.10.3.254 et 10.10.5.254.
Le modèle de switch générique proposé par GNS3 ne supportant pas le VLAN-tagging, il a fallu
connecter ulr à SW1 avec trois câbles différents, un pour chaque VLAN. Le switch HP 1810 qui
sera utilisé supporte cette fonctionnalité : en implémentation réelle, il n'y aurait qu'un seul lien trunk
dot1q au lieu de 3 liens access. Dans ce cas, en plus d'activer le protocole dot1q sur le switch, il
faudra aussi le faire sur le routeur Linux.
• Table de routage
• Configuration du pare-feu
Test de la simulation
Pour vérifier le bon fonctionnement de la simulation, j'ai conduit trois tests de base depuis les postes
clients : le test de promiscuité physique, le test des règles de transferts au niveau du routeur, le test
de connectivité externe.
Ce test permet de vérifier que les VLANs ont bien été définis c'est-à-dire que les ports ont bien été
assignés et que donc que le réseau a bien été sectionné physiquement.
Pour cela, j'ai utilisé l'outil arp-scan qui permet de scanner la liste des machines se trouvant sur le
même réseau physique. Arp-scan agit au niveau physique en utilisant les adresses MAC. Ainsi,
mêmes des machines n'appartenant pas au même réseau logique, c'est-à-dire ne se trouvant pas sur
la même plage d'adresse IP, répondront au scan.
Ce test permet de vérifier que la politique de transfert de paquets du routeur est correcte, c'est-à-dire
de vérifier que les communications entre les différents VLANs sont bien configurées.
Par exemple, pour le cas de la simulation, les machines de V50 (centre de contact) peuvent
communiquer avec celles de V10 (serveurs) mais pas avec celles de V30 (centre SMS).
Nous voyons que WatchGuard est accessible alors que guest03 du centre SMS ne l'est pas.Scan
ARP depuis guest01 (V50) :
Seuls guest02 et ulr, qui sont les seuls à appartenir au même VLAN V50 ont répondu.
Illustration 8: Test des règles de transferts au niveau du routeur grâce à l'outil ping
Ce test permet de vérifier que les différents VLANs peuvent accéder l'extérieur du réseau local,
notamment internet, et surtout de vérifier le chemin emprunté pour cela. En effet, toute sortie vers
l'extérieur doit d'abord passer par le routeur Linux, puis par WatchGuard. Quand la réponse revient,
le chemin inverse est suivi.
Illustration 9: Test de la connectivité vers l'extérieur grâce aux outils ping et traceroute
Le ping vers l'extérieur passe. Les paquets passent d'abord par le routeur Linux, puis par
WatchGuard, avant d'arriver vers l'extérieur.
La haute disponibilité de son infrastructure informatique est un enjeu majeur pour Vivetic afin que
ce dernier puisse honorer ses différents engagements, assurer la continuité de ses prestations et
garder son image auprès de ses clients.
Plusieurs techniques sont utilisées pour rendre un système hautement disponible, à savoir :
• l'existence d'un mode dégradé, c'est-à-dire un mode de fonctionnement dans lequel les
services « vitaux » peuvent toujours être garantis même si les ressources habituellement
utilisées manquent,
La nouvelle architecture informatique de Vivetic qui prendra place doit être hautement disponible.
Elle doit donc observer les techniques ci-dessus.
Mon travail sur ce plan consistait à assurer la haute disponibilité du routeur Linux utilisé pour les
communications interVLAN.
En effet, le routeur Linux est le point unique de défaillance de la nouvelle architecture. Si le routeur
Linux tombe en panne, non seulement les postes clients ne pourront plus se connecter vers
l'extérieur du réseau local (internet notamment), mais toutes les communications internes seront
également coupées car les machines se retrouveront alors dans différents VLANs qui ne peuvent
plus communiquer entre eux.
La solution que j'ai proposé est de rendre le routeur Linux redondant en utilisant un cluster de
routeur. De cette façon, même si une machine du cluster tombe en panne, les autres machines du
cluster continuent d'assurer le routage.
• HSRP pour Hot Standby Router Protocol : propriétaire CISCO, créé en 1994, permet le
basculement Actif/Veille,
• GLBP pour Gateway Load Balancing Protocol : propriétaire CISCO, créé en 2005, permet le
basculement Actif/Actif pour faire du partage de charge,
• VRRP pour Virtual Router Redundancy Protocol : créé par l’IETF en 1999, standardisé donc
compatible entre différents équipements, identique à HSRP3.
Un cluster est dit en mode basculement Actif/Veille, ou en anglais Active/Standby failover, quand
seul un nœud du cluster est actif et les autres restent en veille jusqu'à ce que le nœud actif tombe en
panne. Il est dit en mode basculement Actif/Actif, ou en anglais Active/Active failover, quand les
nœuds du cluster sont tous actifs et que le trafic à destination d'un nœud en panne est juste redirigé
vers un nœud fonctionnel.
Comme la solution utilisée est une solution Linux et non CISCO (au moins dans un premier temps),
nous ne nous intéresserons dans la suite qu'au protocole VRRP ainsi qu'à son implémentation dans
un logiciel appelé Keepalived.
Le protocole VRRP
VRRP pour Virtual Routeur Redundancy Protocol, ou en français Protocole de Redondance de
Routeur Virtuel, est un standard de l'IETF permettant de rendre redondant la passerelle par défaut
des hôtes d'un réseau. VRRP est décrit dans la RFC 2338.
VRRP utilise la notion de routeur virtuel, auquel est associée une adresse IP virtuelle ainsi qu'une
adresse MAC virtuelle. Parmi un groupe de routeurs participant à VRRP dans un réseau, le
protocole va élire un maître, qui va répondre aux requêtes ARP pour l'adresse IP virtuelle, ainsi
qu'un ou plusieurs routeurs de secours, qui reprendront l'adresse IP virtuelle en cas de défaillance du
routeur maître.
Chaque routeur qui participe au groupe VRRP se voit définir une priorité allant de 1 à 255 (du
routeur le moins prioritaire au routeur maître). L'élection va déterminer un routeur maître qui
annoncera alors une priorité de 255.
Les messages VRRP sont échangés à intervalle régulier sur l'adresse multicast 224.0.0.18. Le
3Toutefois VRRP utilise des timers plus petit par défaut le rendant plus rapide
champ « protocole » de l'entête IP est positionné à 112. Les routeurs backup sont attentifs à ces
messages : ils vérifient que la priorité du maître est toujours supérieure à la leur, ainsi que l'arrivée
régulière des messages. À défaut de message d'un autre routeur maître dans le sous-réseau (après
3,6 s par défaut), un routeur backup se proclamera maître.
• d'assurer l'existence et la migration de l'adresse IP virtualisée (VIP pour Virtualizaed IP) d'un
service fiabilisé : c'est le module de résistance aux pannes qui est une implémentation du
protocole VRRP.
D'autres solutions comme le paquet vrrpd auraient également pu être utilisées. Cependant, aucune
n'est aussi riche que Keepalived en termes de fonctionnalités, à ne citer que la notification par email
en cas de panne, fonctionnalité essentielle pour le monitoring. De plus, Keepalived peut également
utiliser le module IPVS pour la programmation du noyau afin de faire de la répartition de charge.
Cette fonctionnalité peut être utile plus tard si la métrologie qui sera faite indique qu'il faut faire de
la répartition de charge selon les résultats mesurés.
Enfin, Keepalived est une des rares solutions Linux de haute disponibilité et de répartition de charge
qui possède une documentation assez complète.
Pour toutes ces raisons, j'ai choisi Keepalived pour créer le cluster de routeurs Linux.
Une configuration de base de Keepalived pour rendre un routeur Linux redondant en utilisant le
module VRRP est présentée en annexe.
Illustration 11: Laboratoire de test avec deux clients et un cluster de deux routeurs Linux
• Service de pointage,
• Service de messagerie,
• Service de VoIP,
Client pilote
Afin de tester le bon fonctionnement de la nouvelle architecture une fois déployée en production,
nous avons créé un client sur lequel on installait tous les logiciels qui étaient utilisés sur les
différents ateliers. Cela incluait les clients de messagerie, le logiciel de pointage, les softphones, …
Comme chaque logiciel doit être paramétré avec des configurations particulières et nécessite d'avoir
accès à certaines ressources pour fonctionner avec le système informatique de Vivetic, l'installation
des différents logiciels a été fait principalement par un collègue informaticien de maintenance.
Mon travail consistait à conduire le débogage une fois l'installation faite.
L'origine de la plupart des problèmes rencontrés se trouvaient au niveau des serveurs qui n'étaient
pas encore configurés pour fonctionner avec la nouvelle architecture. Les principales modifications
apportées aux différents serveurs étaient l'ajout de la route vers le VLAN du laboratoire de test et le
réglage des autorisations.
La route vers le sous-réseau du VLAN doit pointer vers le routeur Linux. C'est ainsi que par le
simple ajout de cette route a pu fonctionner avec le laboratoire le serveur LDAP pour
l'authentification, le serveur de messagerie, le serveur de fichier et la plupart des serveurs utilisés.
Les autorisations d'accès devaient aussi être réglées sur certains serveurs. Ce fût le cas par exemple
du serveur de base de données, un serveur PostgreSQL, qui ne répond qu'à des machines
appartenant à des réseaux de confiance préalablement définis. Il fallait donc ajouter le sous-réseau
du VLAN du laboratoire à cette liste.
Le problème rencontré fût que, depuis le laboratoire de test, avec le serveur WINS déjà précisé, la
résolution des noms NetBIOS n'était pas correcte. Le plus déroutant était que la résolution de noms
était fonctionnelle mais seulement partiellement. Certains noms NetBIOS étaient résolus, d'autres
non. Or, on arrivait bien à joindre le serveur WINS ! En faisant les résolutions depuis un poste client
en production (et donc depuis le VLAN par défaut), tous les noms NetBIOS étaient résolus. Or,
aucun serveur WINS n'est spécifié sur le poste client en production en question !
Pour déterminer l'origine du problème, j'ai utilisé le logiciel de capture de paquets Wireshark. J'ai
ainsi pu déterminer le mécanisme de résolution de noms sous Windows6 :
1. Une tentative de résolution du nom via le serveur DNS spécifié est d'abord effectuée. Si elle
aboutit, la résolution se termine avec succès.
2. Si elle n'aboutit pas, une tentative de résolution du nom via le serveur WINS spécifié est
effectuée. Si elle aboutit, la résolution se termine avec succès.
3. Si elle n'aboutit pas, une tentative de résolution du nom en envoyant une requête en
broadcast est effectuée. Si une réponse est reçue, c'est à dire si le possesseur du nom
NetBIOS existe dans le même domaine de diffusion et qu'il a répondu, la résolution se
termine avec succès.
Le protocole utilisé pour la résolution des noms NetBIOS est le protocole NBNS pour NetBIOS
Naming System. Quand une machine sous Windows joint un réseau, elle envoie en broadcast une
requête NBNS d'enregistrement. Tout serveur WINS se trouvant dans le même domaine de diffusion
reçoit la requête et met à jour sa table de correspondance nom NetBIOS/adresse IP.
Cependant, les machines sous Linux modifiées pour supporter le protocole SMB ne s'enregistrent
pas systématiquement quand elles arrivent sur un réseau. Elles ne sont donc pas connues des
serveurs WINS mais répondent aux requêtes NBNS qu'elles reçoivent. Ce sont ces machines Linux
que l’on n’arrivait pas à résoudre depuis le VLAN du laboratoire de test.
En effet, partant de l'algorithme de résolution ci-dessus, voici la suite des actions effectuées quand
5 Le protocole SMB, pour Server Message Block, est un protocole permettant le partage des ressources (fichiers et
imprimantes) sur des réseaux locaux avec des machines sous Windows.
6 Après avoir résolu le problème et en voulant prendre du recul dessus, j'ai découvert que le mécanisme de résolution
de noms sous Windows est en réalité un peu plus compliqué comme décrit ici :
http://www.itgeared.com/articles/1090-microsoft-windows-tcpip-netbios-and/
1. Une tentative de résolution du nom via le serveur DNS spécifié est d'abord effectuée. Elle
n'aboutit pas car les noms machines Linux ne sont pas enregistrés sur le DNS.
2. Une tentative de résolution du nom via le serveur WINS spécifié est effectuée. Elle n'aboutit
pas car les machines Linux n'envoient pas de requêtes NBNS d'enregistrement quand elles
arrivent sur un réseau.
3. Une tentative de résolution du nom en envoyant une requête en broadcast est effectuée. Le
possesseur du nom NetBIOS existe mais ne se trouve pas dans le même domaine de
diffusion. Le broadcast est envoyé dans le VLAN du laboratoire de test alors que le
possesseur du nom NetBIOS se trouve dans le VLAN par défaut : la requête n'arrive pas
vers le possesseur du nom NetBIOS, aucune réponse n'est donc reçue. La tentative n'aboutit
pas.
Pour résoudre le problème, on peut donc agir à plusieurs niveaux : au niveau du serveur DNS, au
niveau du serveur WINS, au niveau du domaine de diffusion.
Nous avons choisi d'ajouter les noms des machines Linux dans le serveur DNS et de configurer le
serveur WINS pour demander au serveur DNS de résoudre les noms qu'il n'arrive pas à résoudre.
Cela permet de centraliser les résolutions de noms au niveau du serveur DNS.
Mon travail consistait à diagnostiquer l'origine du problème et à fournir la solution à
implémenter. J'ai notamment fourni le squelette du fichier de configuration de bind9, à modifier
pour chaque nom de machine à ajouter.
en production dont je n'avais pas accès. Je lui ai reporté un compte-rendu écrit toutes les semaines
pour lui faire part de mes dernières avancées, en plus des échanges plus fréquents que j'ai fait avec
lui quand besoin était.
Afin de pouvoir valider la solution, j'ai présenté lors d'une réunion la nouvelle architecture à travers
le laboratoire de test au Directeur Technique, au Responsable Réseaux et Systèmes, au Responsable
LAN et à quelques autres Informaticiens de Maintenance. Ont été discutés pendant cette réunion
des points essentiels de la nouvelle architecture notamment l'utilisation de la solution Linux dans un
premier temps pour mesurer ses répercussions sur le plan technique, budgétaire et ressources
humaines.
Finalement, j'ai apporté de petites aides ponctuelles aux Informaticiens de Maintenance quand ceux-
ci me consultaient pour des questions techniques. Je les ai également suivi au début dans leur travail
quand ils dépannaient des machines dans les différents ateliers afin que je puisse voir concrètement
comment le système fonctionnait.
Ce stage a été pour moi l'occasion de retourner à nouveau dans mon pays natal après l'avoir quitté
pour presque deux ans. Ce fût un immense plaisir pour moi que de me retrouver à nouveau avec les
miens et mon intégration avec les collègues s'était fait très naturellement. La différence du train de
vie entre celui de La Réunion et celui de Madagascar est très important ! Cependant, ayant vécu
quasiment tout ma vie ici à Madagascar, ma réadaptation a été très rapide.
Conclusion
Je tiens avant tout à remercier encore une fois l'équipe du département Réseaux et Systèmes de
Vivetic pour son accueil chaleureux et pour sa grande disponibilité au moindre blocage sans quoi la
première étape importante de ce grand projet qui est l'intégration d'un laboratoire de test
fonctionnant sous la nouvelle architecture avec le réseau en production n'aurait pu être achevée.
L'étape importante suivante est la métrologie (tant en termes de ressources matérielles que
humaines), le calibrage et la sécurisation de la solution afin de pouvoir la déployer en production.
Comme je resterai encore quelques temps chez Vivetic, considérant les avancées actuelles, je peux
affirmer avec une assez grande assurance que cette étape sera également achevée avec succès.
Le travail que j'ai réalisé sera réellement utilisé en production. Le réseau actuel sera migré petit à
petit vers la nouvelle architecture, ce qui prendra un peu de temps pour laisser la solution mûrir. Si
les résultats obtenus sont favorables, l'ensemble du réseau de Vivetic est prévu être totalement
migré vers le début de l'année prochaine.
J'ai désormais le sentiment d'avoir franchi un cap important après les six ans que j'ai consacré aux
Nouvelles Technologies de l'Information et de la Communication. A toutes les personnes qui m'ont
permis d'en arriver là, merci encore !
Bibliographie
• Wikipédia : http://fr.wikipedia.org
• Ubuntu-fr : http://doc.ubuntu-fr.org
http://www-igm.univ-mlv.fr/~dr/XPOSE2006/SURZUR-DEFRANCE/vlan.html
Annexes
Dans la partie VRRP de Keepalived, Alexandre CASSEN ne s'est pas limité a la seule
implémentation de la RFC mais il a développé des « facilités » permettant d'interagir en fonction
d'événements du protocole : ajouter/supprimer des routes IP en plus de la VIP, exécuter des
« scripts maisons » sur changement d'état VRRP , ...
vrrp_instance lb1 {
virtual_router_id 1
interface eth0
priority 100
virtual_ipaddress {
10.0.0.7/24
}
}
Une fois le service keepalived lancé, on peut vérifier l'ajout d'une nouvelle adresse à l'interface
spécifié dans le fichier de configuration de Keepalived.
Un domaine ou sous-domaine particulier dont l'administration a été déléguée à une entité unique est
appelé zone DNS. Dans bind9, pour gérer une zone sous sa propre autorité, il faut déclarer la zone
avec la directive zone et écrire le fichier de zone correspondant.
Pour faire entrer les noms de machines, qui sont du type machine1 ou machine2, c'est-à-dire qui
n'ont pas de TLD, il faudrait soit modifier la zone racine '.' soit créer une zone par nom de machine.
Comme modifier la zone racine est assez critique et que le nombre de noms de machine à entrer
n'était pas trop important, c'est la deuxième solution qui a été choisie.
• Déclaration de la zone :
zone "machine1" {
type master;
file "/etc/bind/db.machine1";
};
• Fichier de zone :
$TTL 604800
@ IN SOA machine1. rrs.vivetic.mg. (
20040121 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 192.198.13.21
Ces figures :
• ont été fournies par Vivetic ou
• ont été créées par moi à partir du simulateur GNS3 ou
• ont été crées par moi en utilisant des images sous licence libre venant de thenounproject.com .