Aller au contenu

Exercice 1 — Remettre Cyclo-Nord en service

Durée : ~45 min · En équipe · Théorie associée : Sauvegarder une VM et la remettre en place

Objectif

Remettre en service le pare-feu, le serveur de données et la caisse de Cyclo-Nord sur des serveurs réinstallés, à partir des archives du jalon 1, et retrouver les ventes de la semaine 4.

Prérequis

  • Les quatre archives .vma.zst de l'exercice 4 de la semaine 4, dans le dossier OneDrive de l'équipe.
  • Le fichier jalon1/running-config.txt dans le dépôt GitLab de l'équipe.
  • Les serveurs de l'équipe réinstallés : Proxmox répond sur https://10.70.44.#:8006, et aucune VM n'existe.
  • Le numéro de chaque serveur de l'équipe, noté #.

Les VM retournent sur les mêmes serveurs qu'à la semaine 4 :

VM ID Serveur
fw-cyclonord 401 serveur 1
srv-donnees 403 serveur 2
caisse 402 serveur 3

Si votre équipe n'a que deux serveurs, tout ce qui concerne le serveur 3 se fait sur le serveur 2. Si elle n'en a qu'un, tout se fait sur ce serveur.

Le template 9000 ne sert pas aujourd'hui. Gardez son archive dans le dossier OneDrive sans la restaurer.

Étape 1 — Vérifier le switch

Ouvrez la console série du switch, comme à l'exercice 1 de la semaine 4, puis passez en mode privilégié.

Bash
enable
Bash
show vlan brief

Les VLAN 10 bureaux, 20 serveurs, 30 dmz, 460 publique et 700 gestion doivent apparaître. Si c'est le cas, passez directement à l'étape 3.

Étape 2 — Recoller la configuration du switch

Faites cette étape seulement si l'étape 1 ne montre pas les cinq VLAN : le switch a été remis à zéro lui aussi.

Ouvrez jalon1/running-config.txt dans GitLab et copiez tout son contenu. Dans la console du switch :

Bash
configure terminal

Collez le contenu copié, puis :

Bash
end
Bash
write memory

Quelques lignes peuvent afficher % Invalid input detected : ce sont des lignes d'en-tête que le switch écrit mais ne relit pas, comme Building configuration.... Retapez show vlan brief : les cinq VLAN sont revenus.

C'est la raison d'être de ce fichier dans le jalon 1. Le switch ne se sauvegarde pas avec vzdump, et sa configuration n'existe nulle part ailleurs.

Étape 3 — Rendre vmbr0 VLAN aware

Faites cette étape sur chaque serveur de l'équipe.

Allez dans System > Network, sélectionnez vmbr0, cliquez sur Edit et cochez VLAN Aware. Validez, puis cliquez sur Apply Configuration.

La fenêtre d'édition de vmbr0 avec la case VLAN Aware cochée

Un serveur réinstallé a un bridge neuf, qui ignore les étiquettes VLAN. Sans ce réglage, les trois VM démarreraient, mais aucune ne joindrait son réseau.

Étape 4 — Limiter les VLAN du bridge

Toujours sur chaque serveur, ouvrez le Shell du nœud :

Bash
nano /etc/network/interfaces

Dans le bloc vmbr0, remplacez la ligne bridge-vids 2-4094 par :

INI
    bridge-vids 10,20,30,460
Bash
ifreload -a
Bash
bridge vlan show

La carte physique porte le VLAN 1 en PVID Egress Untagged, puis les VLAN 10, 20, 30 et 460

La commande liste les deux ports du bridge : la carte physique du serveur et vmbr0 lui-même. Le nom de la carte dépend du modèle de serveur, par exemple eno8303. C'est sur elle que vous devez lire les VLAN 10, 20, 30 et 460 : les VLAN de l'entreprise et le VLAN public, rien d'autre.

Étape 5 — Autoriser les snippets

Faites cette étape sur les serveurs 2 et 3.

Allez dans Datacenter > Storage, sélectionnez local et cliquez sur Edit. Dans la liste Content, ajoutez Snippets sans retirer les autres types.

La fenêtre d'édition du stockage local avec Snippets coché en plus des autres types de contenu

Étape 6 — Recréer le snippet des serveurs

Toujours sur les serveurs 2 et 3, dans le Shell du nœud :

Bash
nano /var/lib/vz/snippets/serveur.yaml

