5.2 Architecture générale de la plate-forme - Lip6

Plateforme spécialité
réseau (PFRES)
Encadrant : O. Fourmaux
Etudiants : A. Evain, D. Obreja,
N. Panhaleux, G. Teste
Table des matières 1 Cahier des charges 2
1.1 Introduction 2
1.2 Finalité 2
1.3 Homogénéité 2
1.4 Analyse 2
1.5 Administration 2
1.6 Scénarios 3
1.7 Validation/Montée en charge 3 2 Plan de développement 4
2.1 Analyse et remise en état du matériel 4
2.2 Documentation 4
2.3 Analyse et conception 4
2.4 Câblage, installation des OS et configuration des équipements réseaux
4
2.5 Configuration des AS 5
2.6 Test des scénarios et de montée en charge 5
2.7 Diagramme de Gantt 5 3 Contexte technologique 7 4 Analyse 9
4.1 Liste du matériel disponible et des leurs principales fonctionnalités
9
4.2 Choix des scénarios 12
4.3 Une plate-forme pédagogique 14 5 Conception 15
5.1 Introduction 15
5.2 Architecture générale de la plate-forme 15
5.3 Architecture de chaque AS 15
5.4 Scénarios proposés 23
5.5 Suivi et documentation 23 6 Compte-rendu du projet 25
6.1 Configuration globale de la plateforme 25
6.2 Configuration des AS 26 7 Annexes 37
7.1 Wiki/Trac Documentation 37
7.2 Possibilités d'évolutions 37 Cahier des charges
1 Introduction L'explosion de la bulle internet ces dernières années a forcé une évolution
croissante des protocoles et des architectures mis en ?uvre dans les
différentes parties de l'Internet et les différents types de réseaux mis en
place dans les entreprises, les établissements publiques et autres. Il est
donc crucial de mettre en ?uvre des solutions adaptées, tant au niveau
matériel que protocolaire, pour répondre aux nombreuses exigences des
divers acteurs et utilisateurs des réseaux. 2 Finalité Une fois complétée, la plateforme représentera une version simplifiée de
l'architecture réseau de l'Internet.
Chaque rack représente un système autonome (AS) avec ses problématiques de
sécurité, de routage, de qualité de service, ...
La plateforme sera divisée en deux catégories d'AS :
1. Les racks extérieurs représentant des réseaux d'entreprise connectés à
l'Internet par des ISP.
2. Les racks intérieurs représentant les réseaux c?urs d'ISP. 3 Homogénéité L'intérêt de la plateforme est de pouvoir utiliser du matériel hétérogène
afin de simuler au mieux le monde réel de l'Internet.
Les systèmes installés sur les différentes machines seront donc également
différents entre les AS. A l'intérieur d'un AS, on mettra en place un
ensemble homogène de systèmes d'exploitation. 4 Analyse Le trafic généré devant être analysé, une sonde (type tcpdump ou wireshark)
sera présente dans chaque AS. Le trafic dans les commutateurs pourra être
dupliqué sur un VLAN dédié afin d'être capturé par la sonde. 5 Administration Chaque machine devra être accessible à distance et devra être en mesure
d'accéder à Internet pour les mises à jour ou l'installation de nouveaux
paquets. Le statut de chaque machine pourra ainsi être connu en temps réel
par les administrateurs. L'accès distant se fera à l'aide de la passerelle
gate-net.rsr.lip6.fr (via sphinx.lip6.fr), les requêtes HTTP se feront via
un proxy local sur la passerelle. 6 Scénarios La plateforme réseau fera la démonstration de cinq scénarios reflétant les
possibilités techniques offertes par le matériel et les systèmes.
1. Sécurité
. Firewalls
o Matériels
. DMZ : architecture en Y avec 2 firewalls matériels. La
DMZ hébergera 3 services : mail, DNS et serveur web.
o Logiciels
. Filtrage classique
. Certificats : accès SSL sur le serveur web ou mail.
. Tunnels sécurisés
2. VoIP et QoS
. QoS (DiffServ)
. SIP (téléphonie IP)
3. Routage et topologie
. Protocoles de routage (OSPF, BGP)
. VLANs
. NAT
4. IPv6
5. Administration et Supervision
. Nagios : état du réseau
. Cacti : graphique d'utilisation du réseau et de machines 7 Validation/Montée en charge Lors de l'installation de la plateforme, des machines génératrices de
trafic seront également installées afin de valider les performances de la
plateforme. Ces machines permettront aussi de valider la pertinence et
l'efficacité de la QoS mise en place pour la VoIP. Plan de développement
1 Analyse et remise en état du matériel Durée : 2 semaines.
Cette phase correspond à la découverte, le listing et les tests de la bonne
marche des équipements mis à notre disposition.
Le listing nous permet de prendre connaissance de tout le matériel à notre
disposition et nous permet de nous faire une première idée de ce qu'il est
techniquement possible de faire avec. Cela va de pair avec la vérification
du bon fonctionnement (ou de la remise en état dans le cas contraire) de
tout le matériel.
Cette partie est réalisée en collaboration des 4 participants. 2 Documentation Durée : toute la durée du projet.
Cette phase, de par le fait qu'elle est rythmée par la progression du
projet, s'étend sur toute sa durée.
La documentation est primordiale pour comprendre le fonctionnement des
différents appareils et avoir une idée précise sur les fonctionnalités à
notre disposition pour la mise en place de l'architecture retenue et des
différents scénarios retenus.
Cette partie est réalisée en collaboration par les 4 participants. 3 Analyse et conception Durée : 4 semaines.
Cette phase correspond à la réflexion sur les différents aspects de la mise
en place de l'architecture et des protocoles utilisés au travers des
scénarios.
L'analyse du matériel, des besoins spécifiques à nos scénarios et la
conception d'une architecture en adéquation avec l'objectif fixé est
primordial pour obtenir un résultat cohérent avec le contexte technologique
actuel et les différents paramètres retenus pour les scénarios.
Cette partie est réalisée en collaboration des 4 participants pour
l'architecture et la topologie globale de la plate-forme et
individuellement pour chaque AS:
. A. Evain: AS1 (Réseau entreprise 1, VLAN d'administration, ...)
. D. Obreja: AS2 (Réseau c?ur 1, ...)
. G. Teste: AS3 (Réseau c?ur 2, ...)
. N. Panhaleux: AS4 (Réseau entreprise 2, DMZ, Multi homing, ...) 4 Câblage, installation des OS et configuration des équipements réseaux Durée : 2 semaines.
Cette phase représente la mise en application de la réflexion sur la plate-
forme entreprise les semaines précédentes.
Le câblage, l'installation et la configuration primaire des équipements
réseaux sont l'application directe de la topologie retenue dans la partie
précédente, avec quelques éventuels ajustements si des problèmes sont
rencontrés. Tout ceci est fait de façon généralisée sur tous les AS afin
d'obtenir une configuration primaire de la plate-forme.
Cette partie est réalisée en collaboration des 4 participants. 5 Configuration des AS Durée : 2 semaines.
Cette phase correspond à la configuration interne à chaque AS pour un bon
fonctionnement individuel et intégré au sein de la plate-forme.
La configuration des AS est faite de façon individuelle afin d'obtenir un
résultat équivalent à la représentation faite dans la conception et
permettre la mise en place des divers protocoles nécessaires au
fonctionnement de la plate-forme et nécessaire pour les tests des
scénarios.
Cette partie est réalisée individuellement sur les AS attribués à chacun
des participants (liste ci-dessus). 6 Test des scénarios et de montée en charge Durée : tout au long du projet, après configuration.
Cette phase correspond aux différents tests correspondant aux scénarios
préalablement choisis en fonction du contexte technologique actuel et
réalisé sur la plate-forme.
Le test des s'effectue après chaque configuration d'un scénario. Il
commence par un test local puis un test avec un voisin direct avant de se
généraliser par un test sur la plateforme entière. On procède de la même
manière pour le test de montée en charge préalable qui validera la
topologie retenue.
Cette partie est réalisée en collaboration par les 4 participants. 7 Diagramme de Gantt
[pic]
Contexte technologique L'Internet peut être vu comme une gigantesque interconnexion de systèmes
autonomes. Un système autonome (Autonomous System - AS - en anglais) est
défini comme étant un ensemble de réseaux IP dont la politique de routage
interne est cohérente et qui sont, en général, sous le contrôle d'une même
entité administrative. Le réseau interne d'une entreprise ainsi que le
réseau d'un fournisseur d'accès à Internet peuvent être des exemples de
systèmes autonomes. Pour acheminer des données vers tout point de l'Internet, il faut des
mécanismes pour les faire transiter de manière cohérente entre les AS.
Cependant, les accords économiques qui existent entre les différentes
entités administratives font que l'on n'utilise pas forcément le chemin le
plus court entre deux points. Les mécanismes de routage inter-AS doivent
prendre en compte ces décisions politiques de routage. A l'intérieur d'un AS, ces facteurs économiques n'affectent pas le routage
des données. Il est possible donc de privilégier une politique du plus
court chemin. Le but étant de faire transiter des données le plus
rapidement possible avec un impact minimal sur la qualité du service que
l'on souhaite assurer.
L'Internet étant accessible par des personnes dont les intentions sont fort
peu louables, les AS ont également un fort besoin de