IMA5 2018/2019 P31 : Supervision des serveurs de la plateforme informatique

De Wiki de Projets IMA
(Redirigé depuis IMA5 2018/2019 P31)

Sommaire


Présentation générale

L'objectif du projet est de réaliser un tableau de bord affichant l'état des serveurs physiques et virtuels de la plateforme informatique ainsi que de mettre en place un système de backup automatique.

Description

L'idée pour la réalisation du projet est de remonter l'état des machines physiques et virtuelles sur un serveur virtuel de supervision, serveur sur lequel on va trouver les applications web permettant la génération du tableau de bord. La gestion des tâches de sauvegarde des machines virtuelles se fera, quant à elle, sur le serveur de sauvegarde.

Objectifs

Le projet s'articule autour de ces deux principaux objectifs:

  • Créer un serveur de supervision fonctionnel et sécurisé permettant de visualiser les données des VMs et machines physique en temps réel.
  • Mettre en place un système d'alerte.
  • Mettre en place une solution pour la gestion automatique des sauvegardes des machines virtuelles.

Préparation du projet

Architecture en salle serveur

Cahier des charges

Le système doit rapporter les points suivants :

  • état de santé des machines physiques : température, état des disques, ...
  • occupation des machines physiques : utilisation CPU, utilisation espace disque, utilisation mémoire
  • état de santé des connexions réseau : réseau Renater, réseau ADSL, réseau SDSL
  • état de santé des machines virtuelles : temps d\'exécution de chaque machine virtuelle
  • occupation des machines virtuelles : utilisation disque et mémoire
  • état de certaines applications critiques :
    • date de validité des clefs DNSSEC
    • dates des dernières sauvegardes des machines virtuelles
  • vérification des certificats https de sites web.
  • affichage de la température en salle serveur

En plus de cela, un système de sauvegarde automatique

Choix techniques : matériel et logiciel

Pour la réalisation du serveur de supervision, mon choix s'est tourné vers une solution déjà existante: Nagios Core. En plus d'être facile à mettre en place, Nagios possède l'avantage de posséder les plugins nécessaire au monitoring des machines virtuelles Xen.

A cela, on peut aussi ajouter une communauté active mettant à disposition des plugins et addons sur la plateforme communautaire nagios exchange.

La surveillance des hôtes ainsi que des machines virtuelles sera assuré grâce à un applicatif nommé NRPE:

Schéma de fonctionnement de Nagios+NRPE - Source: https://assets.nagios.com/downloads/nagioscore/docs/nrpe/NRPE.pdf

Cet agent permet de faire remonter à notre serveurs serveurs de monitoring (ici notre serveur nagios) le résultat de scripts lancé directement sur les hôtes.

Liste des tâches à effectuer

  • Dans un premier temps, il sera nécessaire de réaliser une phase de test sur les machines projet en salle E306, L'idée sera de monitorer un PC depuis un autre PC.
  • La deuxième étape consistera à installer la machine virtuelle et à mettre en place le serveur de supervision affichant l'état des machines physiques et virtuelles ainsi que des réseaux (réseau Renater, réseau ADSL, réseau SDSL) et effectuant la vérification des certificats https.
  • La troisième partie du projet sera consacré l'automatisation des tâches de sauvegardes des VMs.
  • Une fois cela fait, il faudra se concentrer sur la vérification des clefs DNSSEC.
  • Il a prévu par la suite de mettre en place un système de surveillance de température en salle serveur.
  • Toute autre tâche priorisé par Mr Redon et/ou Mr Vantroys.

Calendrier prévisionnel

Septembre:

  • Un serveur de supervision fonctionnel avec AU MOINS une partie des valeurs à monitorer.

Octobre:

  • Idéalement, avoir toutes valeurs à monitorer.
  • commencer à mettre en place les tâches de sauvegarde.

Novembre:

  • Avoir un serveur de supervision fonctionnel à 100 % avec toutes les valeurs à surveiller.
  • Idéalement, avoir des tâches de sauvegarde fonctionnelles.
  • Commencer à travailler sur la vérification des clefs DNSSEC.

Décembre:

  • Serveur de supervision et tâches de sauvegarde fonctionnelles à 100%.
  • Vérification des clefs DNSSEC en partie fonctionnelle.

Réalisation du Projet

Semaine 1

Durant cette semaine, 12h ont été consacré:

  • A de la documentation pour le choix de la solution à utiliser.
  • Réalisation de test sur les machines en salle E306.
  • Début de l'installation et/ou de la modification de plugins à utiliser avec NRPE pour monitorer certaines valeurs (Température).

Tests réalisé sur zabeth13 en surveillant zabeth15:

Interface Nagios

Semaine 2

Les tests ayant été concluants voir (semaine 0), l'objectif pour cette semaine fut de mettre en place la supervision sur le serveur de sauvegarde baleine.

Résumé du travail effectué

Lundi matin (4h):

  • Rédaction du wiki
  • Installation de nagios sur la VM de supervision "supervise"
  • Installation de NRPE sur baleine
  • Premier tests des plugins:
    • check_load : test la surcharge du serveur.
    • check_mem : retourne la quantité de mémoire et SwAP disponible sur le serveur
    • check_disk : retourne la quantité d'espace de stockage disponible

Jeudi (8h):

  • Mise en place d'un plugin vérification de température du processeur
  • Création d'un plugin de vérification d'état de santé des disques

Vendredi (8h):

  • Mise en place d'un plugin de vérification de l'état des VMs
  • Résolution de problèmes pour NRPE (accès/droit des utilisateurs pour l’exécution de certain scripts)

Problèmes rencontrés et résolution

Des problèmes ont été rencontré lors de la mise en place des plugin de vérification d'état des disques et des VMs. Ces derniers furent lié à un souci de droit d'accès de certains plugins lancé par NRPE.

L'erreur s'est manifesté de la manière suivante: Le lancement d'une commande shell via un script(plugin) par NRPE s'est faite sans erreur mais avec aucun output.

