Aller au contenu

Exercice 3 — Le réseau de Cyclo-Nord

Durée : ~90 min · En équipe · Prérequis : les exercices 1 et 2 de la semaine

Le mandat

Cyclo-Nord est une boutique de vélos à trois succursales. Jusqu'ici, tout tenait sur un vieux poste dans l'arrière-boutique. La propriétaire veut passer à autre chose et vous confie deux demandes.

  1. Une caisse web, que les employés ouvrent dans un navigateur depuis n'importe quel poste de la boutique.
  2. Une règle qu'elle répète à chaque réunion : « les ventes passent par la caisse, jamais personne ne touche la base de données directement. »

Ces deux demandes tirent dans des sens opposés. La caisse doit être ouverte à tous les postes du magasin, et c'est justement ce qui en fait la machine la plus fragile du parc : une application web que tout le monde utilise est la première chose qui se fait pirater. Vous allez donc couper la caisse en deux : l'interface web dans une zone isolée, sa base de données à l'abri, et un seul port ouvert entre les deux.

Objectif

Monter l'infrastructure sur les serveurs de votre équipe : un pare-feu OPNsense à trois pattes, deux réseaux internes, et une caisse web joignable depuis votre poste dont la base de données n'est atteignable que sur un seul port.

Prérequis

  • L'exercice 1 terminé : le switch d'équipe transporte les VLAN 20, 30 et 460.
  • L'exercice 2 terminé sur chaque serveur de l'équipe : le template 9000 existe partout.
  • Le numéro du serveur qui hébergera le pare-feu, noté #.
  • La seconde carte réseau de votre poste branchée sur un port d'accès en VLAN 20 de votre switch (exercice 1, étape 9).
  • L'image docker de la caisse publiée par votre enseignant : migrc/cyclonord-pos:1.0.

Ce que vous construisez

flowchart TB
    NET["Internet"] --- TOR["Réseau du collège<br/>VLAN 460"]
    TOR ---|206.167.46.#| R["fw-cyclonord<br/>OPNsense<br/>3 cartes"]
    R ---|192.168.20.1| L20{{"LAN · VLAN 20"}}
    R ---|192.168.30.1| L30{{"DMZ · VLAN 30"}}
    L20 --- S["srv-donnees<br/>192.168.20.10"]
    L20 --- PC["Votre poste<br/>seconde carte<br/>DHCP .100 à .199"]
    L30 --- W["caisse<br/>192.168.30.10"]
    W -. "3306 seulement" .-> S
VM ID Serveur VLAN Adresse Rôle chez Cyclo-Nord
fw-cyclonord 401 serveur 1 460 / 20 / 30 206.167.46.#, .20.1, .30.1 la porte d'entrée
srv-donnees 403 serveur 2 20 192.168.20.10/24 la base de données des ventes
caisse 402 serveur 3 30 192.168.30.10/24 l'interface web des ventes

Les trois VM se répartissent sur les serveurs de l'équipe. C'est volontaire : le trafic entre elles traverse réellement le switch physique que vous avez configuré à l'exercice 1. Si votre équipe n'a que deux serveurs, placez caisse sur le serveur 2. Si elle n'en a qu'un, les trois VM vont sur ce serveur, et toutes les étapes se font sur lui.

Le VLAN 10 bureaux existe sur le switch depuis l'exercice 1, mais il reste vide aujourd'hui : le pare-feu n'a que trois pattes.

Le client, c'est votre poste de travail, par sa seconde carte réseau branchée dans le VLAN 20. Il est donc à l'intérieur du réseau de l'entreprise, exactement là où se trouve l'employé qui encaisse une vente. C'est aussi par là que vous administrerez le pare-feu : un pare-feu ne s'administre pas depuis Internet.

Sa première carte reste sur le réseau du collège, en 10.80.X.Y. Vous n'y touchez pas : c'est elle qui porte votre accès à Internet et à l'interface web de Proxmox.

Le pare-feu porte une adresse publique

La patte vtnet0 est directement sur Internet, sans rien devant elle. Rien de ce que vous montez aujourd'hui n'y sera publié : tout se passe du côté interne. N'ouvrez aucun port sur cette interface.

