TP sysres IMA5sc 2018/2019 G5
Sommaire
- 1 TP Systeme Reseau
- 1.1 TP Conteneur Reseau
- 1.2 TP Conteneur Reseau
- 1.3 TP PRA Global
TP Systeme Reseau
Vous trouverez sur cette page Wiki tous les travaux relatifs au cours de Systeme Reseau réalisés par Delobelle Matthieu
TP Conteneur Reseau
Etapes de realisation des conteneurs (a la main)
Creation d'un fichier (utilisé en tant que partition) de 10240 bloc de 1024k octets (Soit un fichier de 10Go)
dd if=/dev/zero of=disc.img bs=1024k count=10240
Creation d'un systeme d'un systeme de fichier linux au sein du fichier precedemment créé
mkfs disc.img
Creation des dossiers temporaires dans lequel le systeme sera monté
mkdir /tmp/fs1 mkdir /tmp/fs2 mkdir /tmp/fs3
Montage du systeme de fichier dans fs1
mount -o loop disc.img /tmp/fs1
La commande df -Ath permet d'avoir la liste des partitions montés par le systeme
On voit bien que le /tmp/fs0 propose un emplacement memoire de 10Go
Bootstrap d'un systeme Debian au sein de la partition montée
debootstrap --include=apache2,vim,nano stable /tmp/fs1
Preparation du montage du systeme
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab
Unmount de la partition
umount /tmp/fs1
(On remarque bien que la partition n'est plus montée via df -h)
Duplication de l'image deux fois, puis montage des trois systemes de fichier
cp disc.img disc2.img cp disc.img disc3.img
mount -o loop disc.img /tmp/fs1 mount -o loop disc2.img /tmp/fs2 mount -o loop disc3.img /tmp/fs3
On verifie le resultat avec un autre df -h
Demarrage des conteneurs en chargeant les systemes de fichier.
unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash"; # La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom # -n : table de nom reseau # -u : table des hostnames
Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :
On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur
En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs
ps aux | grep unshare
Mise en réseau des conteneurs
Creation du bridge (commutateur virtuel) sur la machine hote
ip link add bridge2 type bridge
Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire)
ip link add vif1 type veth peer name eth0@vif1 #conteneur 1 ip link add vif2 type veth peer name eth0@vif2 #conteneur 2 ip link add vif3 type veth peer name eth0@vif3 #conteneur 3 ip link add vif4 type veth peer name eth1@vif4 #mandataire
Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif.
ip link set vif1 master bridge2 ip link set vif2 master bridge2 ip link set vif3 master bridge2 ip link set vif4 master bridge
ip link set vif1 up ip link set vif2 up ip link set vif3 up ip link set vif4 up
On recupere les PID des differents conteneurs
ps aux | grep unshare
Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif
ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1 ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2 ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3
On ajoute ensuite les adresses IP a chaque conteneur
Dans le conteneur 1
ip addr add 192.168.1.11/24 dev eth0 ip link set eth0 up ip link set lo up
Dans le conteneur 2
ip addr add 192.168.1.12/24 dev eth0 ip link set eth0 up ip link set lo up
Dans le conteneur 3
ip addr add 192.168.1.13/24 dev eth0 ip link set eth0 up ip link set lo up
On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote
On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire
ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1 ip addr add 172.26.145.140/24 dev eth1 ip link set eth1 up
Mise en place des mandataires inverses
TP Conteneur Reseau
Etapes de realisation des conteneurs (a la main)
Creation d'un fichier (utilisé en tant que partition) de 10240 bloc de 1024k octets (Soit un fichier de 10Go)
dd if=/dev/zero of=disc.img bs=1024k count=10240
Creation d'un systeme d'un systeme de fichier linux au sein du fichier precedemment créé
mkfs disc.img
Creation des dossiers temporaires dans lequel le systeme sera monté
mkdir /tmp/fs1 mkdir /tmp/fs2 mkdir /tmp/fs3
Montage du systeme de fichier dans fs1
mount -o loop disc.img /tmp/fs1
La commande df -Ath permet d'avoir la liste des partitions montés par le systeme
On voit bien que le /tmp/fs0 propose un emplacement memoire de 10Go
Bootstrap d'un systeme Debian au sein de la partition montée
debootstrap --include=apache2,vim,nano stable /tmp/fs1
Preparation du montage du systeme
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab
Unmount de la partition
umount /tmp/fs1
(On remarque bien que la partition n'est plus montée via df -h)
Duplication de l'image deux fois, puis montage des trois systemes de fichier
cp disc.img disc2.img cp disc.img disc3.img
mount -o loop disc.img /tmp/fs1 mount -o loop disc2.img /tmp/fs2 mount -o loop disc3.img /tmp/fs3
On verifie le resultat avec un autre df -h
Demarrage des conteneurs en chargeant les systemes de fichier.
unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash"; # La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom # -n : table de nom reseau # -u : table des hostnames
Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :
On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur
En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs
ps aux | grep unshare
Mise en réseau des conteneurs
Creation du bridge (commutateur virtuel) sur la machine hote
ip link add bridge2 type bridge
Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire)
ip link add vif1 type veth peer name eth0@vif1 #conteneur 1 ip link add vif2 type veth peer name eth0@vif2 #conteneur 2 ip link add vif3 type veth peer name eth0@vif3 #conteneur 3 ip link add vif4 type veth peer name eth1@vif4 #mandataire
Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif.
ip link set vif1 master bridge2 ip link set vif2 master bridge2 ip link set vif3 master bridge2 ip link set vif4 master bridge
ip link set vif1 up ip link set vif2 up ip link set vif3 up ip link set vif4 up
On recupere les PID des differents conteneurs
ps aux | grep unshare
Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif
ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1 ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2 ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3
On ajoute ensuite les adresses IP a chaque conteneur
Dans le conteneur 1
ip addr add 192.168.1.11/24 dev eth0 ip link set eth0 up ip link set lo up
Dans le conteneur 2
ip addr add 192.168.1.12/24 dev eth0 ip link set eth0 up ip link set lo up
Dans le conteneur 3
ip addr add 192.168.1.13/24 dev eth0 ip link set eth0 up ip link set lo up
On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote
On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire
ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1 ip addr add 172.26.145.140/24 dev eth1 ip link set eth1 up
Mise en place des mandataires inverses
Configuration du fichier sites-enables/000-default.conf du mandataire inverse (conteneur 3)
<VirtualHost *:80> ServerName azeroth.plil.space ServerAdmin webmaster@mdelobel.plil.space ProxyPass / http://192.168.1.11 ProxyPassRever / http://192.168.1.11 ProxyRequests Off ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> <VirtualHost *:80> ServerName argus.plil.space ServerAdmin webmaster@mdelobel.plil.space ProxyPass / http://192.168.1.12 ProxyPassRever / http://192.168.1.12 ProxyRequests Off ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>
11h => Serveurs Web unshare OK (pb a du recommencer voir Ji)
12h20 => Serveurs Web docker OK
TP PRA Global
Cette partie a été realisée en binôme avec Ji YANG
Changement des cartes SD (Cordouan et Chassiron)
Changement du système de stockage pour les serveur Chassiron et Cordouan. L'objectif étant d'augmenter la taille des cartes SD servant au stockage du système afin de passer de carte 2Go a 16Go
Etapes de réalisation
Nous nous attaquerons dans une premier temps au serveur Chassiron, qui n'est pas en utilisé activement pour les travaux en cours, cela permettra de bénéficier de plus de temps pour mettre en place les manipulations, afin d'aller plus vite sur le serveur Cordouan qui est necessaire au fonctionnement de certains systèmes
Extinction des machines et recup des cartes SD
Avant d'extraire une des cartes SD, il est necessaire d'éteindre correctement la machine. Cette simple commande fait l'affaire
shutdown now
Cependant la commande shutdown prévoit une sauvegarde des processus en cours, la commande halt aurait pu eviter cette étape..
Copie des cartes SD
Nous recuperons une des deux cartes SD présentes sur Chassiron, puis la branchons sur un des ordinateurs portables (Flétan dans notre cas) afin de proceder à la copie des cartes. (On ne peut utiliser une Zabeth ni une Tutur, car elles ne disposent pas de lecteur de carte SD)
Une fois la carte branchée, on remarque en utilisant la commande ls /dev/ que 4 nouveaux fichiers sont apparus. Pour voir lesquels, cela est très facile :
ls /dev/ > tmp ##BRANCHER LA CARTE SD ls /dev/ > tmp2 diff tmp tmp2
On voit alors le nom des trois fichiers. Grace à la commande suivante, on peut determineur leur contenu, et le type de fichier
fdisk -l /dev/mmcblk0*
/// INSERER PHOTO
On voit que le fichier mmcblk0 contient 3 partitions, une de type Linux, une Extended, ainsi qu'une Linux Swap. Etant donné qu'il s'agit du type respectif des trois autres fichiers.. on en déduit que la partition mmcblk0 contient en réalité mmcblk0p1, p2 et p5
Il ne suffit donc de dupliquer le contenu de mmcblk0 vers l'autre carte, car il contient l'intégralité des données de la carte. Pour se faire, on duplique les données vers un fichier temporaire, que l'on re-dupliquera vers la plus grande carte SD
dd if=/dev/mmcblk0 of=/home/pifou/TMP_SAVESDCARD1_CHASSIRON/data.bin ### CHANGEMENT DE CARTE dd if=/home/pifou/TMP_SAVESDCARD1_CHASSIRON/data.bin of=/dev/mmcblk0
On peut vérifier la bonne duplication du système en reefectuant la commande 'ls /dev/' et en voyant que les partitions mmcblk0p1, p2 et p5 ont été créées.
On peut également monter le système pour vérifier son intégrité.
mkdir /tmp/u1 mount /dev/mmcblk0p1 /tmp/u1 cd /tmp/u1
Si tout se passe bien, on peut parfaitement naviguer dans le système Linux de Chassiron
Augmentation de la taille des partitions
Afin d'utiliser pleinement les cartes SD et toute leur capacité, il est necessaire d'augmenter la taille des partitions (qui est encore à 2Go à cette étape), afin de pouvoir ensuite augmenter la tailler du système de fichier.
Pour se faire il faut tout d'abord démonter la carte.
umount /tmp/u1
Puis on peut lancer l'utilitaire "parted" afin de modifier les partitions en ligne de commande. On utilise alors la suite de commande suivante
select /dev/mmcblk0 print
//INSERER PHOTO
Comme on peut le voir, si l'on souhaite augmenter la taille de la partition du système linux (aka. changer l'indice de fin de la partition) il faut tout d'abord supprimer les partitions de swap. Pour se faire
rm 2 #identifiant obtenu avec la commande print rm 5
resizepart 1 #Augmente la taille de la partition "1" (celle du système) 15000
//PHOTO
Une fois cela fait, on recrée les partitions necessaires au swap
mkpart extended 15001 15134 #Creation de l'extented apres la partition du Linux mkpart logical linux-swap(v1) 15001 15134
On peut ensuite regenerer le fichier avec la commande dd
Une fois la taille de la partition augmentée, on peut desormais augmenter la taille du système de fichier Linux. Pour se faire, on lance les commandes suivantes :
e2fsck -f /dev/mmcblk0p1 resize2fs /dev/mmcblk0p1
Cela redimensionnera automatiquement le système de fichier afin qu'il prenne la taille maximale de la partition
Creation VM Xen
Creation de l'image
Une fois le serveur Cordouan redémarré, on s'y connecte en SSH ( cordouan.insecserv.deule.net ), puis on y cree l'image Xen qui nous servira de VM. Le thème choisi étant les déités grecques.. notre VM s'appellera 'Chronos'
xen-create-image --hostname=Chronos --ip=193.48.57.181 --netmask=255.255.255.240 --gateway=193.48.57.176 --dir=/usr/local/xen
Du fait que nous n'avons pas préciser l'option --password, un mdp a été généré automatiquement, il est lisible dans les logs, accessibles grâce à :
cat /var/log/xen-tools/Chronos.log
On peut ensuite lancer la commande
xl create /etc/xen/Chronos.cfg
On peut vérifier le bon fonctionnement grâce à la commande
xl list
On voit donc bien l'image Xen 'Chronos' qui est lancée, on peut donc s'y connecter :
xl console Chronos
Pour plus de praticité, on va changer le mot de passe, en utilisant celui habituel de root avec la commande passwd
Activation SSH
On autorise l'utilisation du SSH en tant que root, pour se faire on modifie le fichier de config /etc/ssh/sshd_config, en éditant la commande PermitRootLogin
PermitRootLogin yes
On pense a redemarrer le service ssh
service ssh stop service ssh start
Ajout des partitions logiciels
Extention des volumes du /home et /var
Notre VM est hebergé par le serveur Cordouan sur un seul volume de 10Go. Pour la suite du TP, notre VM aura besoin de plus d'espace, nous créons donc 2 partitions logicielles sur Cordouan, de 10Go chacune que l'on reservera au /home et au /var
lvcreate -L10G -n chronos-home virtual lvcreate -L10G -n chronos-var virtual
Une fois les partitions créées, il faut les raccorder à la machine Xen, pour se faire on modifie le fichier de config Chronos.cfg
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/Chronos/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Chronos/swap.img,xvda1,w',
'phy:/dev/virtual/chronos-home,xvdb1,w', 'phy:/dev/virtual/chronos-var,xvdc1,w',
Une fois Chronos redemarré, on créé un système de fichier dans les partitions de 10Go recemment importée.
mkfs -t ext4 /dev/xvdb1 mkfs -t ext4 /dev/xvdc1
On peut alors monter ses partitions dans le /home et dans le /var
mount /dev/xvdb1 /home #Pas de probleme, car le /home est vide
mkdir /vtmp mount /dev/xvdc1 /vtmp cp -R /var/* /vtmp/ umount /vtmp mount /dev/xvdc1 /var
Afin que cette configuration soit conservée et lancée au changement, on modifie le fichier /etc/fstab
# /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0 /dev/xvda1 none swap sw 0 0 /dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1 /dev/xvdb1 /home ext4 defaults 0 2 /dev/xvdc1 /var ext4 defaults 0 2
Creation du RAID5
Afin de crée le RAID5, il est necessaire d'installer le paquet mdadm
apt-get install mdadm
On reproduit la manipulation precedente afin de crée trois partitions de 1Go
lvcreate -L1G -n khronos-part1 virtual lvcreate -L1G -n khronos-part2 virtual lvcreate -L1G -n khronos-part3 virtual
et ajout dans le Chronos.cfg
'phy:/dev/virtual/khronos-part1,xvdd1,w', 'phy:/dev/virtual/khronos-part2,xvde1,w', 'phy:/dev/virtual/khronos-part3,xvdf1,w'
Apres redemarrage de la machine, les 3 partitions sont chargées, il est donc possible de créer un RAID logiciel via la commande :
mkdir /raid mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1 mkfs -t ext4 /dev/md0
On rajoute donc le RAID5 dans le /etc/fstab
/dev/md0 /raid ext4 defaults 0 2
On peut donc vérifier le bon fonctionnement du systeme avec la commande lsblk
Configuration de bind9
Bind est un paquet permettant la mise en place d'un DNS sur la machine, on l'installe donc au côté d'apache pour la suite du TP
apt-get install bind9 apache2
Bind vient avec tout un packetage de fichier de configuration à modifier permettant le bon fonctionnement du systeme. Afin de configurer notre propre DNS, nous allons créer le fichier /etc/bind/dns.khronos.site dans lequel nous écrirons notre onfig
$TTL 604800 @ IN SOA dns.khronos.site. root.khronos.site. ( 12 ; Serial 43200 ; Refresh 1800 ; Retry 1814400 ; Expire 604800 ) ; Negative Cache TTL ; IN NS dns.khronos.site. IN NS ns6.gandi.net. dns IN A 193.48.57.181 www IN A 193.48.57.181 @ IN A 193.48.57.181
Il est important de faire attention à ce fichier, qui peut être source de nombreuses erreurs :
- Il est primordial d'avoir un '.' a la fin des adresses dns - A chaque modification du fichier il faut incrémenter l'indice Serial - Ne pas oublier les 3 champs, dont le champ @ - Avoir des valeurs cohérentes pour les délais
Configuration de DNSSEC
DNSSEC permet de SECuriser les echanges DNS, pour se faire nous allons signer notre fichier de config DNS. Pour y parvenir, nous allons généré un couple de clés (KSK et ZSK)
mkdir khronos.site.dnssec cd khronos.site.dnssec dnssec-keygen -f KSK -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE khronos.site dnssec-keygen -a RSASHA1 -b 1024 -n -r /dev/urandom ZONE khronos.site
Pour plus de faciliter on renomme les clés générées
mv Kkhronos.site.+005+52087.key khronos.site.ksk.key mv Kkhronos.site.+005+52087.private khronos.site.ksk.private mv Kkhronos.site.+005+49746.key khronos.site.zsk.key mv Kkhronos.site.+005+49746.private khronos.site.zsk.private
On inclue donc ces clés dans le fichiers dns.khronos.site
$include /etc/bind/khronos.site.dnssec/khronos.site.ksk.key $include /etc/bind/khronos.site.dnssec/khronos.site.zsk.key
Et on peut finalement signer le fichier dns.khronos.site avec les clés (a lancé depuis le dossier /etc/bind/)
dnssec-signzone -o khronos.site -k khronos.site.dnssec/khronos.site.ksk.key dns.khronos.site khronos.site.dnssec/khronos.site.zsk.key
Config des named.conf
Une fois le fichier /etc/bind/dns.khronos.site.signed généré, on peut donc modifier le fichier /etc/bind/named.conf.local
zone "khronos.site" {
type master;
file "/etc/bind/dns.khronos.site.signed";
allow-transfer { 217.70.177.40;};
};
L'adresse IP dans le allow-transfer est obtenue en prennant l'adresse de ns6.gandi.net
et on ajoute les commandes suivantes dans le named.conf.options afin de confirmer l'utilisation de dnssec
dnssec-validation auto; dnssec-enable yes;
Ajout de la clé KSK dans Gandi
Sur l'interface WEB de Gandi, il est possible d'envoyer notre clé KSK, pour se faire on donne à Gandi la partie surlignée du screen suivant
Il faut bien évidemment mettre les configs correspondantes a format de la clé..
Verification du DNSSEC avec DNSVIZ
Le site [dnsviz.net] permet de vérifier l'état de marche de notre DNSSEC
Et selon lui, tout est okay !
Certificat SSL et sécurisation d'Apache
Obtention du certificat
Nous commençons par un générer deux fichiers grâce à la commande
openssl req -nodes -newkey rsa:2048 -sha1 -keyout khronos.site.key -out khronos.site.csr
- khronos.site.csr : il s'agit d'un fichier servant à faire une demande de certificat auprès de Gandi. Il contient quelques informations personnelles ainsi que la cl" publique.
- khronos.site.key : c'est la clé
On peut envoyer le fichier .csr à Gandi afin d'obtenir notre certificat SSL. Pour se faire on choisi le mode de validation par fichier Pour obtenir validation, il faut créer le fichier /var/www/html/.well-known/pki-validation/B726A2F14B337F7C0B53A107F0930FF2.txt et y mettre le contenu exigé par Gandi (Attention dans le formatage de Gandi les retours chariots sont écris avec des \n, il est necessaire de bien les remplacer..)
On peut donc telecharger notre certificat SSL une fois qu'il a été validé. Une fois obtenu, on le deplace dans les dossiers correspondants
/etc/ssl/certs/khronos.site.crt /etc/ssl/private/khronos.site.key /etc/ssl/certs/GandiStandardSSLCA2.pem
Securisation d'Apache
Il est nécessaire d'activer le module SSL d'Apache, cela se fait grâce à la commande suivante
a2enmod ssl
Une fois cela fait, on peut donc modifier le fichier de config d'apache /etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80> ServerName www.khronos.site Redirect / https://www.khronos.site #Tout appel sur le port 80 (http) redirigera vers le https a savoir le 443 DocumentRoot /var/www/html </VirtualHost> <VirtualHost *:443> ServerName www.khronos.site DocumentRoot /var/www/html SSLEngine on SSLCertificateFile /etc/ssl/certs/khronos.site.crt SSLCertificateKeyFile /etc/ssl/private/khronos.site.key SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem SSLVerifyClient None </VirtualHost>
Une fois la modifications effectuées, on redemarre le service apache2
service apache2 restart
Et une fois que Gandi a réalisé sa propagation, il est possible d'obtenir un connexion https sécurisée sur khronos.site