Pour régler le problème, il a été nécessaire de donner à NRPE les même droits que le root pour l’exécution de certains plugins en suivant les étapes indiqué dans ce guide:

  • Installation de sudo
  • Ajout des lignes suivantes au fichier /etc/sudoers avec visudo:
Defaults: nagios !requiretty
nagios    ALL=(root)  NOPASSWD: /usr/local/nagios/libexec/check_xenvm
nagios    ALL=(root)  NOPASSWD: /usr/local/nagios/libexec/smart_check_disks.sh 

NB: Cette configuration peut être dangereuse est sera modifié par la suite.

  • Dans le fichier de configuation /usr/local/nagios/etc/nrpe.cfg:
command[check_xenvm]=/usr/bin/sudo /usr/lib/nagios/plugins/check_xenvmm -w 1 -c 2
command[check_smartN]=/usr/bin/sudo /usr/lib/nagios/plugins/check_smartN N

Déploiement NRPE & Configuration de Nagios

Idée générale

La mise en place de la surveillance d'un serveur (physique comme virtuel) se fait en deux temps:

  • Installation et configuration de NRPE sur le serveur distant à surveiller.
  • Configuration de Nagios sur le serveur de supervision.

Configuration de Nagios

La configuration de Nagios se fait de manière assez simple par la modification des fichiers de configuration présent dans le répertoire /usr/local/nagios/etc/.

L'arborescence dans ce répertoire se présente comme suit:

|-- cgi.cfg                    Config de l'application web de nagios 
|-- htpasswd.users             Contient les identifiants pour la connexion à l'application web, ici: nagiosadmin:1234 
|-- nagios.cfg                 Fichier de configuration de Nagios    
|-- resource.cfg               Définition de chemin pour l'accès aux scripts lancé par Nagios    
|-- objects                    Dossier contenant les fichier de configuration relatifs aux services et hôtes   
|    |-- commands.cfg          Fichier de configuration des commandes pouvant être lancé par Nagios
|    |-- contacts.cfg          Configuration des contacts à avertir en cas de problème 
|    |-- localhost.cfg         Configuration de la supervision du serveur hôte Nagios 
|    |-- printer.cfg           Définition des imprimantes hôtes à superviser 
|    |-- switch.cfg            Définition des switchs hôtes à superviser 
|    |-- templates.cfg         Fichier contenant des templates de base pour la définition d'hôtes ou de services   
|    |-- timeperiods.cfg       Définition des configs de temps 
|    |-- windows.cfg           Exemple d'un fichier de configuration pour une machine Windows 
|-- servers                    Dossier contenant les fichier de configuration servant à la définition des hôtes à monitorer et des services à executer   
|    |-- baleine.cfg           Définitions pour l'hôte baleine    
|    |-- vmBaleine.cfg         Définitions pour les VMs se trouvant sur baleine    

Afin se surveiller une donnée, il est nécessaire de définir deux principaux élément:

  • Un hôte à surveiller.
  • Un servir à mettre en place.

La définition de ces objets se fait au moyen de macros dans des fichier de configuration (.cfg), situés dans un répertoire dédié: /usr/local/nagios/etc/servers.


Les définitions ci-dessous se situent dans le fichier /usr/local/nagios/etc/servers/baleine.cfg et permettent de monitorer le niveau de charge du serveur baleine:

On définie un hôte en lui attribuant une adresse:

define host 
      use linux-box 
      host_name baleine.insecserv.deule.net{ 
      alias Serveur de sauvegarde Baleine 
      address 172.26.64.15 
}

Et on met en place un service sur cet hôte:

define service{ 
     use generic-service 
     host_name baleine.insecserv.deule.net 
     service_description Current Load 
     check_command check_nrpe!check_load 
}

On peut voir dans la définition du service ci-dessus que Nagios exécute la commande check_nrpe, laquelle prend en paramètre "check_load"

La définition de la commande check_nrpe est faite dans le fichier de configuration /usr/local/nagios/etc/objects/commands.cfg:

define command{ 
     command_name check_nrpe 
     command_line /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ 
}

La commande check_nrpe va ensuite faire un appel au daemon nrpe executé sur la machine distante à monitorer.

Installation & Configuration de NRPE

L'installation de NRPE sur le serveur distant à monitorer s'est fait en suivant ce guide.

NRPE doit ensuite se paramétrer en modifiant le fichier /usr/local/nagios/etc/nrpe.cfg:

Serveurs autorisés à communiquer avec nrpe:

 allowed_hosts=127.0.0.1,172.26.64.13

Permet de demander à NRPE de lancer des commande avec des arguments

 dont_blame_nrme=1

Définition des commandes à lancer:

# Le script /usr/local/nagios/libexec/check_load est lancé lorsque NRPE reçoit check_load: 
command[check_load]=/usr/local/nagios/libexec/check_load -r -w .15,.10,.05 -c .30,.25,.20
...


Semaine 3

Résumé du travail effectué

Lundi(4h)

  • Résolution de problèmes lié à l’exécution de quelques scripts (problème d'affichage de la température, de l'état des disques)
  • Rédaction du wiki

Mercredi(4h)

  • Finalisation des scripts de vérification de la température du CPU et de l'état des disques
  • Installation d'une VM de test: vmtest
  • Mise en place de nrpe sur la VM de test
  • Tests des plugins sur la VM

Jeudi(4h)

  • Premiers tests effectué pour la vérification des connexions ADSL, SDSL et Renater.

Création de la VM "vmtest"

Dans le but de tester la la supervision sur une VM, la machine virtuelle "vmtest" a été créée:

Commande de création de la machine virtuelle:

xen-create-image 
 --hostname=vmtest \                 
 --memory=256mb \  
 --vcpus=1 \   
 --dir=/usr/local/xen \   
 --ip=172.26.64.16 \  
 --netmask=255.255.255.0 \   
 --dist=stable \   
 --size=4Gb \   
 --swap=128mb \

Script smartctl