Étape 1 — Télécharger l'image d'OPNsense

OPNsense est un pare-feu basé sur FreeBSD, qui se configure entièrement dans un navigateur. C'est le même produit que celui qu'on trouve dans beaucoup de PME. Sur un routeur Linux, les mêmes règles s'écriraient à la main dans /etc/nftables.conf.

Sur le serveur 1, ouvrez le Shell du nœud. Allez chercher le lien de l'image DVD amd64 sur la page de téléchargement d'OPNsense, puis adaptez la commande.

Bash
cd /var/lib/vz/template/iso
Bash
wget https://pkg.opnsense.org/releases/26.7/OPNsense-26.7-dvd-amd64.iso.bz2

Le fichier arrive compressé. Proxmox ne sait pas monter un .bz2, il faut donc le décompresser.

Bash
bunzip2 OPNsense-26.7-dvd-amd64.iso.bz2
Bash
ls -lh OPNsense-*.iso

L'ISO décompressée fait environ 2 Go

Note

Le numéro de version change deux fois par an. Reprenez le nom exact du fichier que vous avez téléchargé dans toutes les commandes qui suivent.

Étape 2 — Créer la VM du pare-feu

Le pare-feu ne sort pas du template Debian : ce n'est pas un Linux, et il s'installe depuis son ISO. Créez-le en une commande, avec ses trois cartes réseau.

Bash
qm create 401 --name fw-cyclonord --memory 2048 --cores 2 --ostype other \
  --scsihw virtio-scsi-single --scsi0 local-lvm:32 \
  --ide2 local:iso/OPNsense-26.7-dvd-amd64.iso,media=cdrom \
  --boot 'order=ide2;scsi0' \
  --net0 virtio,bridge=vmbr0,tag=460 \
  --net1 virtio,bridge=vmbr0,tag=20 \
  --net2 virtio,bridge=vmbr0,tag=30

Le \ en fin de ligne dit au shell que la commande continue à la ligne suivante.

Ouvrez le panneau Hardware de la VM 401 pour vérifier le résultat.

Le panneau Hardware affiche trois cartes réseau avec les tags 460, 20 et 30

Trois cartes sur le même bridge. C'est l'étiquette VLAN, et elle seule, qui envoie chacune dans un réseau différent. OPNsense verra trois cartes ordinaires et ne saura jamais que les VLAN existent.

Important

L'ordre des cartes décide du nom qu'elles porteront dans FreeBSD : net0 devient vtnet0, net1 devient vtnet1, net2 devient vtnet2. Toute la suite de l'exercice repose sur cette correspondance.

Étape 3 — Installer OPNsense

Démarrez la VM et ouvrez sa Console. Le système démarre en mode live, ce qui prend une minute, puis affiche une invite de connexion.

Connectez-vous avec l'utilisateur installer et le mot de passe opnsense. L'installateur se lance de lui-même.

Écran Réponse
Keymap laissez la disposition par défaut, Continue
Mode d'installation Install (UFS)
Disque le seul proposé, da0
Confirmation de l'effacement Yes
Mot de passe root Motdepasse123!, deux fois
Fin Complete Install

L'écran de choix du mode d'installation avec Install (UFS) sélectionné

La VM redémarre. Retirez l'ISO pendant qu'elle redémarre, depuis le Shell du nœud :

Bash
qm set 401 --ide2 none,media=cdrom

Étape 4 — Assigner les trois interfaces

Au redémarrage, la console affiche un menu numéroté. OPNsense a deviné deux interfaces sur trois, mais il faut lui dire quoi faire de la troisième.

Tapez 1 pour Assign interfaces, puis répondez :

Question Réponse
Configure LAGGs? n
Configure VLANs? n
WAN interface name vtnet0
LAN interface name vtnet1
Optional interface 1 vtnet2
Optional interface 2 (Entrée, pour terminer)
Do you want to proceed? y

Le menu de console affiche WAN sur vtnet0, LAN sur vtnet1 et OPT1 sur vtnet2