Écrivez exactement le même contenu qu'à l'exercice 3 de la semaine 4 :

YAML
#cloud-config
packages:
  - qemu-guest-agent
  - docker.io
  - curl
  - netcat-openbsd
runcmd:
  - systemctl enable --now qemu-guest-agent
  - systemctl enable --now docker
  - usermod -aG docker etudiant

L'archive de caisse et celle de srv-donnees contiennent la ligne cicustom: vendor=local:snippets/serveur.yaml. L'archive transporte cette référence, mais pas le fichier lui-même, qui vivait sur le disque du nœud. Sans lui, Proxmox refuse de démarrer la VM.

Étape 7 — Récupérer les archives

Sur votre poste, téléchargez les trois archives vzdump-qemu-401-…, vzdump-qemu-402-… et vzdump-qemu-403-… depuis le dossier OneDrive de l'équipe, dans Documents\tp1-cyclonord.

Ouvrez PowerShell et placez-vous dans ce dossier :

PowerShell
cd $HOME\Documents\tp1-cyclonord
PowerShell
dir

Les trois archives vma.zst sont présentes avec leur taille

Étape 8 — Envoyer l'archive du pare-feu

PowerShell
scp .\vzdump-qemu-401-*.vma.zst root@10.70.44.#:/var/lib/vz/dump/

Remplacez # par le numéro du serveur 1. C'est le même scp qu'à la semaine 4, dans l'autre sens : la source est sur votre poste, la destination est le dossier dump/ du nœud.

scp affiche la barre de progression de l'archive 401 jusqu'à 100 %

Étape 9 — Envoyer l'archive du serveur de données

PowerShell
scp .\vzdump-qemu-403-*.vma.zst root@10.70.44.#:/var/lib/vz/dump/

Remplacez # par le numéro du serveur 2.

Étape 10 — Envoyer l'archive de la caisse

PowerShell
scp .\vzdump-qemu-402-*.vma.zst root@10.70.44.#:/var/lib/vz/dump/

Remplacez # par le numéro du serveur 3.

Étape 11 — Restaurer le pare-feu