Afin de vérifier l'état de santé des disques durs, un script fonctionne grace à l'outil smartctl.

Exemple commande: smartctl -ad cciss,[0-7] /dev/cciss/c0d1, pour un disque du serveur baleine (slot0). Cette commande permet de récupérer des informations concernant l'état de santé des disques, la température ainsi que divers informations (fabriquant, etc ...):

=== START OF INFORMATION SECTION ===
Vendor:               HP
Product:              DG146A4960
Revision:             HPDB
User Capacity:        146 815 737 856 bytes [146 GB]
Logical block size:   512 bytes
Rotation Rate:        10020 rpm
Logical Unit id:      0x5000cca000062ed4
Serial number:        P4V3DDTA
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Fri Dec  7 15:22:21 2018 CET
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     34 C
Drive Trip Temperature:        70 C

Manufactured in week 34 of year 2007
Specified cycle count over device lifetime:  50000
Accumulated start-stop cycles:  118
Elements in grown defect list: 0

Vendor (Seagate) cache information
  Blocks sent to initiator = 6238682277216256

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0        0         0         0          0          0,000           0
write:         0        0         0         0          0          0,000           0

Non-medium error count:      403

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background long   Completed                   -    1819                 - [-   -    -]
# 2  Background short  Completed                   -    1819                 - [-   -    -]

Long (extended) Self Test duration: 2541 seconds [42,4 minutes]

Pour les disques de la baie DAS, on récupère des informations plus détaillés sur l'état de santé des diques. Commande: smartctl -ad cciss,[8-19] /dev/cciss/c0d1:

Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   253   253   021    Pre-fail  Always       -       1150
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       6
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002f   200   200   051    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   034   034   000    Old_age   Always       -       48633
 10 Spin_Retry_Count        0x0033   100   253   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0033   100   253   051    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       6
184 End-to-End_Error        0x0033   100   100   097    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   067   050   045    Old_age   Always       -       33
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       5
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   117   100   000    Old_age   Always       -       33
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

L'idée consiste donc à réaliser un script utilisant cette commande pour remonter l'état de santé des disques. On fonction de la présence ou non d'erreur ou de warning, le script renvoi 0 (OK), 1 (Warning), 2 (Critical) ou 3 (Unknown).

Script check_temp

Le même principe à été utilisé pour relever la température du CPU.

Dans ce cas, j'ai utilisé l'outil sensors:

acpitz-virtual-0
Adapter: Virtual device
temp1:         +8.3°C  (crit = +31.3°C)