Répondre n à la question sur les VLAN peut surprendre. C'est pourtant correct : les étiquettes sont posées et retirées par le bridge de Proxmox, avant que la trame n'arrive dans la VM. OPNsense reçoit trois liens ordinaires.

Étape 5 — Donner une adresse à chaque interface

Tapez 2 pour Set interface IP address, et recommencez trois fois, une par interface.

Interface Adresse Masque Passerelle DHCP serveur
WAN (vtnet0) 206.167.46.# 24 206.167.46.1 non
LAN (vtnet1) 192.168.20.1 24 (aucune) oui, de 192.168.20.100 à 192.168.20.199
OPT1 (vtnet2) 192.168.30.1 24 (aucune) non

Remplacez # par le numéro du serveur qui héberge le pare-feu. Répondez n aux questions sur IPv6 et sur le retour à HTTP.

Pour le serveur DHCP, répondez n sur le WAN et la DMZ. Sur le LAN, répondez y, puis donnez 192.168.20.100 comme première adresse et 192.168.20.199 comme dernière. C'est ce serveur DHCP qui donnera une adresse à votre poste à l'étape suivante.

Le menu de console affiche les trois interfaces avec leurs adresses

Une seule passerelle, sur le WAN. Un routeur n'a qu'une sortie par défaut : celle qui mène à Internet. Les deux autres réseaux, il les atteint directement, puisqu'il a une patte dedans.

Étape 6 — Entrer dans le réseau de l'entreprise

L'interface web d'OPNsense n'écoute que sur le LAN. Un pare-feu neuf ne se laisse administrer que de l'intérieur, et c'est exactement le comportement voulu.

Branchez la seconde carte réseau de votre poste sur le port d'accès GigabitEthernet1/0/5 de votre switch. L'équipe n'en a qu'un : les membres s'y relaient, et celui qui est branché administre le pare-feu pour les autres.

Les commandes qui suivent modifient la configuration réseau du poste, donc elles demandent les droits d'administrateur. Lancez MakeMeAdmin pour les obtenir le temps de la manipulation, puis ouvrez PowerShell en tant qu'administrateur.

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 de configuration automatique: 169.254.83.17
   Masque de sous-réseau. . . . . . . . . : 255.255.0.0
   Passerelle par défaut. . . . . . . . . :

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

Deux cartes apparaissent, et leur nom change d'un poste à l'autre : parfois Ethernet, parfois Ethernet 2. Ne vous fiez pas au nom, fiez-vous à l'adresse.

  • Celle qui porte une adresse en 10.80.X.Y est la carte du collège. Vous n'y touchez pas.
  • L'autre est celle que vous venez de brancher. Elle affiche souvent une adresse IPv4 automatique en 169.254.x.x : elle a demandé une adresse avant que le serveur DHCP du pare-feu existe, et Windows lui a donné une adresse de dépannage qui ne mène nulle part. Elle peut aussi porter une adresse fixe laissée par un autre groupe.

Relevez le nom exact de cette seconde carte, tel qu'ipconfig l'écrit après « Carte Ethernet », et reprenez-le dans les trois commandes suivantes à la place de Ethernet 2.

Remettez la carte en DHCP :

PowerShell
netsh interface ipv4 set address name="Ethernet 2" dhcp

Si la carte était déjà en DHCP, la commande répond que le DHCP est déjà activé. C'est normal, rien n'a changé.

Donnez à la carte une métrique élevée :

PowerShell
Set-NetIPInterface -InterfaceAlias "Ethernet 2" -InterfaceMetric 500

Le serveur DHCP du pare-feu donne aussi une passerelle à la carte, 192.168.20.1. Votre poste a alors deux routes par défaut : celle du collège et celle du pare-feu. Windows emprunte celle dont la métrique est la plus basse. Avec 500, la carte du collège reste la sortie par défaut, et votre accès à Internet et à l'interface web de Proxmox ne change pas.

Redémarrez la carte, pour qu'elle demande son adresse tout de suite :

PowerShell
Restart-NetAdapter -Name "Ethernet 2"

Sans ce redémarrage, Windows ne redemande une adresse qu'au bout de quelques minutes.

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 doit montrer vos deux cartes :

