TP sysres IMA2a5 2020/2021 G4 : Différence entre versions

Version du 31 octobre 2020 à 18:00

Installation de l'architecture matérielle

Dans un premier temps, nous nous sommes occupés de l'aspect Hardware du projet. Le but étant de connecter entre eux les différents éléments suivants : Routeur 6509, Serveur de virtualisation R540, commutateur 3560-E & ISR 4331. Pour cela, nous nous sommes servis de la fibre mise à dispostion. En effet, le routeur 6509, composé des deux cartes de supervision doit être connecté au R540, au 3560-E ainsi qu'à l'ISR 4331 via une liaison fibre. Initialement, nous comptions connecter chaque carte de supervision aux autres éléments grâce à la fibre présente dans les salles. Cela aurait donné le schéma ci-dessous :

Schéma mis au propre par Alexandre GLAINE après avoir fait un brouillon au tableau lors de la réunion d'équipe

Ainsi, grâce à cette configuration, il y aurait eu de la redondance entre les cartes de supervision et les autres éléments. De ce fait, si une des cartes de supervision était défectueuse, la seconde pourrait toujours communiquer avec le reste du système. Cependant, afin de se partager le matériel avec la seconde classe, nous ne pouvions utiliser que la moitié de la fibre mise à disposition. De ce fait, nous avons abouti à la configuration suivante :

Schéma modifié par Alexandre GLAINE après que Crispin DJAMBA et moi-même nous sommes rendus compte que nous ne pouvions utiliser que la moitié de la fibre.

Ainsi, les connexions fibres sont partagées entre les deux cartes de supervision. Ces dernières sont connectées entre elles via le fond de panier. De cette manière, nous aboutissons à la connexion suivante :

Ici, le R540 et le 3560-E sont connectés à la seconde carte de supervision. La première, quant à elle, est directement connectée à l'ISR 4331 et au réseau Polytech. Pour vérifier que notre système est bien connecté au réseau Polytech, nous sommes descendu dans la salle ----- et avons vérifié la bonne connexion en envoyant un signal lumineux à travers la fibre. Grâce à cela, nous avons également décelé des erreurs comme une inversion du Tx et du Rx, que nous avons immédiatement corrigées.

Les connexions commutateur3560-E / l'ISR4331 et commutateur3560-E / R540 ont été faites grâce à des câbles RJ45. L'ISR 4331 a également été connecté au réseau SDSL directement dans la salle E304.

Ainsi, cette configuration matérielle permet d'avoir une connexion entre tous les éléments tout en gardant à l'esprit l'aspect de sécurité. En effet, le routeur 6509 n'est pas placée dans la même salle que le Serveur de virtualisation R540, le commutateur 3560-E et l'ISR 4331. De ce fait, si un aléa comme un incendie se déclare dans l'une des salles, le reste du système reste intacte.

Mise en place des machines virtuelles

Création

Chacun a ensuite créé sa machine virtuelle. Lionel SAWICZ et moi avons également créé celles de Samuel CRAMETTE et Nathan COULON car ils étaient occupés sur une autre tâche. Pour cela, nous nous sommes connectés sur le serveur capbreton en ssh. Ensuite, nous avons pu créer nos machines en les paramétrant grâce à la commande suivante :

xen-create-image --hostname=Falcon --ip=193.48.57.167 --gateway=193.48.57.163 --dir=/usr/local/xen --dist=beowulf

On peut vérifier l'avancement de l'installation grâce à :

tail -f /var/log/xen-tools/Falcon.cfg

Démarrage

Pour lancer ma machine virtuelle, j'ai utilisé la commande :

xen create /etc/xen/Falcon.cfg
xen console Falcon

Configuration