i5k_amb-isa-0000
Adapter: ISA adapter
Ch. 0 DIMM 0:  +51.0°C  (low  = +127.5°C, high = +127.5°C)
Ch. 0 DIMM 1:  +56.0°C  (low  = +127.5°C, high = +127.5°C)
Ch. 1 DIMM 0:  +66.5°C  (low  = +127.5°C, high = +127.5°C)
Ch. 1 DIMM 1:  +51.0°C  (low  = +127.5°C, high = +127.5°C)
Ch. 2 DIMM 0:  +52.0°C  (low  = +127.5°C, high = +127.5°C)
Ch. 3 DIMM 0:  +47.5°C  (low  = +127.5°C, high = +127.5°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +40.0°C  (high = +78.0°C, crit = +100.0°C)
Core 1:       +42.0°C  (high = +78.0°C, crit = +100.0°C)

coretemp-isa-0003
Adapter: ISA adapter
Core 0:       +38.0°C  (high = +78.0°C, crit = +100.0°C)
Core 1:       +32.0°C  (high = +78.0°C, crit = +100.0°C)

On obtient ici la température des deux cœurs appartenant aux deux processeurs du serveur baleine.

Pour la mise en place de la sonde, le script suivant à été récupéré sur la plateforme Nagios Exchange (et légèrement modifié).

Semaine 4

Résumé du travail effectué

Lundi (4h)

  • Premiers test réalisés sur une VM "stargate", possédant 3 interfaces reliés aux réseaux ADSL, SDSL et Renater

Mercredi(4h)

  • Continuation tests sur la VM "stargate"

Jeudi(4h)

  • Résolution de problème liés à la VM stargate (problème DNS).
  • Début Documentation DNSSEC.

VM stargate

Afin de pouvoir tester l'état de santé des réseaux ADSL, SDSL et Ranater, une machine virtuelle possédant 4 interfaces à été mise en place par Mr Redon.

Adresses IPv6:

2001:660:4401:6011:216:3eff:fe47:ba1f
2001:7a8:116e:47:216:3eff:fe47:ba20

Interfaces:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000                 Réseau ADSL
    link/ether 00:16:3e:47:ba:1e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.111/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe47:ba1e/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000                 Réseau Renater
    link/ether 00:16:3e:47:ba:1f brd ff:ff:ff:ff:ff:ff
    inet6 2001:660:4401:6011:216:3eff:fe47:ba1f/64 scope global mngtmpaddr dynamic
       valid_lft 873sec preferred_lft 773sec
    inet6 fe80::216:3eff:fe47:ba1f/64 scope link 
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000                 Réseau SDSL
    link/ether 00:16:3e:47:ba:20 brd ff:ff:ff:ff:ff:ff
    inet6 2001:7a8:116e:47:216:3eff:fe47:ba20/64 scope global mngtmpaddr dynamic 
       valid_lft 939sec preferred_lft 839sec
    inet6 fe80::216:3eff:fe47:ba20/64 scope link 
       valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000                 Réseau Renater
    link/ether 00:16:3e:47:ba:21 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::216:3eff:fe47:ba21/64 scope link 
       valid_lft forever preferred_lft forever

Table de routage ipv4:

default via 192.168.1.253 dev eth0
 192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.111 

Table de routage ipv6:

 2001:660:4401:6011::/64 dev eth1  proto kernel  metric 256  expires 923sec
 2001:660:4401:6048::/64 dev eth3  proto kernel  metric 256  expires 963sec
 2001:7a8:116e:47::/64 dev eth2  proto kernel  metric 256  expires 982sec
 fe80::/64 dev eth1  proto kernel  metric 256 
 fe80::/64 dev eth2  proto kernel  metric 256 
 fe80::/64 dev eth3  proto kernel  metric 256 
 fe80::/64 dev eth0  proto kernel  metric 256 
 default via fe80::211:5dff:fef2:5400 dev eth1  proto ra  metric 1024  expires 1723sec hoplimit 64
 default via fe80::4e4e:35ff:fe5e:b943 dev eth2  proto ra  metric 1024  expires 1782sec hoplimit 64
 default via fe80::211:5dff:fef2:5400 dev eth3  proto ra  metric 1024  expires 1763sec hoplimit 64

Semaine 5

Résumé du travail effectué

La semaine à entièrement été déduite à de la documentation à propos du protocole DNSSEC et à des recherches en vue de récupérer les dates de validité des certificats DNSSEC. A l'issue de la semaine, aucune solution n'a été trouvé pour trouver la date de validité des clefs KSK et ZSK.

Le protocole DNSSEC

Cette semaine fut pour moi l'occasion d'étudier en détail le fonctionnement du protocole DNSSEC ainsi que des différentes signatures qui y sont associées.

Fonctionnement général

Schéma d'une attaque type "man in the middle"
Fonctionnement du DNSSEC

DNSSEC est une amélioration du DNS permettant de sécuriser la communication entre un résolveur et un utilisateur. Ce protocole à été mis en place après la découverte de failles de sécurité lors de l’utilisation du DNS, lequel s'est avéré très vulnérable aux attaques DDOS ou de type "man in the middle". Il était en effet possible pour une personne malveillante d'intercepter les requêtes envoyés par des clients au serveur DNS et de répondre à la place de celui-ci, facilitant ainsi les technique de phishing.

Afin d’empêcher ce type de pratique, DNSSEC se base sur un modèle de cryptographie à clé publique. On va donc retrouver, entre le résolveur et le client, un serveur d'autorité dont le rôle va être de signer les réponses aux requêtes envoyés au serveur DNS avec une clé privé.

Les enregistrements signés par le serveur autorité sont ensuite groupé par type en RRSET.

Parmi les enregistrements propre au DNS, on retrouve notamment ces derniers:

* A       Renvoie une adresse IPv4 pour un nom de host donné.
* AAAA    Retourne une adresse IPv6 pour un nom de domaine donné.
* NS      Délègue la gestion d'une zone à un serveur de nom faisant autorité 
* SOA     Définit le serveur maitre du domaine. 
* MX      Définit le nom du serveur de courrier du domaine 
* CNAME   Permet de réaliser un alias (un raccourci) d'un host vers un autre.
...
liste complète des enregistrements DNS

A cela, on peut ajouter les enregistrements DNSSEC permettant de faciliter la validation des signatures par le client et par le serveur autorité:

* DNSSEC  Contient les clés publiques KSK et ZSK
* RRSIG   Contient les signatures des enregistrements
* NSEC    Contient la liste des enregistrements qui existent pour un domaine, utilisé notamment comme preuve de non existence (dans le cas d'une résolution impossible).
* DS      Contient des informations (Nom et clé publique) sur les zones fille du domaine concerné (ce qui permet d'établir une chaine de confiance et donc de réduire le nombre d'appel au serveur DNS).


Pour des raison de sécurité, le protocole DNSSEC repose sur deux paires de clés:

  • Une paire de clé ZSK, utilisés pour signer les enregistrement, renouvelé régulièrement (tous les 30 jours max).
  • Une paire de clé KSK, utilisés pour signer les ZSK, renouvelé moins régulièrement (tous les 13 mois max, d'après la source suivante).

Tests

Afin de récupérer les dates de validité des clefs ZSK et KSK, plusieurs tests ont été effectués grâce à l'utilisation de dig, un outil permettant d’interroger un serveur DNS. Les tests ont été effectué depuis une VM routé ne passant par le proxy, sur les domaines suivants:

  • plil.fr
  • ns.plil.fr
  • dnssec-tools.org
Tester la connexion au serveur DNS

La commande dig plil.fr +dnssec permet de vérifier si les enregistrements obtenus en interrogeant le serveur DNS sont signés avec DNSSEC:

; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30025                 // Aucune erreur retourné 
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;plil.fr. IN A
 
;; ANSWER SECTION:
plil.fr. 18696 IN A 193.48.57.52                                          // Adresse IP du domaine 
 
;; Query time: 6 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Oct 23 18:17:09 DST 2018
;; MSG SIZE rcvd: 52
Récupérer la liste des signatures obtenues

Il est possible de récupérer la liste des enregistrements qui existent pour le domaine plil.fr grâce à cette commande: dig plil.fr NSEC +multi:

; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr NSEC +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25124
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;plil.fr.               IN NSEC

;; ANSWER SECTION:
plil.fr.                259200 IN NSEC archives.plil.fr. A NS SOA AAAA RRSIG NSEC DNSKEY    // Enregistrements obtenus
 
;; Query time: 19 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Oct 23 18:41:46 DST 2018
;; MSG SIZE  rcvd: 75
Récupération des clés publiques KSK et ZSK

Cette commande permet de récupérer les clefs publiques ZSK et KSK pour un domaine: dig plil.fr DNSKEY +multi:

; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr DNSKEY +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57848
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;plil.fr.               IN DNSKEY
 
;; ANSWER SECTION:
plil.fr.                259200 IN DNSKEY 256 3 5 (
                                AwEAAcBspyK0pCevwfGt3wmU97YaOBlXhbcAxBE3tPy4
                                nGSBxFAs01WF0WUd3lgho3nXnwMXUI/KSp9nDdSLTgKe
                                H8u/IKMumUOQcggfh4UYZ2CzzycWzZ2gqBo531yI2GRZ
                                VSqdXH+jqeoVteJSH3cxEOAL0gT8yitN+RWIXumh/IId
                                ) ; ZSK; alg = RSASHA1; key id = 51828
plil.fr.                259200 IN DNSKEY 257 3 5 (
                                AwEAAaZre4ATp9W0nATXk5/nKW8unbLBOCSqpog/yYC0
                                2Y+3hUo8xrdM/OjvGNAJEpr46fp+4q10bN2SBBwNv8o6
                                cfZddEDei1HLsdJYukuLFK+EjYyboqD+fZtkgqyYFlHb
                                ltwZCpnEmfDcp+dcoTMvLwXpM1ZEyBIYJF0LBr4Na0lb
                                HNaAHrUJnMLZVLUDlA4U4rU/AZtbyJC/avdqEsjUC1w+
                                8+yY+o4j4sR3P9+iavb67XFi+Ta0fh6dQSH325drPX+T
                                CgXPUTGWjxbKJfJ0gTjrr5BYL6eEm80SC+OOdSdAEWHA
                                7QrrvO8kwYQdCzTKdbN1EZ4G5XdVo/dPtPLnlDc=
                                ) ; KSK; alg = RSASHA1; key id = 40768
 
;; Query time: 41 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Oct 23 18:46:42 DST 2018
;; MSG SIZE  rcvd: 460

En plus des clés publiques, on récupère aussi les informations suivantes:

  • ID de la clé
  • Type d'algorithme
Récupération des enregistrements signés

Les tests suivants ont été réalisé sur le domaine suivants: dnssec-tools.org, en raison du plus grand nombre de signature obtenues.

On récupère les ID des clefs publiques KSK et ZSK dig dnssec-tools.org DNSKEY +multi:

;; ANSWER SECTION:
dnssec-tools.org.       300 IN DNSKEY 256 3 5 (
                                AwEAAfDcFXK9ef/BppquoTm7LSk2rIE5x9LPu+WplVEA
                                To9i7OhqxxPy6K6uIomxLNtZAlcDbUybQEeopWhglovk
                                odkvRY72q6ZUxW1vwzBAvmDLZ7dfTjPa0LYKVQ7qsf7Q
                                jFBiyPkWARSAHH2xqBATry25ft8j9O9ULX4/DYdYPq9D
                                ) ; ZSK; alg = RSASHA1; key id = 3147
dnssec-tools.org.       300 IN DNSKEY 256 3 5 (
                                AwEAAde0IFUPiuDwEQM8vGlR436nb+TzGLlMWxzMmWDP
                                mHfWMPv8OXgZafScErgijGRnwPfv+t9irTUsX4dkvJie
                                vkV549mtDwhXLb9Vyg9C5JsoqOBq//QJvZXEZHtcHPoQ
                                9tIGVt8W9uctLUKMsAdAVaozfMxl8CuLWjqkL2Gq57HP
                                ) ; ZSK; alg = RSASHA1; key id = 19221
dnssec-tools.org.       300 IN DNSKEY 257 3 5 (
                                AwEAAazJbvxfEciFb3LmGsddun82dGsrZj4YpCvn8qHI
                                KRQ2c0Hra0LnfhOK09YKG7B9eey3aWzOKWUa50fv/0sl
                                8npI7/5tgWCQFBpIdqcDxoJxtvtFlrUlOpRQz45aFE3x
                                FJoquCfPGYgaNSZu5VGED4qAsZqxGXLvDU8SDX76Eo3G
                                oLBqYJGXG0inRVAQViFNk9ovtA2kZSP4oHTsWBCcnKDx
                                8CRZhF9jrbplzUdW7ahbTRaYv6tPYaKd7nzvH8GksO9b
                                9t5EJ1o1BhL6cDOHXOrkL+Twhc1Mwg5jBhYWH6r1LaTX
                                w2NQN1hAQzGrAZPt13kP0KQp/ybGhoKtunLxVsFiiDb6
                                4HQs+cRiw2wSf/vYaNVAiYesrMHTpq5BLeWTVrMLk2Kt
                                NtQMV972pOKipT9UN7At7Sugdpbm1g7jQ8G3eKP6iRg5
                                YA0PjbuXFNYjmKG9fMTjQGgs5IHbDVe/W3mPHYS+1970
                                AmNX/momejvYG8NlQykZdrcqPUw5dSAOmUnbehl3wzJJ
                                HIR59FaxeG9bO8vrFBlaRapz1eMtrZbqkYV7P8PnUP/3
                                i7WVGZO5AJxPpxpHaSNbd63d575pQKMQxEU7dPPfQsq8
                                wnNxcCHDixb6EetVcfv9Id9up4v9t0O33O4562kN2S9/
                                cwPOOlnobJ/g597cU2sF5Pmxn+r7
                                ) ; KSK; alg = RSASHA1; key id = 34816

On remarque la présence de plusieurs clés ZSK. Ce type de clé est en effet destiné à être remplacé régulièrement (tous les 30 jours max), le rollover de la clé se fait alors progressivement et on se retrouve en général avec deux clés d'un même type. Dans ce cas, le serveur autorité valide les enregistrement signés avec les deux clés le temps du rollover.


Les enregistrements signés peuvent ensuite être obtenus avec la commande suivante: dig dnssec-tools.org RRSIG +multi:

 ; <<>> DiG 9.10.3-P4-Debian <<>> dnssec-tools.org RRSIG +multi
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5112
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ;; QUESTION SECTION:
 ;dnssec-tools.org.      IN RRSIG
  
 ;; ANSWER SECTION:
 dnssec-tools.org.       300 IN RRSIG DNSKEY 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.   // Signature de la clé ZSK utilisé 
                                 SRwNkxRrulP6wjFaCSKC/6ZWV9vidak3h3wqXKk9MjrH
                                 jCByL8dbqdpMWDBpnjGxgf2y7NLYhriYkvgQJJIAnwDT
                                 PJFUNGSV+2Houradlnjz4IMC7T5XQGFlvPiCQ00SF/zq
                                 k7sDKNl+umgDkKE1vYcg2VbmI1RSUsDD0tXlgb8= )
 dnssec-tools.org.       300 IN RRSIG DNSKEY 5 2 300 (
                                 20181117051029 20181018041029 34816 dnssec-tools.org.  // Signature de la clé KSK utilisé
                                 OUj7q7m78jdXacfB7rMGlFSIYkD1bb25TNpXc0UBbSMn
                                 El65gff8CZNWR26NWfYbD0ZwSpzO0ifDbQWB9PXyGoev
                                  F91+cmOm4WZfAEGrwxthEyIrcsdOlv8SbArnwJR64XmN
                                 CXNAzHSx+6YVuuP3QD+ZKNCVbyAbItbiagDhNAOmwidv
                                 g0MWz2oTiJOg3TfywcKef3nuBv2U95xvvLktOEY7hUUX
                                 Jlx9hM/s4F/CNlY0yZLMArrM75SlHGyvtG4q03HRlohZ
                                 cf5VhqaIeMkjjYul33Dtt5GKzq9uDi/8Ov6saFyPHTrU
                                 6SU1a75wZSKiWiA8W6xDhV+2gc9JmG4KfNbfsNWR5rZD
                                 64CQ4/6r1FKB/XGveIJ4xFamJ43qBBZRQfSEzE5uLHZw
                                 D1FZk3EcgeEhoBYeZzGTW4SWYCG/tXLdFilMYxvJA4Uh
                                 oEryW68AfIUpBnvCkwuVakvoKarxMIb1xusKtBMZNTrR
                                 oFyjn1oUgNpujUXAAEwy2zMRNMlWOffDw2HC5MXBxqzx
                                 Bu6lGY/D8hvFiZIg2QvjNKMAEsUDoBJsgxW9yonymIzb
                                 yJdn9bcD5X5JFzmBtBlqGZnkZkTgarhFg7Oc1Lhj+tqE
                                  MBxpYXHb4YAG4oghAg65u0XGnIoc4wQd9/E/U9nDPtaA
                                 M9S9rauoI0GKKdPf5kZB51c= )
 dnssec-tools.org.       300 IN RRSIG TXT 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 JT6HieOWWKoWniaePFwMWERiXWmHTLA/njxRUbJmYC25
                                 L0YWYpiS1SEuRxwHIrgILyWAgE5t02T8XMZCyM108VE4
                                 Ahu7WKxUMegWUe+UkUwWsSAi42XNT6q+j2biGi8zDUbF
                                 zJpK0qIzZCbMAdzLu4WZpdMx8LjTcXOnkBJWFbA= )
 dnssec-tools.org.       300 IN RRSIG MX 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 zvX7zsWg2wow08/cGjqysRChZnk9vOXCjaWylUAoJZsZ
                                 6lTKXL0Y1HCnqXJe9z/xjFwt8eIjnRDCucqoYeRegxBC
                                 QG8WX5aaDAZQuRSGNUc/qgf2+hE/GxHTn4hbaBJj5hCb
                                 DeX8/qo+ynUg3OVbU8h1ynjmr4u+20cypzo4Gxs= )
 dnssec-tools.org.       300 IN RRSIG A 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 2M4jkmtd9y2e+mRWeNqvunL5DjSV/Z3fUOx4uiWbCdNQ
                                 PpF2PfMq9iEngbEQvBD+m0BZl/RswbUnAoiTeGX7/Xt0
                                 e0KgG8v+4uyKVKfHfntK3YdBgaWL/ySWLHoCz3ISE37/
                                 B1Z4jhoGOBo4J2xUqGl3A99OlDv+ublcCC3aEBY= )
 dnssec-tools.org.       300 IN RRSIG NS 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 aZY3ax6C/C34VD204K1Y0wTmDKxQ/XK4prJE13VRO/+L
                                 nNgGGPwUMhnSjkKS3QHX8g447K7ERO49PLtEeJndgDJI
                                 28nac6Fcx9wmlaxKpy+VGkAS/t/MYlzkFBdZvZKvuE+p
                                 eWcIvHBpn8NGXI1KAU2tVKTGxvimMHxdznP69gM= )
 dnssec-tools.org.       300 IN RRSIG SOA 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 HZEcgLM4CWBHtwi5huuGrq7iF+Ek5HMu6Y8K1d+Rv0tD
                                 h1Qv9o/zzl7dLm7rKDHUv0uHo6gxgvRWYrE5a0ZHDZdI
                                 QHcMIXh64dhQ6tqqEAbeaXaHPCz7Nb0lRkqzQS5JTbrf
                                 1P43r84bTGxsBPvhxDDs0Ul9MAboCsYcoTstUDo= )
 dnssec-tools.org.       10800 IN RRSIG NSEC 5 2 10800 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 aDMGZpsKlyxTA3tHGnpCUfsKWtkFxzac6LzhxJNtn1Oy
                                 5uNyZDdv0s0uSrb1H+E9te7DW7Czadl74Y5iUNnwjw+s
                                 6EODP1LRJcnlFkatlwnKPjtTxB3VWldle8fwl/LPmnUg
                                 ioO0b/SVcjfRx/j7wqnZhvqWhRops2sKjMmIwbE= )
 dnssec-tools.org.       81812 IN RRSIG DS 7 2 86400 (
                                 20181107152349 20181017142349 1862 org.
                                 bod0E+AePe5i0M7eXJe994yyvohhh4BzpHiIkqgB6SGY
                                 IMY7w0imjfqqlBnwoIeFkBVmMRpZF7izWwUAr19tK5Bs
                                 0qcn/ZZdWJTBWCaeG5Hp8s85O85InMUMpI557A/MKOLu
                                 ipuxBVFei+vyuMhlb37TBMtc/IpU8SoBYDRyIpk= )
 
 ;; Query time: 1111 msec
 ;; SERVER: 192.168.1.254#53(192.168.1.254)
 ;; WHEN: Tue Oct 23 19:07:31 DST 2018
 ;; MSG SIZE  rcvd: 2000