Carte Adresse Passerelle
Celle du collège 10.80.X.Y celle du collège
La seconde entre 192.168.20.100 et 192.168.20.199 192.168.20.1

Chaque poste reçoit sa propre adresse du pare-feu : deux postes ne peuvent pas prendre la même.

Votre poste est maintenant dans le VLAN 20, du bon côté du pare-feu. Ouvrez https://192.168.20.1. Le certificat est auto-signé, donc le navigateur affiche un avertissement : passez outre. Connectez-vous avec root et Motdepasse123!.

Vous n'avez écrit aucune règle, et pourtant la page répond. OPNsense pose d'office deux choses sur son interface LAN : une autorisation de sortie vers tout, et une règle dite anti-lockout qui garantit l'accès à sa propre interface d'administration. Sans elle, la première erreur de règle vous enfermerait dehors.

Étape 7 — Ouvrir le tableau de bord

OPNsense propose son assistant de configuration au premier démarrage. Vous n'en avez pas besoin : tout ce qu'il demande est déjà fait. Cliquez sur Abort pour l'abandonner et arriver au tableau de bord.

L'assistant de configuration d'OPNsense avec les boutons Next et Abort

Regardez le bandeau bleu en haut de cette page. S'il annonce live media mode, la VM a redémarré sur l'ISO au lieu de son disque, et toute votre configuration sera perdue au prochain redémarrage. Retirez l'ISO comme à l'étape 3, puis redémarrez la VM et reprenez depuis l'étape 4.

Allez voir Firewall > Rules > WAN. La liste est vide.

C'est la première leçon du pare-feu : tout ce qui n'est pas écrit est interdit. Personne, depuis Internet, ne peut joindre quoi que ce soit derrière cette machine, et il n'y a rien à faire pour obtenir ce résultat. C'est l'état de départ.

Étape 8 — Nommer la DMZ

Un pare-feu dont les interfaces s'appellent OPT1 et OPT2 devient illisible en trois semaines.

Allez dans Interfaces > [OPT1], cochez Enable Interface, et remplacez la description par DMZ.

Le menu Interfaces affiche maintenant WAN, LAN et DMZ

Save, puis Apply changes. Le menu de gauche affiche maintenant DMZ, et c'est ce nom qui servira dans les règles.

Étape 9 — Vérifier le NAT sortant

Allez dans Firewall > NAT > Source Nat.

Le mode est réglé sur Automatic Source NAT rule generation et les deux réseaux internes apparaissent dans la liste grisée

Le mode automatique est actif par défaut. OPNsense a créé de lui-même une règle pour chaque réseau qu'il porte : les machines du LAN et de la DMZ sortiront sur Internet avec l'adresse publique du pare-feu, et le serveur distant ne verra jamais la leur.

Cette réécriture de l'adresse source s'appelle le masquerade. C'est ce que fait aussi votre routeur à la maison. Sur un routeur Linux, il aurait fallu écrire la règle à la main.

Étape 10 — Écrire les règles de la DMZ

Allez dans Firewall > Rules > DMZ. La liste est vide : la DMZ ne peut donc rien faire du tout, pas même sortir sur Internet. Il faut deux règles, dans cet ordre.

Première règle, avec le + :

Champ Valeur
Action Block
Direction in
Source DMZ net
Destination LAN net
Description dmz ne parle pas au lan

Seconde règle :

Champ Valeur
Action Pass
Direction in
Source DMZ net
Destination any
Description dmz vers internet

Apply changes.

Les deux règles de la DMZ, le blocage vers le LAN au-dessus de l'autorisation vers Internet

L'ordre décide de tout. OPNsense lit la liste de haut en bas et s'arrête à la première ligne qui correspond. Le blocage est au-dessus, donc un paquet vers le LAN est jeté avant même d'atteindre la règle qui autorise « tout ». Inversez les deux lignes et la DMZ aurait accès à vos données.

Étape 11 — Préparer le snippet des serveurs

Les deux machines de Cyclo-Nord feront tourner leurs services dans des conteneurs Docker, et c'est cloud-init qui va l'installer.