Le mot de passe par défaut étant vraiment compliqué, j'ai pu le changer avec passwd. Cependant, il m'était impossible de me connecter sur ma machine virtuelle. C'est pourquoi, j'ai également dû effectuer des changements dans les fichiers "/etc/ssh/ssh_config" (pour autoriser la connexion en ssh) et "/etc/network/interfaces" (pour changer l'adresse de la gateway). Il ne me restait plus qu'à redémarrer le service :

ifdown eth0
ifup eth0
service ssh restart

Utilisation

Je peux maintenant avoir accès directement à ma machine virtuelle en tapant la commande :

ssh root@193.48.57.167

Configuration IPV6

Routage de site IPV6

Il fallait également configurer les routeurs de manière à ce que nos machines puissent se construire des adresses IPV6. Pour ma part, je me suis occupé du routeur 6509E. Nous avons fixé le préfixe IPV6 de notre promotion à 2001:660:4401:60a0::/60. La configuration IPV6 pour l'un des trois VLAN s'est faite de la manière suivante :

sh run int vlan1

interface Vlan1
 ip address 10.6..0.1 255.255.255.0
 ipv6 address 2001:660:4401:60A1::/64 eui-64
 ipv6 enable
 ipv6 nd prefix 2001:660:4401:60A1::/64 1000 900
 ipv6 nd router-preference High
end

Je me suis préalablement assuré que le 6509E est en mode double pile IPV4/IPV6 avec :

sdm prefer dual-ipv4-and-ipv6 default

Ensuite, j'ai effectué la configuration globale grâce à la commande :

ipv6 unicast-routing

Interconnexion avec internet

Après avoir activé le protocole RIPV6 avec

ipv6 rip tpima5sc enable

J'ai cherché à interconnecter le routeur 6509E avec celui de Polytech en utilisant le protocolant activé précédemment de la manière suivante :

ipv6 router rip tpima5sc
 redistribute connected metric 1
 redistribute rip 1 metric 1
 redistribute static metric 1

Mise en place du serveur DNS

Pendant que mes autres camarades étaient penchés sur d'autres tâches, je me suis intéressé à la mise en place du serveur DNS avec Lena CHENU de manière à pouvoir leur transmettre mes recherches et leur faire gagner du temps.

Modification des fichiers de configuration

Dans un premier temps, j'ai acheté un nom de domaine, nommé "salsifis.site", via la plateforme gandi.net. Le but du serveur DNS est de traduire ce nom de domaine en adresse IP. Pour cela, j'ai commencé par inscire l'IP de la machine autorisée à communiquer avec mon serveur DNS en modifiant le fichier /etc/bind/named.conf.options de la manière suivante :

 options {
        directory "/var/cache/bind";
        forwarders {
               0.0.0.0;
        };
        dnssec-validation auto;
        listen-on-v6 { any; };
        allow-transfer { "allowed_to_transfer"; };
 };
 acl "allowed_to_transfer" {
   217.70.177.40/32;
 };

Ensuite, il a fallu définir une zone correspondant à mon domaine (salsifis.site). Pour cela, j'ai modifié cette fois-ci le fichier /etc/bind/named.conf.local comme présenté ci-dessous :

 zone "salsifis.site" {
 type master;
 file "/etc/bind/db.salsifis.site";
 };

L'étape suivante fut d'écrire le fichier de zone qui est le fichier de configuration du domaine. Ce fichier, nommé /etc/bind/db.salsifis.site, s'écrit donc :

 $TTL    3600
 @   IN      SOA     ns.salsifis.site. postmaster.salsifis.site. (
                       1        ; Version
                       1800     ; Refresh (30m)
                       600      ; Retry (10m)
                       3600     ; Expire (1h)
                       3600 )   ; Minimum TTL (1h)
     IN NS ns.salsifis.site.
     IN NS ns6.gandi.net.
 ns  IN A   193.48.57.167

Vérification et service Bind9

J'ai trouvé une commande sur internet qui m'a permis de déceler les erreurs de syntaxe dasn mon fichier. J'ai de ce fait utilisé la commande

 named-checkzone salsifis.site /etc/bind/db.salsifis.site

de manière à ne pas relancer le service bind9 avec des erreurs.

Une fois avoir tout corrigé, j'ai enfin pu lancer la commande

 service bind9 restart

Si le processus se déroule bien, la console nous affiche "ok".