On retrouve les signature des clés KSK et ZSK obtenus précédemment grâce à leurs ID. On récupère aussi les dates de validités de leurs signatures:

  • 2018/11/17 - 05:10:29 pour la clé ZSK
  • 2018/11/17 - 05:10:29 pour la clé KSK

Semaine 6

Résumé du travail effectué

Lundi (4h)

  • Suite à une discussion avec le tuteur de projet, il a finalement été déterminé que la date de validité à récupérer est celle de la signature DNSKEY des clés ZSK et KSK.
  • Documentation concernant les méthodes permettant de sauvegarder les machines virtuelles.

Mercredi(4h)

  • Rédaction d'un script permettant de retourner la date de validité des signature DNSKEY des clés KSK et ZSK.
  • Mise en place d'un script permettant de vérifier la validité des certificats https.

Jeudi(4h)

  • Travail sur la VM stargate, afin de vérifier l'état des réseaux ADSL, SDSL et Renater.
  • Mise en place de politiques de routages afin de router alternativement chacune des interfaces et de les tester.


Script de récupération de la date de validité DNSKEY

Afin de récupérer la date de validité ces clés DNSKEY, un script utilisant la commande dig plil.fr DNSKEY a été utilisé. Il a été convenu avec le tuteur de projet que la date à récupérer est celle indiqué sur l'enregistrement RRSIG signé des clés publiques DNSKEY:


plil.fr.	21599 IN RRSIG DNSKEY 5 2 259200 (
                       20181221111257 20181121110621 40768 plil.fr.
                       TWruW7vtrja1i37zJw/egTbLCPvlw5DTVDvEQf7qIPu0
                       P8eKTw0dD3N+JXGU3k1mmvidw+Ljy7YeqZn9A1ZbR1Db
                       qfQnXk6sg5MBRS0Xw3QFVB61cvnETz36bsZQvd7fO9ny
                       KMWpviQOEfjWbZaZk5vbDZXbgFrksj7Mt/55zMvyMFvJ
                       I5fAv+mlo5RGk8M/AUJ20TaVjUOfe/p9qTlDJoEFSjeW
                       A6qN7tFjn7qIvgHLhcghguVBsn7nogxzX9gIZ0uvZSFz
                       xC+xQrn8wEOISSZJWm9ZONwJuHcT8oIgjcSqnDx4rmcu
                       pF3YyB2OYTcxa9JT+Hx8wX0swoc0P+B/Nw== )
plil.fr.	21599 IN RRSIG DNSKEY 5 2 259200 (
                       20181221111257 20181121110621 51828 plil.fr.      
                       Oc+8B84qbhy4lh2Uka1bkJnYJhQFFSZO3AfxW6YPbQha
                       vsVd9ozGc3Zbs3jumVm6TLK5sC8B+l24NnBeGD9QCiG4
                       29RbsRMyOi59YaemTA42BRuZCKJMWvJn6e/0FCyvTc2T
                       w/we6MWDXcRoIAqbCD+79Bniq+sbt4pBRU2zrWU= )