Faites cette étape sur les serveurs 2 et 3, puisque chacun hébergera une de ces VM.

Bash
nano /var/lib/vz/snippets/serveur.yaml
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

Quelques lignes de plus que le fichier agent.yaml de l'exercice 2, et la VM arrivera avec Docker installé, démarré et prêt à l'emploi. C'est toute l'idée de cloud-init : la machine naît dans l'état où vous en avez besoin.

Note

Docker fait l'objet des semaines 8 à 10. Pour aujourd'hui, servez-vous en sans chercher à comprendre ce qu'il fait : retenez seulement qu'une commande docker run télécharge un logiciel déjà installé et le démarre.

Étape 12 — Déployer le serveur de données

C'est la machine qui garde ce qui ne doit pas sortir : la base de données des ventes.

Sur le serveur 2, clic droit sur le template 9000 puis Clone, et reprenez les mêmes fenêtres qu'à l'exercice 2 avec ces valeurs.

Fenêtre Champ Valeur
Clone VM ID 403
Clone Name srv-donnees
Clone Mode Linked Clone
Network Device (net0) VLAN Tag 20
IP Config (net0) IPv4/CIDR 192.168.20.10/24
IP Config (net0) Gateway 192.168.20.1

Le panneau Cloud-Init de srv-donnees avec l'adresse 192.168.20.10 et sa passerelle

Rattachez le snippet des serveurs depuis le Shell du serveur 2 :

Bash
qm set 403 --cicustom "vendor=local:snippets/serveur.yaml"

Démarrez la VM.

Étape 13 — Vérifier le travail de cloud-init

Ouvrez la console de srv-donnees et connectez-vous avec etudiant / Motdepasse123!. Le premier démarrage prend une minute ou deux : la VM télécharge Docker à travers le pare-feu que vous venez de construire.

Bash
ping -c 2 192.168.20.1
Bash
curl -s https://api.ipify.org

La passerelle répond, et le service renvoie l'adresse publique du pare-feu

Ces deux commandes valident tout le travail des étapes précédentes. La VM sort d'un réseau privé, traverse le switch physique, passe par le pare-feu, et revient.

La seconde mérite un arrêt. La VM a l'adresse 192.168.20.10, et Internet voit 206.167.46.# : c'est le NAT sortant de l'étape 9, qui a remplacé l'adresse source. Comparez avec l'exercice 3 de la semaine 3, où le conteneur voyait sa propre adresse revenir.

Vérifiez ensuite que Docker est arrivé :

Bash
docker version

Docker répond avec sa version pour le client et pour le serveur

Vous n'avez rien installé. Quelques lignes dans un fichier YAML, écrites avant même que la machine existe, et elle démarre avec Docker en service. Si cette commande échoue, cloud-init n'a pas pu télécharger le paquet, et c'est donc le réseau qu'il faut regarder en premier.

Étape 14 — Lancer la base de données des ventes

Bash
 docker run -d --name db --restart unless-stopped \
  -p 3306:3306 \
  -e 'MARIADB_ROOT_PASSWORD=Motdepasse123!' \
  -e MARIADB_DATABASE=pos \
  -e MARIADB_USER=pos \
  -e 'MARIADB_PASSWORD=Motdepasse123!' \
  -v db-data:/var/lib/mysql \
  mariadb:11

L'option -p 3306:3306 publie le port de la base sur la carte réseau de la VM. Sans elle, la base ne serait joignable que depuis la VM elle-même, et la caisse ne pourrait jamais l'atteindre.

Bash
 docker ps

Le conteneur db apparaît avec le statut Up et le port 3306 publié

Étape 15 — Déployer la caisse

Sur le serveur 3, mêmes fenêtres, avec ces valeurs.

Fenêtre Champ Valeur
Clone VM ID 402
Clone Name caisse
Clone Mode Linked Clone
Network Device (net0) VLAN Tag 30
IP Config (net0) IPv4/CIDR 192.168.30.10/24
IP Config (net0) Gateway 192.168.30.1

Rattachez le snippet depuis le Shell du serveur 3 :