Sur le serveur 1, sélectionnez local (pve#) puis l'onglet Backups. L'archive déposée par scp apparaît dans la liste. Sélectionnez-la et cliquez sur Restore.

Champ Valeur
Storage From backup configuration
VM 401
Unique décoché
Start after restore coché

La fenêtre Restore: VM avec l'identifiant 401 et la case Start after restore cochée

Cliquez sur Restore. Le journal se termine sur TASK OK, et la VM 401 démarre.

Le pare-feu revient avec ses trois cartes, sur les VLAN 460, 20 et 30, et avec toutes ses règles. Les cartes sont décrites dans la configuration de la VM, et les règles dans le disque d'OPNsense : l'archive contient les deux.

Étape 12 — Restaurer le serveur de données

Sur le serveur 2, même manipulation avec l'archive vzdump-qemu-403-… et l'identifiant 403.

Le journal de restauration de la VM 403 se termine sur TASK OK

Étape 13 — Restaurer la caisse

Sur le serveur 3, même manipulation avec l'archive vzdump-qemu-402-… et l'identifiant 402.

La caisse était un clone lié du template 9000, et ce template n'existe plus. La restauration fonctionne quand même : l'archive contient le disque complet, tel que la VM le voyait.

Étape 14 — Rebrancher votre poste dans le VLAN 20

Branchez la seconde carte réseau de votre poste sur le port d'accès GigabitEthernet1/0/5 du switch. Lancez MakeMeAdmin, puis ouvrez PowerShell en tant qu'administrateur.

Reprenez le nom exact de la seconde carte, tel qu'ipconfig l'affiche, à la place de Ethernet 2. Ce sont les trois commandes de la semaine 4 : remise en DHCP, métrique élevée, redémarrage de la carte.

PowerShell
netsh interface ipv4 set address name="Ethernet 2" dhcp
PowerShell
Set-NetIPInterface -InterfaceAlias "Ethernet 2" -InterfaceMetric 500
PowerShell
Restart-NetAdapter -Name "Ethernet 2"
PowerShell
ipconfig
Texte
Carte Ethernet Ethernet :

   Adresse IPv4. . . . . . . . . . . . . .: 10.80.X.Y
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Passerelle par défaut. . . . . . . . . : 10.80.X.1

Carte Ethernet Ethernet 2 :

   Adresse IPv4. . . . . . . . . . . . . .: 192.168.20.100
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Passerelle par défaut. . . . . . . . . : 192.168.20.1

La sortie est abrégée, et vos noms de cartes et vos adresses seront différents.

La seconde carte reçoit une adresse entre 192.168.20.100 et 192.168.20.199, distribuée par le pare-feu restauré.

Si elle reste en 169.254.x.x, votre pare-feu a été sauvegardé avant l'activation de son serveur DHCP. Ouvrez la console de la VM 401, tapez 2, choisissez l'interface LAN, gardez 192.168.20.1/24, et répondez y au serveur DHCP avec la plage 192.168.20.100 à 192.168.20.199. Relancez ensuite Restart-NetAdapter.

Étape 15 — Redonner au poste le chemin de la DMZ

PowerShell
route -p add 192.168.30.0 mask 255.255.255.0 192.168.20.1

La commande répond OK!.

Étape 16 — Ouvrir la caisse

Depuis votre poste, ouvrez http://192.168.30.10.

Le navigateur affiche la caisse de Cyclo-Nord avec son catalogue

Vous n'avez écrit aucune règle de pare-feu, aucune adresse, aucune commande docker. Tout était dans les trois archives.

Étape 17 — Retrouver les ventes de la semaine 4

Ouvrez la console de srv-donnees et connectez-vous avec etudiant / Motdepasse123!.

Bash
sudo docker exec db mariadb -upos -p'Motdepasse123!' pos -e "SELECT id, boutique, total FROM ventes;"

La table ventes contient les ventes encaissées à la semaine 4

Les ventes encaissées la semaine dernière sont là. Les serveurs ont été effacés entre-temps : ces lignes ont survécu uniquement parce qu'une archive existait ailleurs que sur leur disque.

Vérification finale

  • show vlan brief liste les VLAN 10, 20, 30, 460 et 700
  • bridge vlan show affiche les VLAN 10, 20, 30 et 460 sur la carte physique de chaque serveur
  • Les VM 401, 402 et 403 tournent, chacune sur son serveur
  • http://192.168.30.10 affiche la caisse depuis votre poste
  • La table ventes contient les ventes de la semaine 4

Question 1

Vous restaurez la caisse sans avoir recréé le snippet serveur.yaml. Que se passe-t-il ?

  • a) La VM démarre, mais Docker n'est plus installé.
  • b) La VM refuse de démarrer, parce que sa configuration désigne un fichier absent du nœud.
  • c) La restauration échoue, parce que l'archive est incomplète.
Voir la réponse **b) La VM refuse de démarrer, parce que sa configuration désigne un fichier absent du nœud.** Proxmox fabrique le lecteur cloud-init à chaque démarrage, à partir de la configuration de la VM. La ligne `cicustom` lui demande d'y inclure `serveur.yaml` : s'il ne trouve pas le fichier, il s'arrête sur `volume 'local:snippets/serveur.yaml' does not exist`. Le choix a) suppose que Docker vient du snippet à chaque démarrage. Docker est installé dans le disque depuis la semaine 4, et l'archive l'a conservé. Le snippet ne sert plus à rien installer, mais Proxmox exige quand même qu'il existe.

En cas de problème

Symptôme Cause probable Correction
scp affiche REMOTE HOST IDENTIFICATION HAS CHANGED Le serveur a été réinstallé et porte une nouvelle clé SSH ssh-keygen -R 10.70.44.#, puis relancer scp
L'archive n'apparaît pas dans Backups Elle a été envoyée sur un autre serveur, ou dans un autre dossier ls /var/lib/vz/dump/ dans le Shell du nœud
volume 'local:snippets/serveur.yaml' does not exist Snippet absent sur ce nœud Étapes 5 et 6 sur ce serveur
La VM démarre mais ne joint pas sa passerelle vmbr0 n'est pas VLAN aware, ou le VLAN manque dans bridge-vids Étapes 3 et 4
La caisse affiche « base de données injoignable » srv-donnees démarre encore, ou le conteneur db est arrêté Attendre une minute, puis sudo docker ps sur srv-donnees
https://192.168.20.1 ne répond pas depuis le poste Seconde carte sans adresse du VLAN 20, ou câble sur le mauvais port ipconfig, puis show interfaces status sur le switch
Plus d'accès à Internet ni à Proxmox depuis le poste Métrique de la seconde carte non relevée Set-NetIPInterface -InterfaceAlias "Ethernet 2" -InterfaceMetric 500