L'enregistrement contient des informations suivantes(plus d'infos sur ce lien):

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type Covered           |  Algorithm    |     Labels    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Original TTL                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Signature Expiration                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Signature Inception                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Key Tag            |                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Signature                          /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L'idée pour le script consiste donc à récupérer la date d'expiration et à la parser. Le résultat suivant est obtenu:

root@stargate:~/PFE_IMA_5 ./check_dnssec.sh plil.fr ZSK
Key OK - ZSK Expiration Date = 2018/12/21 11:12:57 | 20181221111257

Tables de routages

Pour la réalisation du script permettant de récupérer l'état de santé des réseaux ADSL, SDSL et Renater, la "difficulté" a surtout résidé dans le fait de forcer l'utilisation d'une interface pour pouvoir tester un réseau en particulier.

On doit tester les trois réseaux suivants:

  • ADSL -> eth0
  • SDSL -> eth1 et eth3
  • Renater -> eth2

Étant donné que l'interface eth0 est la seule à posséder une adresse en ipv4, un simple ping vers des machines distantes permet de tester l'état du réseau ADSL.

Pour tester les réseaux SDSL et Renater, il faut faire en sorte d'utiliser uniquement d'une de ces interfaces. On peut observer qu'en pingant une adresse en ipv6 depuis l'interface eth2 (donc en utilisant le réseau SDSL), les paquets sont envoyé depuis l'adresses ipv6 de l'interface eth1 (Renater):

root@stargate:~# ping6 -I eth2 2001:4860:4860::8888
ping6: Warning: source address might be selected on device other than eth2.
PING 2001:4860:4860::8888(2001:4860:4860::8888) from 2001:660:4401:6011:216:3eff:fe47:ba1f eth2: 56 data  bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=55 time=5.13 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=55 time=5.55 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=3 ttl=55 time=5.19 ms

Ce fait à été confirmé par une analyse via tcpdump:

root@stargate:~# tcpdump -i eth1 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:06:38.694422 IP6 2001:660:4401:6011:216:3eff:fe47:ba1f > google-public-dns-a.google.com: ICMP6, echo request, seq 8, length 64
16:06:38.699920 IP6 google-public-dns-a.google.com > 2001:660:4401:6011:216:3eff:fe47:ba1f: ICMP6, echo reply, seq 8, length 64

L'idée initial à donc consisté à créer des règles de routages pour chaque réseau et à activer uniquement l'une d'elle pour forcer l'utilisation d'une seule interface. Cependant, cette solution s'est avéré inutile, la VM étant capable de pinger via une interface malgré l'absence de règle de routage pour cette dernière.

Semaine 7

Résumé du travail effectué

Lundi (4h)

  • Rédaction d'un scipt pour tester la connectivité des réseaux ADSL, SDSL et Renater.
  • Tests réalisés sur l’hôte de la VM stargate (en débranchant les entrés ADSL, SDSL et Renater pour simuler un problème de connectivité).