Bash
qm set 402 --cicustom "vendor=local:snippets/serveur.yaml"

Démarrez la VM, ouvrez sa console et connectez-vous.

Étape 16 — Lancer l'interface de caisse

Bash
sudo docker run -d --name caisse --restart unless-stopped \
  -p 80:8080 \
  -e POS_BOUTIQUE="Succursale centre-ville" \
  -e POS_DB_HOST=192.168.20.10 \
  -e 'POS_DB_PASSWORD=Motdepasse123!' \
  migrc/cyclonord-pos:1.0

Le nom de la succursale s'affichera en haut de l'écran.

Deux options portent tout le sens de cette commande. -p 80:8080 rend l'interface visible sur le réseau. POS_DB_HOST=192.168.20.10 dit à la caisse que sa base de données n'est pas sur la même machine : elle est de l'autre côté du pare-feu, dans le LAN.

Étape 17 — Constater que la caisse ne démarre pas vraiment

Bash
curl -s -o /dev/null -w '%{http_code}\n' localhost

La commande affiche 503

Un code 503 veut dire que le service est là, mais qu'il ne peut pas travailler. Regardez ce qu'il en dit :

Bash
curl -s localhost | grep -A2 injoignable

La page affiche que la base de données 192.168.20.10:3306 est injoignable

La caisse tourne, la base tourne, les deux ont une adresse correcte. Ce qui manque, c'est l'autorisation de se parler : votre règle de blocage jette tout ce qui va de la DMZ vers le LAN, sans regarder le port.

Étape 18 — Ouvrir un seul port entre la DMZ et les données

Retournez dans Firewall > Rules > DMZ et ajoutez une règle aussi étroite que possible : une machine, un port, un sens.

Champ Valeur
Action Pass
Protocol TCP
Source DMZ net
Destination Single host or Network, 192.168.20.10/32
Destination port range 3306
Description caisse vers sa bd

Il reste à la remonter au-dessus de la règle de blocage, avec la flèche à droite de la ligne, puis Apply changes.

La règle du port 3306 est en première position, au-dessus du blocage vers le LAN

Revenez dans la console de la caisse et réessayez :

Bash
curl -s -o /dev/null -w '%{http_code}\n' localhost

La commande affiche maintenant 200

C'est le principe du moindre privilège. On n'a pas relié les deux réseaux : on a ouvert une porte de la taille exacte du besoin.

Étape 19 — Vérifier ce que la caisse n'a pas le droit de faire

C'est la demande de la propriétaire, et c'est le moment de la vérifier. Toujours depuis la caisse, essayez deux ports sur la machine dont elle lit la base de données depuis cinq minutes.

Bash
nc -zv -w 5 192.168.20.10 3306
Bash
nc -zv -w 5 192.168.20.10 22

Le port 3306 répond succeeded, le port 22 expire après cinq secondes

Même machine, même réseau, même pare-feu. La seule différence, c'est le port.

C'est toute la raison d'être de la DMZ. Une interface web ouverte à tous les postes du magasin est la machine la plus fragile du parc ; le jour où elle est compromise, l'attaquant hérite d'un accès à une base de ventes sur un seul port, et de rien d'autre.

Étape 20 — Donner au poste le chemin de la DMZ

Votre poste connaît 192.168.20.0/24, puisqu'il a une carte dedans. La caisse, elle, est dans 192.168.30.0/24, un réseau dont il n'a jamais entendu parler. Sans rien faire, il enverrait le paquet à sa passerelle par défaut, celle du collège, qui jetterait une adresse privée qu'elle ne sait pas router.

Dans PowerShell administrateur :

PowerShell
route -p add 192.168.30.0 mask 255.255.255.0 192.168.20.1

La commande répond OK!. Vous venez de dire à votre poste une seule chose : pour ce réseau-là, et pour lui seul, passe par le pare-feu. Tout le reste continue de sortir par le collège.

C'est exactement ce que fait une table de routage, sur un poste comme sur un routeur : une liste de destinations, et pour chacune, à qui remettre le paquet.