Mercredi(4h)

  • Correction du script pour test de la connectivité des réseaux ADSL, SDSL et Renater.

Tests connectivité des réseau ADSL, SDSL et Renater - Suite

Dans la continuité de ce qui a été fait durant la dernière semaine, d'autres test ont été réalisés afin de pinger par une interface.

Une solution à finalement été trouvé en utilisant la commande suivante:

root@stargate:~# ping6 -I 2001:7a8:116e:47:216:3eff:fe47:ba20  2001:4860:4860::8888
PING 2001:4860:4860::8888(2001:4860:4860::8888) from 2001:7a8:116e:47:216:3eff:fe47:ba20 : 56 data bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=57 time=7.16 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=57 time=7.21 ms

Cependant, en analysant les paquets icmp6 passant par les interface eth1 et eth2 on obtient ceci:

Les echo request sont envoyé sur l'interface eth1

root@stargate:~# tcpdump -i eth1 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:36:49.282006 IP6 2001:7a8:116e:47:216:3eff:fe47:ba20 > google-public-dns-a.google.com: ICMP6, echo request, seq 15, length 64
16:36:50.283237 IP6 2001:7a8:116e:47:216:3eff:fe47:ba20 > google-public-dns-a.google.com: ICMP6, echo request, seq 16, length 64
16:36:51.284455 IP6 2001:7a8:116e:47:216:3eff:fe47:ba20 > google-public-dns-a.google.com: ICMP6, echo request, seq 17, length 64

Les echo reply sont ensuite reçues sur l'interface eth2, puisque l'adresse source indiqué explicitement est celle de l'interface eth2:

root@stargate:~# tcpdump -i eth2 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
16:32:17.341902 IP6 google-public-dns-a.google.com > 2001:7a8:116e:47:216:3eff:fe47:ba20: ICMP6, echo  reply, seq 4, length 64
16:32:18.343265 IP6 google-public-dns-a.google.com > 2001:7a8:116e:47:216:3eff:fe47:ba20: ICMP6, echo reply, seq 5, length 64
16:32:19.344553 IP6 google-public-dns-a.google.com > 2001:7a8:116e:47:216:3eff:fe47:ba20: ICMP6, echo reply, seq 6, length 64

Des tests complémentaires ont ensuite été fait directement en salle serveur en débranchant les liaisons ADSL, SDSL et Renater. Cette solution s'est finalement avéré fonctionner.

Un script renvoyant l'état des réseaux ADSL, SDSL et Renater a finalement été rédigé:

usage: ./check_ping.sh <Network> 
Network : choose: ADSL, SDSL or Renater
root@stargate:~/PFE_IMA_5# ./check_ping.sh ADSL
Connexion ADSL OK - 10/10 paquets reçus

Ce script ping 5 adresses ipv4 ou ipv6 et renvoie l'état du réseau indiqué en paramètre ainsi le nombre de paquets reçus.

Semaine 8

Résumé du travail effectué

Mercredi(4h)

  • Redaction d'un script pour sauvegarde automatique (destiné à fonctionner avec cron). Le script en question sauvegarde les images disk & swap des VMs sur le serveur de sauvegarde baleine.
  • Configuration de Nagiosafin de permettre la visualisation des données via grafana.

Installation de Grafana

Afin de soigner l'affichage des valeurs à monitorer, un serveur grafana à été installé sur le serveur de supervision.

Ce dernier consiste en une application web apache2 permettant de récupérer des flux provenant de bases de donnés (type times series) et de les afficher. Grafana peut ainsi afficher simultanément des graphs et des données provenant de plusieurs sources.

Afin de pouvoir afficher les données produites par Nagios, la base de donné InfluxDB a été installé:


Source: Load value du serveur baleine affiché sur grafana

Semaine 9

Résumé du travail effectué

Mercredi(6h)

  • Tests de l'outil de supervision Prometheus combiné avec l'outil de visualisation de données grafana.
  • Recherche d'un système de backup open source fonctionnant sur linux:

Installation de Grafana + Node_exporter

Cette séance à été dédié à l'installation du serveur de supervision Prometheus, qui est un fork de nagios. Ce dernier est moderne et possède une compatibilité avec Node_exporter, un outil permettant de prélever des données via des outils linux et des afficher formaté sur un serveur web.

La configuration se fait de manière très simple en indiquant les adresses IP des machines à superviser dans le fichier prometheus.yml:

scrape_configs:
 # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
   
 - job_name: 'node'
   static_configs:
           - targets: ['172.26.64.15:9100','localhost:9100','172.26.64.16:9100']  

Le résultat obtenue se présente de la manière suivante:


Semaine 10

Résumé du travail effectué

Mercredi(4h)

  • Test de la solution de sauvegarde incrémentiel rsnapshot

jeudi(4h)

  • Continuation des tests sur rsnapshot.

Après une discussion avec le tuteur de projet, la solution rsnapshot à finalement été abandonné en raison de son non respect au cahier des charges (nécessite trop de configuration).

Semaine 11

Résumé du travail effectué

Jeudi(4h)

  • Correction bug script DNSSEC et état disque.
  • Rédaction Wiki

Vendredi(4h)

  • Rédaction Wiki

Semaine 12

Résumé du travail effectué

Jeudi(4h)

  • Rédaction Wiki
  • Début Rédaction rapport

Semaine 13

Résumé du travail effectué

Lundi(6h)

  • Modification du script de vérification de l'état des disques pour intégration à Prometheus.
  • Intégration du script de vérification de l'état des disques à la dashboard grafana.

Mardi(6h)

  • Modification et installation de script de service pour prometheus et node_exporter sur les VMs et Serveurs.

Mercredi(4h)

  • Script pour sauvegarde automatique des machines virtuelles, avec roulement sur 3 jours, 3 semaines et 3 mois (modification du script fournit par Mr Redon).

Documents Rendus

Fichier:Rapport interm diaire PFE.pdf

Fichier:Soutenance PFE.pdf