Bash
route print 192.168.30.0
Texte
Itinéraires actifs :
Destination réseau    Masque réseau  Adr. passerelle   Adr. interface  Métrique
     192.168.30.0    255.255.255.0     192.168.20.1   192.168.20.100    ...
===========================================================================
Itinéraires persistants :
  Adresse réseau    Masque réseau  Adresse passerelle  Métrique
     192.168.30.0    255.255.255.0     192.168.20.1        1

La ligne apparaît avec 192.168.20.1 comme passerelle et votre seconde carte comme interface.

Étape 21 — Ouvrir la caisse depuis votre poste

Depuis votre poste de travail, ouvrez http://192.168.30.10 dans un navigateur. Forcez le protocole http et non https : la caisse n'écoute que sur le port 80.

Le navigateur affiche la caisse de Cyclo-Nord avec son catalogue et le nom de la succursale

La page s'affiche du premier coup, et vous n'avez écrit aucune règle pour ça. Votre poste est dans le LAN, et le LAN a le droit d'aller partout.

Comparez avec la DMZ. Sa liste de règles, vous l'avez remplie ligne par ligne, et elle ne contient toujours que trois autorisations étroites. Deux réseaux derrière le même pare-feu, deux traitements opposés : on fait confiance à celui où sont les employés, et on se méfie de celui où est la machine que tout le monde utilise.

Notez qu'aucune des deux n'est joignable depuis Internet. La liste WAN est restée vide.

Étape 22 — Encaisser une vente

Ajoutez un vélo et un casque au panier, puis cliquez sur Encaisser.

Le panier affiche les deux articles, le sous-total, la TPS, la TVQ et le total

Le panier se vide et un bandeau vert annonce le numéro de la vente et son montant.

Le bandeau vert annonce la vente numéro 1 enregistrée avec son total

Suivez le chemin de ce clic : votre navigateur, dans le LAN, a joint une machine de la DMZ en traversant le pare-feu ; celle-ci a ouvert une connexion vers le port 3306 d'une machine du LAN, et la vente est écrite sur un disque qui n'est joignable ni depuis Internet, ni depuis la machine qui vient de l'utiliser pour autre chose que ce port.

Vérifiez-le sur srv-donnees :

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

La vente apparaît dans la base avec le nom de la succursale et son total

Vérification finale

  • ipconfig montre une adresse entre 192.168.20.100 et .199 sur la seconde carte, et le réseau du collège intact sur l'autre
  • https://192.168.20.1 ouvre l'interface d'OPNsense depuis votre poste
  • curl https://api.ipify.org depuis srv-donnees renvoie l'adresse publique du pare-feu
  • La caisse joint la base sur le port 3306, mais pas le port 22 de la même machine
  • http://192.168.30.10 affiche la caisse de votre succursale depuis votre navigateur
  • Firewall > Rules > WAN est toujours vide
  • Une vente encaissée depuis le navigateur apparaît dans la table ventes

Question 1

Vous inversez les deux règles de la DMZ : l'autorisation vers any passe au-dessus du blocage vers le LAN. Que se passe-t-il ?

  • a) Rien, les deux règles sont toujours présentes.
  • b) La DMZ atteint le LAN entier, parce qu'OPNsense s'arrête à la première règle qui correspond.
  • c) Le pare-feu refuse d'appliquer la configuration, parce que les deux règles se contredisent.
Voir la réponse **b) La DMZ atteint le LAN entier, parce qu'OPNsense s'arrête à la première règle qui correspond.** Un paquet de la caisse vers `192.168.20.10` correspond à « source DMZ net, destination any » : il est accepté, et la règle de blocage placée en dessous n'est jamais lue. Le blocage existe toujours dans la liste, mais il ne sert plus à rien. Le choix c) prête au pare-feu une vérification qu'il ne fait pas. Un jeu de règles contradictoire est parfaitement valide : c'est l'ordre, et lui seul, qui tranche.

Question 2

La caisse joint 192.168.20.10 sur le port 3306, mais pas sur le port 22. Pourquoi cette différence, alors que c'est la même machine ?

  • a) Parce que le serveur SSH de srv-donnees n'accepte que les connexions locales.
  • b) Parce que la règle de l'étape 18 nomme un port précis, et que tout ce qu'elle ne nomme pas retombe sur la règle de blocage juste en dessous.
  • c) Parce que le port 22 est déjà utilisé par la caisse elle-même.
Voir la réponse **b) Parce que la règle de l'étape 18 nomme un port précis, et que tout ce qu'elle ne nomme pas retombe sur la règle de blocage juste en dessous.** Une règle de pare-feu n'ouvre que ce qu'elle décrit. Celle-ci décrit une adresse de destination et un port : le trafic vers le port 22 de cette même machine ne lui correspond pas, continue sa descente dans la liste, et rencontre le blocage. Le choix a) prête au serveur SSH une décision qui n'est pas la sienne. Il écoute très bien sur toutes les interfaces : c'est le pare-feu, et lui seul, qui décide qui a le droit de lui parler.

En cas de problème

Symptôme Cause probable Correction
https://192.168.20.1 ne répond pas Le poste n'est pas dans le VLAN 20, ou le pare-feu n'a pas d'adresse sur son LAN Vérifier ipconfig, puis l'étape 5 par la console de la VM
Les interfaces s'appellent em0, em1 Les cartes ne sont pas en virtio Les repasser en virtio dans Hardware, puis refaire l'étape 4
Une VM ne joint pas sa passerelle VLAN absent de bridge-vids sur son nœud Étape 13 de l'exercice 1
sudo docker version échoue sur la VM cloud-init n'a pas pu télécharger le paquet Vérifier ping 9.9.9.9 depuis la VM, puis recloner
La caisse n'a pas Internet au démarrage La règle « dmz vers internet » manque ou est sous le blocage Étape 10, vérifier l'ordre
docker: permission denied Le sudo a été oublié Reprendre la commande avec sudo
La caisse affiche « base de données injoignable » Règle du port 3306 absente, mal placée, ou conteneur db arrêté Étape 18, puis sudo docker ps sur srv-donnees
La caisse répond 500 après l'ouverture du port Mot de passe de la base différent des deux côtés Comparer MARIADB_PASSWORD et POS_DB_PASSWORD
https://192.168.20.1 ne répond pas depuis le poste Carte sans adresse du VLAN 20, ou port du switch en trunk au lieu d'accès ipconfig, puis l'étape 9 de l'exercice 1
La seconde carte reste en 169.254.x.x DHCP non activé sur le LAN du pare-feu, ou carte pas redémarrée Étape 5 par la console de la VM, puis Restart-NetAdapter
La seconde carte affiche « Média déconnecté » Câble absent, ou branché sur un port non configuré Vérifier le port sur le switch, show interfaces status
La caisse ne répond pas mais le pare-feu oui Route vers la DMZ absente Refaire l'étape 20, vérifier avec route print 192.168.30.0
Plus d'accès à Internet ni à Proxmox depuis le poste La seconde carte a gardé sa métrique automatique et sa passerelle passe en premier Set-NetIPInterface -InterfaceAlias "Ethernet 2" -InterfaceMetric 500
Le pare-feu oublie tout à chaque redémarrage L'ISO est encore attachée : la VM démarre en live media mode qm set 401 --ide2 none,media=cdrom, redémarrer, refaire les étapes 4 et 5

Nettoyage

Rien n'est exposé sur Internet : la liste des règles WAN est restée vide du début à la fin. Laissez l'infrastructure en place, vous en aurez besoin au TP1.

Sur votre poste, retirez la route et rendez à la seconde carte sa métrique automatique :

PowerShell
route delete 192.168.30.0
PowerShell
Set-NetIPInterface -InterfaceAlias "Ethernet 2" -AutomaticMetric Enabled

Pour aller plus loin

  • Ajoutez un troisième réseau interne : une quatrième carte sur le pare-feu et une interface BUREAUX en 192.168.10.1/24, le VLAN que votre switch transporte déjà sans que personne s'en serve. C'est le travail du TP1.
  • Restreignez l'accès à l'interface d'administration d'OPNsense à votre seule adresse plutôt qu'à tout le LAN.