Documentation — Lab pfSense sous Proxmox

Contexte : BTS SIO — option SISR Auteur : Axel GOUIRAND — BTS SIO option SISR (session 2027) Environnement : Proxmox VE 9.1.2 (serveur pve-01 de l’établissement), pool SIO2527_Axel Date de début : 11/09/2026 Dernière mise à jour : 12/11/2026 (étape 76 : limitation de débit de la zone VISITEURS mesurée, test T21 ; étape 75 : charte informatique écrite, connue, contrôlée ; étape 74 : GPO « poste prêt à l’arrivée », LAPS, SSH par clé, phase 21 ; T-8, T-9, T-23 ; relecture complète des parties « état actuel » : §1 à §3 remis à jour (zone VISITEURS, machines, adresses, systèmes, schéma actuel)) ; 11/11/2026 (étape 73 : portail GLPI des salariés, connexion par l’annuaire en LDAPS ; H-97) ; 10/11/2026 (étape 72 : Matomo et site de GSB en ligne ; H-94 à H-96) ; 06/11/2026 (étapes 68 à 70 : alerte « serveur retiré », inventaire GLPI par entité, alertes → tickets ; étape 67 : LogAnalyzer, journaux bruts en direct, sonde Galera rendue silencieuse ; étape 65.3 : machine restaurée depuis la copie du NAS, phase 13 terminée ; règle « VM absente » réactivée) ; 05/11/2026 (étape 61 : GPO bannière et ping, posées et prouvées en PowerShell ; étape 62 : sonde de synchronisation Galera pour HAProxy, 10.23 ; étape 63 : export SQL nocturne, 13.8 ; étape 64 : site de GSB, public et intranet ; H-84 : lsyncd ; étape 65 : 2e copie hors site sur S3, H-85 ; étape 66 : GLPI, H-86) ; 04/11/2026 (59.7 : bruit des alertes Windows filtré, règles 100210 à 100213) ; 03/11/2026 (étape 59 : Wazuh, serveur de détection d’intrusion, premiers agents et mails (59.8) ; étape 60 : Suricata sur pfSense, zones VISITEURS et USERS, alertes lues par Wazuh (60.6) ; dettes T-17 et T-18) Documents liés : SUIVI-TP.md (avancement) · Matrice-de-flux.md (règles de pare-feu) · Troubleshooting.md (incidents) · Architecture.md (schémas)

Légende des statuts

Seules les étapes sont considérées comme validées. Une étape n’est marquée qu’après vérification effective (capture d’écran ou test réseau à l’appui).

1. Objectif du lab

Mettre en place un pare-feu pfSense en frontal de 5 réseaux virtuels (VLAN) isolés, hébergés sur un hyperviseur Proxmox VE, afin de simuler l’infrastructure d’une PME (le laboratoire GSB, entreprise fictive du BTS SIO). Le projet est parti de 4 VLAN (septembre) ; la zone VISITEURS (VLAN 50) a été ajoutée le 30/10 (étape 55).

État au 12/11/2026 : 15 machines virtuelles (et un modèle de clonage), toutes supervisées et sauvegardées chaque nuit.

pfSense assure : le routage inter-VLAN, le filtrage entre zones, le NAT vers le réseau de l’établissement, le DHCP des VLAN 40 et 50, la résolution DNS de l’ensemble du lab, la détection d’intrusion (Suricata, zones USERS et VISITEURS) et l’accès distant (Tailscale).

Schéma actuel

Vue d’ensemble au 11/11/2026, exportée du schéma schemas/Infrastructure-TP.drawio (7 pages : vue d’ensemble, flux et ports, accès distant, cluster, Pangolin, sauvegarde, supervision).

Schéma initial de septembre (au propre) — historique

Premier schéma (13/09), avant les phases suivantes : il montre encore le WAN en 10.1.0.86, un serveur Guacamole (remplacé par Termix) et un client Debian (abandonné). Gardé pour l’historique.

Schéma manuscrit d'origine

2. Plan d’adressage retenu

2.1 Tableau de référence

L’attribution des adresses à l’intérieur de chaque réseau suit la convention par blocs du §2.4 et le détail du §2.5.

2.2 Justification de l’écart avec le schéma initial

Le schéma manuscrit prévoyait 10.1.10.0, 10.1.20.0, 10.1.30.0, 10.1.40.0. (Les adresses de cette section sont celles de septembre ; le WAN est depuis en adresse fixe 10.1.0.197, étape 15.)

Problème identifié : l’interface WAN reçoit par DHCP l’adresse 10.1.0.86 avec un masque /16. Le réseau de l’établissement couvre donc :

10.1.0.0/16  =  10.1.0.0  →  10.1.255.255

Cette plage contient déjà les quatre sous-réseaux du schéma. pfSense se serait retrouvé avec deux routes concurrentes vers les mêmes adresses (une via le WAN, une via le VLAN). En pratique la règle du longest prefix match fait gagner le /24, mais toute machine réelle de l’établissement située en 10.1.10.x, 10.1.20.x, 10.1.30.x ou 10.1.40.x serait devenue définitivement injoignable depuis le lab.

Correction retenue : bascule sur le préfixe 10.0.X.0/24, qui :

• ne chevauche aucune plage de l’établissement,
• conserve la logique de lecture du schéma (VLAN 20 → 10.0.20.0),
• reste cohérent avec l’adresse LAN déjà en place (10.0.0.1).

2.3 Pourquoi un masque /24 et pas /16

Un masque /16 ne prend en compte que les deux premiers octets :

10.0.10.0 /16  →  réseau 10.0.0.0
10.0.20.0 /16  →  réseau 10.0.0.0     <- identique
10.0.30.0 /16  →  réseau 10.0.0.0     <- identique
10.0.40.0 /16  →  réseau 10.0.0.0     <- identique

Tous les VLAN désigneraient le même réseau. pfSense refuse cette configuration (subnet overlaps with interface LAN), et surtout cela annulerait l’intérêt même du découpage en VLAN : séparer les domaines de diffusion.

Un masque /24 prend en compte les trois premiers octets, ce qui rend chaque VLAN distinct, avec 254 adresses utilisables — largement suffisant pour ce lab.

2.4 Découpage interne de chaque /24 (convention canonique)

Chaque VLAN suit le même découpage par blocs, plutôt qu’une attribution au fil de l’eau :

Pourquoi des blocs ? L’adresse devient auto-documentée. 10.0.30.11 se lit immédiatement « serveur du VLAN 30 » ; 10.0.40.137 se lit « poste client en DHCP ». Cela accélère le diagnostic et permet d’écrire des règles de pare-feu sur des plages plutôt que machine par machine.

2.5 Attribution des adresses

Architecture applicative retenue : 2-tier

Le schéma initial plaçait WordPress dans le VLAN 20 avec MySQL. WordPress étant une application web (PHP + Apache) et non une base de données, les deux couches ont été séparées :

VLAN 10 WEB                        VLAN 20 BDD
┌──────────────────┐               ┌──────────────────┐
│ Apache + PHP     │── 3306 ──────►│ MySQL            │
│ WordPress        │               │ base wp_lab      │
│ 10.0.10.10       │               │ 10.0.20.10       │
└──────────────────┘               └──────────────────┘
   joignable par                      jamais joignable
     les USERS                          par les USERS

Justification : si le site WordPress est compromis — ce qui est fréquent sur un CMS non à jour — l’attaquant obtient un accès dans le VLAN 10. Il ne peut alors atteindre la base que sur le port 3306, et non prendre le contrôle du serveur de données. Les deux couches réunies sur une même machine s’effondreraient ensemble.

C’est également ce qui donne un usage concret à la règle SRV_WEB → SRV_MYSQL : 3306 de la matrice de flux, et un flux inter-VLAN réellement démontrable en phase de tests.

Depuis la phase 10 (étapes 28 à 31) : la même séparation est gardée, mais redondée : deux serveurs web derrière le répartiteur srv-ha, et une base en cluster Galera de trois nœuds. Les serveurs web ne joignent plus la base directement : seul srv-ha le fait (règle SRV_HA → GALERA_NODES : 3306). Voir le schéma, page « Cluster et répartition ».

Conséquence du DHCP désactivé sur les VLAN 10, 20 et 30 : les VM de ces zones ne recevront aucune adresse au démarrage. L’IP doit être saisie manuellement — pendant l’installation pour Debian, après installation pour Windows Server. Une VM sans réseau au premier démarrage dans ces VLAN n’est pas une panne.

2.6 Décisions d’architecture validées

Les dérogations restantes sont des compromis de lab assumés et documentés. Le canon est rappelé en regard afin de pouvoir l’exposer et le justifier.

Architecture DNS : résolveur centralisé

Le réseau de l’établissement présentant des défaillances DNS récurrentes, le réflexe naturel serait de distribuer un résolveur public (8.8.8.8) en secours aux postes clients. Cette approche a été écartée au profit d’une centralisation sur pfSense :

poste-win11 (10.0.40.10)
     │  DNS = 10.0.40.1   ← une seule adresse, jamais modifiée
     ▼
  pfSense / unbound  ──►  1.1.1.1  ou  8.8.8.8
     ▲                    (le secours vit ici)
     │
  cache partagé par toutes les VM, journaux centralisés

Trois raisons de ce choix :

① La cause racine était l’option DNS Server Override. Activée par défaut, elle laisse le bail DHCP du WAN injecter les serveurs de l’établissement (10.1.0.150, 10.2.0.150) dans la liste de pfSense — qui interrogeait donc lui-même les serveurs défaillants. La décocher supprime le problème pour pfSense et pour toutes les VM d’un coup.

② Un DNS public en secours sur les postes casserait l’Active Directory. Interrogé sur SRV-AD.sio.internal, un résolveur public répond — il répond NXDOMAIN, « ce nom n’existe pas ». Windows prend cette réponse pour définitive et ne réessaie pas ailleurs. Ouvertures de session, GPO et réplication deviennent intermittentes selon le serveur interrogé. La recommandation Microsoft est catégorique : une machine membre d’un domaine ne liste que des DNS internes.

③ Le secours ne disparaît pas, il remonte d’un étage. Les postes ne connaissent qu’une adresse ; c’est pfSense qui détient les deux résolveurs publics et bascule de l’un à l’autre. La redondance est conservée, et un changement de fournisseur DNS se fait à un seul endroit sans toucher aucune VM.

Mode Forwarding plutôt que récursif : en récursif, unbound interroge lui-même les serveurs racine puis les TLD — plus autonome, mais multipliant les échanges sortants, donc sensible à un réseau filtrant que l’on ne maîtrise pas. En Forwarding, une seule destination, comportement prévisible. 1.1.1.1 et 8.8.8.8 gérant DNSSEC, la validation reste active.

Aucune règle de pare-feu n’est nécessaire pour que pfSense sorte en DNS : les règles d’interface filtrent ce qui traverse le pare-feu, pas ce qu’il génère lui-même.

Pourquoi sio.internal et pas sio.local

.local est réservé au protocole mDNS (RFC 6762) et explicitement déconseillé par Microsoft pour un domaine Active Directory. .internal a été réservé par l’ICANN en 2024 pour l’usage privé — c’est l’équivalent, pour les noms, de ce que sont les adresses RFC 1918 pour les IP. En production, le canon Microsoft reste un sous-domaine d’un domaine réellement possédé (ad.masociete.fr).

Systèmes d’exploitation retenus

2.7 Règles de pare-feu

La matrice de flux complète et les règles détaillées par interface font l’objet d’un document dédié : Matrice-de-flux.md.

3. Environnement technique

4. Procédure pas à pas

Étape 1 — Création de la VM pfSense sous Proxmox

Paramètres retenus :

Pourquoi VirtIO ? C’est le pilote paravirtualisé de Proxmox : la VM « sait » qu’elle est virtualisée et dialogue directement avec l’hyperviseur, sans émulation de matériel. Résultat : de bien meilleures performances réseau. C’est aussi ce qui donne le nom d’interface vtnet côté FreeBSD/pfSense (une carte émulée Intel E1000 s’appellerait em0).

Étape 2 — Installation de pfSense

Déroulé de l’installateur :

1. Acceptation de la licence
2. Install pfSense
3. Choix du clavier : French (AZERTY)
4. Partitionnement : Auto (UFS) — GPT
5. Installation, puis Reboot

UFS ou ZFS ? ZFS apporte snapshots et sommes de contrôle, mais consomme nettement plus de RAM. Avec 2 Go alloués, UFS est le choix adapté.

Résultat attendu au reboot : le menu console pfSense s’affiche avec ses options numérotées.

Étape 3 — Affectation des interfaces

À l’issue de l’installation, pfSense n’a détecté qu’une seule carte (vtnet0), assignée en WAN en DHCP. Elle a obtenu l’adresse 10.1.0.86/16 du serveur DHCP de l’établissement.

Une seconde carte réseau a ensuite été ajoutée à la VM depuis Proxmox (VM → Hardware → Add → Network Device), puis assignée en LAN dans pfSense (menu console, option 1) Assign Interfaces), avec l’adresse temporaire 10.0.0.1.

Configuration temporaire : cette interface LAN sert d’accès de secours. Elle deviendra l’interface parente du trunk portant les VLAN 10/20/30/40.

Étape 4 — Activation de l’accès webConfigurator depuis le WAN

Par défaut, pfSense bloque tout accès à son interface d’administration depuis le WAN. Or dans ce lab, le poste de travail se trouve du côté WAN (réseau de l’école).

Depuis la console pfSense (option 8) Shell) :

pfSsh.php playback enableallowallwan

L’interface est alors joignable sur https://10.1.0.86.

RÈGLE TEMPORAIRE — À SUPPRIMER Cette commande crée une règle allow all sur le WAN. Elle ouvre le pare-feu en grand et doit être retirée une fois l’administration possible depuis le VLAN 30 (ADM) : Pare-feu → Règles → onglet WAN → supprimer la règle générée. À remplacer par une règle restreinte à l’IP du poste d’administration.

Étape 5 — Assistant de configuration initiale (Setup Wizard)

Lancé automatiquement à la première connexion web.

Pourquoi décocher « Block RFC1918 » ? Cette option fait jeter par pfSense tout trafic provenant d’une adresse privée sur le WAN. Elle est pertinente pour un pare-feu branché sur une vraie connexion Internet publique. Ici, le « WAN » est un réseau privé (10.1.0.0/16) : laisser l’option cochée reviendrait à bloquer l’intégralité du trafic, y compris l’accès à l’interface d’administration.

Étape 6 — Mise à jour du système

System → Update → System Update

Passage de pfSense CE 2.7.0 à 2.9.0-RELEASE.

Points vérifiés sur cette capture :

Étape 7 — Création des interfaces VLAN

Interfaces → Assignments → onglet VLANs → Add

Quatre VLAN créés, tous rattachés à l’interface parente vtnet1 :

Que fait cette page exactement ? Elle crée des sous-interfaces virtuelles (vtnet1.10, vtnet1.20…) sur une seule carte physique. Chaque trame émise sur vtnet1.20 se voit ajouter une étiquette 802.1Q contenant le numéro 20. Un switch compatible VLAN lit cette étiquette et sait dans quel réseau livrer la trame. C’est le principe du « router on a stick » : un seul lien physique transporte plusieurs réseaux logiques.

À ce stade les VLAN sont créés mais pas encore utilisables : ils ne sont ni assignés à une interface pfSense, ni adressés.

Étape 8 — Changement du mot de passe administrateur

System → User Manager → onglet Users → crayon sur admin → Password + Confirmation → Save

Validation : le bandeau rouge « The password for this account is insecure. Password is currently set to the default value (pfsense) » disparaît du tableau de bord.

Pourquoi c’était urgent : le webConfigurator était exposé sur le WAN (étape 4) et le compte admin conservait le mot de passe par défaut. Toute machine du réseau de l’établissement pouvait prendre le contrôle du pare-feu. C’est la combinaison de vulnérabilités la plus classique — et la plus sanctionnée en soutenance.

Étape 9 — Création du bridge trunk vmbr1

Les VLAN existent dans pfSense, mais les trames taguées doivent encore traverser Proxmox. La carte vtnet1 était initialement raccordée à vmbr0, le bridge relié à la carte physique : les trames VLAN du lab seraient donc parties sur le réseau de l’établissement.

Principe

Un bridge Proxmox est un switch virtuel :

A — Création du bridge

Proxmox → nœud pve-01 → Système → Réseau → Créer → Linux Bridge

Puis Appliquer la configuration (bouton en haut) pour activer sans redémarrer le nœud.

Validation : vmbr1 — Gère les VLAN = Oui, Ports/esclaves vide, aucun CIDR ni passerelle. À comparer avec vmbr0, qui porte bien la carte physique eno1 et l’adresse de l’hyperviseur (10.1.0.253/16, passerelle 10.1.0.254).

Ne pas modifier vmbr0 : le WAN y transite, et une erreur fait perdre l’accès à Proxmox lui-même.

B — Bascule de la carte réseau de pfSense

VM 103 → Matériel → double-clic sur Carte réseau (net1)

Validation : la vue Matériel affiche Carte réseau (net1) : virtio=BC:24:11:61:53:5C,bridge=vmbr1.

Trunk et access — la distinction à maîtriser : ici le champ VLAN Tag reste vide car pfSense gère les étiquettes lui-même (port trunk). Pour les VM applicatives ce sera l’inverse : on y saisira 10, 20, 30 ou 40, et Proxmox taguera à leur place (port access) — la VM n’aura rien à configurer et croira être sur un réseau ordinaire.

C — Points d’hygiène relevés sur la VM

Étape 10 — Mise en service des VLAN

A — Passage du LAN en /24 (préalable obligatoire)

Interfaces → LAN → masque 24 au lieu de 16 → Save → Apply Changes.

Pourquoi c’est un préalable : le LAN en 10.0.0.1/16 couvrait 10.0.0.0 → 10.0.255.255, donc englobait les quatre futurs VLAN. Toute tentative d’adresser 10.0.10.1/24 aurait été rejetée par pfSense avec l’erreur : « IPv4 address 10.0.10.1 is being used by or overlaps with: LAN ». C’est la manifestation concrète de la règle du §2.3.

B — Assignation des interfaces

Interfaces → Assignments → liste Available network ports → sélectionner chaque VLAN → + Add

OPT = « Optional » : nom générique donné par pfSense à toute interface autre que WAN et LAN. La numérotation suit l’ordre d’ajout, pas les tags VLAN.

C — Activation et adressage

Pour chaque interface : Interfaces → OPTx

Pourquoi laisser décochées les cases « Block private / bogon networks » ? Elles servent à rejeter des adresses illégitimes arrivant d’Internet et n’ont de sens que sur une interface WAN. Sur un VLAN interne en 10.0.x.0/24, les cocher reviendrait à bloquer son propre réseau.

Validation — critère de fin de phase

Status → Interfaces :

Deux observations à relever dans cette page — elles valident toute la théorie du TP :

1. Les quatre interfaces VLAN partagent la même adresse MAC (bc:24:11:61:53:5c, celle de vtnet1). C’est la preuve matérielle du router-on-a-stick : une seule carte physique, une seule adresse MAC, quatre réseaux logiques distingués uniquement par l’étiquette 802.1Q. Le nom vtnet1.10 se lit « sous-interface de vtnet1, tag 10 ».

2. Le compteur In/out packets (block) est déjà non nul sur chaque interface VLAN, alors qu’aucune règle n’a été écrite. C’est la règle implicite block all (règle d’or n°3) qui travaille. Le pare-feu refuse déjà tout ce qui se présente — c’est le comportement attendu, pas une panne.

D — Serveur DHCP du VLAN 40

Services → DHCP Server → onglet USERS

Validation : Status → Services affiche dhcpd (ISC DHCP Server) en running, aux côtés de unbound (DNS Resolver), ntpd, dpinger et syslogd.

Modification prévue en phase 6. Tant que l’Active Directory n’existe pas, les clients doivent résoudre via pfSense. Dès la création du domaine sio.internal (tâche 6.5), ce champ devra être remplacé par les deux contrôleurs :

DNS Servers : 10.0.30.10
              10.0.30.11

Sans cette modification, les clients Windows ne trouveront pas leur contrôleur de domaine : ils recherchent des enregistrements SRV (_ldap._tcp.dc._msdcs.sio.internal) que seul le DNS d’Active Directory détient. C’est la cause la plus fréquente d’échec de jonction au domaine.

La phase 3 est terminée. L’infrastructure réseau est opérationnelle : pfSense route entre les quatre VLAN. Aucun trafic ne circule encore, faute de règles de pare-feu — c’est l’objet de la phase suivante.

Étape 11 — Création des alias de pare-feu

Firewall → Aliases

Un alias est une variable nommée réutilisable dans les règles. Trois bénéfices : maintenabilité (l’adresse d’un serveur change → un seul endroit à modifier, toutes les règles suivent), lisibilité (SRV_WEB → SRV_MYSQL : 3306 se lit, 10.0.10.10 → 10.0.20.10 : 3306 se déchiffre) et fiabilité (pas de faute de frappe répétée dans plusieurs règles).

Onglet IP — 6 alias

LAB_NETS est de type Network(s), pas Host(s) : il attend une notation CIDR. Se tromper de type produit une règle qui ne correspondra jamais.

Le LAN (10.0.0.0/24) y figure car cet alias sert aux règles de blocage (Reject → LAB_NETS) : il doit couvrir tout l’interne, sinon un flux pourrait s’échapper vers le LAN de secours au lieu d’être refusé.

Onglet Ports — 4 alias

Pourquoi autant de ports pour Active Directory ? AD n’est pas un protocole mais un empilement : DNS (53) pour localiser le contrôleur, Kerberos (88/464) pour l’authentification, LDAP (389/636) pour l’annuaire, SMB (445) pour SYSVOL et les GPO, NTP (123) car Kerberos refuse un écart d’horloge supérieur à 5 minutes, et RPC (135 + plage dynamique) pour la réplication.

La plage 49152:65535 (syntaxe pfSense : début:fin) correspond aux ports dynamiques de Windows : les appels RPC négocient un port au hasard dans cet intervalle, impossible à prévoir. C’est la cause la plus fréquente d’échec de jonction au domaine à travers un pare-feu.

Étape 12 — Règles de pare-feu de l’onglet USERS (VLAN 40)

Firewall → Rules → onglet USERS

Première des quatre séries de règles. La conception complète figure dans Matrice-de-flux.md ; on reprend ici le résultat appliqué.

Le motif d’ordonnancement

1-5  autorisations précises   (vers telle machine, sur tel port)
 6   Reject vers LAB_NETS     (tout le reste de l'interne)
 7   Pass vers any            (ne désigne plus qu'Internet)

La règle 7 vise any, qui inclut normalement les réseaux internes. Mais la règle 6 les a déjà interceptés (principe : première correspondance gagne), donc any ne désigne plus en pratique qu’Internet. C’est le motif canonique, réutilisé à l’identique sur les trois autres onglets.

Points de vigilance rencontrés

La quatrième ligne mérite d’être retenue. Une règle « bonne machine, port any » donne l’illusion d’être précise puisqu’elle nomme un seul hôte — alors qu’elle est grande ouverte. En audit, on lit toujours les colonnes Destination et Port ensemble.

La colonne States affiche 0/0 B sur toutes les règles : normal, aucune machine n’existe encore dans les VLAN. Ce compteur deviendra le principal outil de diagnostic en phase 5 — une règle restée à 0/0 alors que du trafic est généré signifie qu’elle ne correspond pas, ou qu’une règle placée au-dessus l’intercepte.

Étape 13 — Règles de pare-feu de l’onglet WEB (VLAN 10)

Firewall → Rules → onglet WEB

La règle 3 — le flux inter-VLAN du TP

C’est la seule règle du lab écrite d’hôte à hôte plutôt que de réseau à réseau :

SRV_WEB (10.0.10.10)  ──── TCP 3306 ───►  SRV_MYSQL (10.0.20.10)

Une machine supplémentaire ajoutée dans le VLAN 10 n’aurait pas accès à la base : elle serait interceptée par la règle 4. C’est le moindre privilège appliqué à la lettre — et l’argument à présenter quand on demande pourquoi cette règle n’est pas écrite WEB subnets → BDD subnets.

Le port 3306 est saisi en dur plutôt que via un alias : il n’est utilisé qu’ici, et un alias pour une règle unique n’apporterait aucune maintenabilité.

Le pare-feu n’est que le premier des trois verrous sur ce flux. En phase 6, si WordPress ne joint pas la base malgré cette règle, vérifier dans l’ordre :

1. la règle de pare-feu (faite ici) ;
2. l’écoute réseau de MySQL — par défaut bind-address = 127.0.0.1, donc le service refuse tout ce qui vient du réseau ;
3. les droits applicatifs — le compte doit être déclaré pour l’hôte d’origine : CREATE USER 'wp'@'10.0.10.10'.

Points de vigilance rencontrés

Le point le plus important de cette étape. Une règle dont la source n’appartient pas au réseau de l’onglet est silencieusement inopérante : pfSense l’accepte, l’affiche en vert, et elle ne correspondra jamais à aucun paquet. Le bouton Copy fait gagner du temps entre onglets mais ne met pas la source à jour.

Réflexe de contrôle : avant de valider un onglet, relire la colonne Source de haut en bas. Elle ne peut contenir que le réseau de l’onglet, ou un hôte de ce réseau. Toute autre valeur saute alors aux yeux.

Étape 14 — Règles de pare-feu de l’onglet BDD (VLAN 20)

Firewall → Rules → onglet BDD

C’est la zone la plus fermée du lab : la base n’initie aucun flux.

Aucune règle n’autorise le serveur web à entrer. C’est volontaire et correct : le flux SRV_WEB → SRV_MYSQL : 3306 est autorisé sur l’onglet WEB (étape 13, règle 3), et les réponses reviennent seules grâce à la table d’états. Ajouter une règle d’entrée ici ouvrirait la base dans un sens qui ne doit jamais l’être.

La règle 4 est à DÉCOCHER, pas à supprimer (tâche 6.3). pfSense permet de désactiver une règle sans l’effacer : elle reste grisée dans la liste et devient la trace documentaire de la démarche — ouverture pour l’installation, fermeture ensuite.

Le log de la règle 3 est particulièrement important ici. Un flux sortant depuis la base vers un autre VLAN serait le signe d’une exfiltration : une base de données n’a aucune raison d’initier une connexion. C’est le journal le plus pertinent du lab à présenter.

Étape 15 — Règles de pare-feu de l’onglet ADM (VLAN 30)

Firewall → Rules → onglet ADM

Cette série nécessite un alias supplémentaire : PORTS_ADMIN_FW (Port(s) : 443, 22).

La règle 4 — la traduction du bastion

Sa source est SRV_BASTION (10.0.30.12) seul, pas ADM subnets. Combinée à la règle 5 qui refuse tout le reste, elle impose que même les contrôleurs de domaine passent par Termix pour administrer les autres VLAN.

        entrée étroite                      sortie limitée
  ADM / USERS ────────►  SRV_BASTION  ──────────────────►  tous les VLAN
   443 / 8443            10.0.30.12          22 / 3389

Conséquence assumée : pour administrer srv-web ou srv-mysql, on passe par le bastion, pas par un SSH direct depuis un serveur AD. C’est exactement le comportement attendu — et ce qui rend la règle démontrable. Un contrôleur de domaine compromis ne peut rien faire vers les autres zones.

Deux alias de ports à ne pas confondre

Deux usages distincts, donc deux alias. Les fusionner en un seul (22, 443, 3389) ferait qu’une modification destinée au bastion — l’ajout de VNC sur 5900, par exemple — ouvrirait silencieusement ce même port vers l’administration du pare-feu. Un alias = un usage, comme une variable en programmation.

Étape 16 — Vérification du NAT sortant

Firewall → NAT → onglet Outbound

Mode retenu : Automatic outbound NAT rule generation (valeur par défaut, aucune modification nécessaire).

Les deux règles générées automatiquement

Validation : les cinq réseaux internes du lab apparaissent bien dans la liste des sources. Toute machine des VLAN sortira donc en 10.1.0.197 — l’adresse WAN fixe retenue à l’étape 15.

Pourquoi le NAT est indispensable ici

Le réseau de l’établissement ne connaît pas les réseaux 10.0.x.0/24 et n’a aucune route vers eux. Sans traduction, les paquets sortiraient bien, mais aucune réponse ne reviendrait : le routeur de l’école ne saurait pas où les renvoyer.

Le NAT réécrit l’adresse source de chaque paquet sortant en 10.1.0.197. Vu de l’établissement, l’ensemble du lab ressemble à une machine unique. pfSense conserve la table de correspondance et restitue la bonne adresse interne au retour.

Pourquoi deux règles, et à quoi sert « Static Port »

Par défaut, le NAT ne réécrit pas seulement l’adresse source mais aussi le port source, en tirant un numéro au hasard (icône ⇄ de la seconde règle). C’est ce qui permet à plusieurs machines internes de partager la même adresse publique sans confusion.

La première règle est une exception pour ISAKMP (port 500, la négociation de clés IPsec) : ce protocole exige que le port source reste 500. La case Static Port désactive donc la réécriture pour ce trafic précis. pfSense crée cette exception automatiquement, même sans VPN configuré.

Le mode Hybrid ne serait nécessaire que pour ajouter une règle de NAT particulière à une machine donnée, tout en conservant les règles automatiques. Inutile ici.

Aucune règle de NAT entrante (Port Forward) n’est créée : le site web n’est pas publié vers le réseau de l’établissement (décision §2.6).

La phase 4 est terminée. Le lab compte 12 alias, 22 règles de filtrage réparties sur 4 zones, et un NAT sortant fonctionnel. Une sauvegarde XML de la configuration a été réalisée à ce stade (Diagnostics → Backup & Restore) avant d’entamer la création des machines virtuelles.

Étape 17 — Première VM raccordée : poste-win11 (VLAN 40)

Première machine du lab. Volontairement choisie dans le VLAN 40 en DHCP plutôt qu’un serveur en IP fixe : c’est la seule qui éprouve toute la chaîne d’un coup.

Tag 40 (Proxmox) → trunk vmbr1 → vtnet1.40 → interface USERS → DHCP → règles → NAT

A — Paramètres Proxmox (VM 101)

La ligne réseau contient tout ce qui compte :

• virtio → pilote paravirtualisé, reconnu par Windows comme Red Hat VirtIO Ethernet Adapter
• bridge=vmbr1 → le switch virtuel isolé du lab
• tag=40 → port access : Proxmox tague et détague pour la VM, qui n’a rien à configurer
• absence de firewall=1 → le filtrage est laissé à pfSense seul

Différence avec pfSense : la VM pfSense a la même ligne sans tag — c’est son mode trunk, elle gère les étiquettes elle-même. Ici, la VM ignore totalement l’existence des VLAN.

B — Résultat côté Windows

Panneau de configuration → Centre Réseau et partage → État de Ethernet → Détails

Validation : cette seule capture valide les phases 1 à 4. Si un maillon de la chaîne avait été erroné, la machine n’aurait obtenu aucune adresse — ou une adresse dans la mauvaise plage.

Point d’attention rencontré : les serveurs DNS distribués

Au premier bail, le poste a reçu 8.8.8.8 et 1.1.1.1 comme serveurs DNS au lieu de 10.0.40.1 :

Cause : le champ DNS Servers du serveur DHCP avait été laissé vide. Dans ce cas, pfSense ne distribue pas sa propre adresse mais les serveurs configurés dans System → General Setup.

Conséquence : aucune résolution de noms possible. Les requêtes partaient vers 8.8.8.8 en UDP 53, or aucune règle de l’onglet USERS ne couvre ce flux — la règle 1 vise USERS address, la règle 6 ne concerne que l’interne, et la règle 7 n’autorise que les ports 80/443. Les requêtes tombaient donc sur le block all implicite. Le pare-feu fonctionnait exactement comme prévu.

Correction : Services → DHCP Server → USERS → DNS Servers = 10.0.40.1 seul, puis ipconfig /release && ipconfig /renew côté client.

Le diagnostic à retenir : « l’adressage fonctionne mais pas les noms » désigne toujours le DNS, jamais le routage. Un ping par adresse IP qui passe et un ping par nom qui échoue localisent la panne en deux commandes.

Étape 18 — srv-web : première VM en IP fixe (VLAN 10)

VM 110, Debian 13 « Trixie ». Première machine d’une zone sans DHCP : les paramètres réseau sont saisis manuellement pendant l’installation.

A — Configuration réseau à l’installation

L’installateur affiche d’abord « La configuration automatique a échoué — Le protocole DHCP n’est probablement pas utilisé sur le réseau ». Ce message est attendu, pas une panne : le DHCP est volontairement désactivé sur le VLAN 10 (§2.5).

Continuer → Configurer le réseau vous-même :

Côté Proxmox : vmbr1 + VLAN Tag 10, modèle VirtIO, pare-feu décoché.

L’écran Serveurs de noms est celui qu’on bâcle, et aucun DHCP ne vient rattraper l’oubli dans cette zone. Sans lui : adressage correct, mais apt inopérant.

B — Validation

# ip -4 addr show
2: ens18 ... inet 10.0.10.10/24 brd 10.0.10.255 scope global ens18

# ip route
default via 10.0.10.1 dev ens18 proto static metric 100
10.0.10.0/24 dev ens18 proto kernel scope link src 10.0.10.10 metric 100

# cat /etc/resolv.conf
nameserver 10.0.10.1

# apt update
Atteint : 1 http://deb.debian.org/debian trixie InRelease
Atteint : 2 http://deb.debian.org/debian trixie-updates InRelease
Atteint : 3 http://security.debian.org/debian-security trixie-security InRelease
Tous les paquets sont à jour.

apt update valide à lui seul quatre mécanismes : résolution DNS via pfSense, routage par la passerelle, règle 5 de l’onglet WEB (WEB subnets → any : PORTS_WEB), et NAT sortant.

# ping -c3 10.0.20.1
3 packets transmitted, 3 received, 0% packet loss

Le routage inter-VLAN fonctionne (règle 2 de l’onglet WEB, ICMP vers LAB_NETS).

C — Point d’attention : ping vers le poste Windows sans réponse

# ping -c3 10.0.40.100
3 packets transmitted, 0 received, 100% packet loss

Ce n’est pas pfSense. Le pare-feu autorise bien ce flux (règle 2 de l’onglet WEB), et le routage vers le VLAN 40 est fonctionnel — la même commande vers 10.0.40.1 répond.

Cause réelle : le pare-feu de Windows. Windows Defender bloque par défaut les demandes d’écho ICMP entrantes provenant d’un autre sous-réseau, sauf si la règle Partage de fichiers et d’imprimantes (demande d’écho — ICMPv4-Entrant) est activée.

Vérification : le ping en sens inverse (depuis Windows vers 10.0.10.10) fonctionne, ce qui prouve que la connectivité et les règles pfSense sont correctes dans les deux sens.

Le point de cours : un pare-feu réseau n’est pas le seul filtre du chemin. Chaque hôte possède son propre pare-feu, et Windows est particulièrement restrictif en entrée. Avant d’incriminer pfSense, vérifier systématiquement que la machine cible accepte le flux — les compteurs States et les journaux du pare-feu permettent de trancher en quelques secondes.

Étape 19 — srv-docker : le bastion (VLAN 30)

VM 114, Debian 12 « Bookworm ». Machine destinée à héberger Termix (SSH et RDP) sous forme de conteneurs.

A — Paramètres retenus

Mot de passe root laissé vide à l’installation. L’installateur Debian désactive alors le compte root et ajoute automatiquement le premier utilisateur au groupe sudo — sudo est opérationnel dès la première connexion, sans usermod ni redémarrage. C’est aussi plus sûr : aucun compte root avec mot de passe à forcer par SSH.

B — Installation de Docker

Le dépôt officiel Docker a été retenu plutôt que les paquets Debian, pour disposer de Compose v2 — la syntaxe supposée par la documentation de Termix.

sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian bookworm stable" | sudo tee /etc/apt/sources.list.d/docker.list

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER

Validation : docker run --rm hello-world puis docker ps sans sudo.

hello-world valide toute la chaîne réseau : résolution de registry-1.docker.io via pfSense, sortie Internet par la règle 6 de l’onglet ADM, NAT, téléchargement, exécution.

Appartenir au groupe docker équivaut à un accès root sur la machine : un membre peut lancer un conteneur montant / et modifier tout le système. Acceptable sur un serveur d’administration mono-utilisateur, à proscrire sur une machine partagée.

C — Points d’attention rencontrés

Le réflexe de diagnostic : après l’ajout d’un dépôt, contrôler la sortie de apt update. Si la nouvelle source n’y figure pas, inutile de chercher ailleurs. Le message « il existe dans la base de données » signifie précisément : « je connais ce nom de paquet, mais aucune source ne me le fournit ».

Et une règle générale : coller plusieurs commandes d’un coup dans un terminal est une source d’erreurs silencieuses — une ligne avale la suivante, un caractère est mal interprété. Pour les commandes qui écrivent des fichiers, une ligne à la fois, puis on vérifie.

D — Hétérogénéité des versions Debian

Écart constaté et assumé : les deux versions sont maintenues et fonctionnent. En production, l’homogénéité serait recherchée — un seul cycle de mises à jour, une seule procédure, un seul jeu de paquets à maîtriser.

Étape 20 — Les trois services du bastion

srv-docker héberge trois piles Compose indépendantes, chacune dans son propre réseau Docker.

Chaque pile Compose crée son propre réseau isolé (termix-net, portainer_default). Les conteneurs d’une pile ne peuvent pas joindre ceux d’une autre. C’est du cloisonnement à l’échelle des conteneurs — la même logique que les VLAN, un étage plus bas.

A — Termix

Portail d’accès unique : SSH, bureau à distance — via le moteur guacd qu’il embarque —, transfert de fichiers, gestion Docker et métriques. Base SQLite par défaut, aucun serveur de base de données à déployer à côté.

services:
  termix:
    image: ghcr.io/lukegus/termix:latest
    container_name: termix
    restart: unless-stopped
    ports:
      - "443:8080"
    environment:
      PORT: "8080"
    volumes:
      - termix-data:/app/data
    networks:
      - termix-net
    depends_on:
      - termix-guacd

  termix-guacd:
    image: guacamole/guacd:1.6.0   # moteur de rendu embarque par Termix
    container_name: termix-guacd
    restart: unless-stopped
    networks:
      - termix-net

volumes:
  termix-data:
    driver: local

networks:
  termix-net:
    driver: bridge

Le moteur de rendu est nommé termix-guacd : les noms de conteneurs sont uniques sur l’hôte, un préfixe explicite évite toute collision avec une autre pile. Le port 4822 n’est pas publié — il n’est joignable qu’à l’intérieur du réseau termix-net.

B — Portainer

Supervision des conteneurs. Volontairement non exposé au réseau : la publication est liée à 127.0.0.1, et l’accès se fait par tunnel SSH depuis le poste de travail.

services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    ports:
      - "127.0.0.1:9443:9443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data

volumes:
  portainer_data:

Accès depuis le poste de travail :

ssh -L 9443:localhost:9443 docker

puis https://localhost:9443 (certificat auto-signé).

Pourquoi Portainer n’est pas dans PORTS_BASTION. Termix est un portail d’accès destiné aux utilisateurs. Portainer est un outil d’exploitation : il monte /var/run/docker.sock, donc quiconque y accède peut lancer un conteneur montant / et obtenir root sur srv-docker. Un tel outil n’a pas à être joignable depuis le VLAN utilisateurs.

Le tunnel SSH -L fait écouter le port 9443 sur le poste de travail et ressortir le trafic à l’autre bout de la session SSH, sur srv-docker. Le navigateur croit parler à sa propre machine ; rien n’est exposé, aucune règle n’est ajoutée. Il fonctionne à travers le ProxyJump — le tunnel s’établit sur le dernier saut.

C — Contrainte de ports imposée par le pare-feu

L’alias PORTS_BASTION n’autorise que le 443. Termix y est donc publié — alors qu’il sert du HTTP en clair.

Conséquence : aucune URL courte ne fonctionne. http://10.0.30.12 part sur le port 80, https://10.0.30.12 tenterait une négociation TLS que Termix ne sait pas faire. Il faut écrire http://10.0.30.12:443.

Un cas où la contrainte de sécurité a forcé un choix technique discutable — et il faut savoir le reconnaître plutôt que le masquer. Deux corrections possibles :

Correction	Effet
Ajouter 80 à PORTS_BASTION et republier Termix sur le 80	http://10.0.30.12 fonctionne naturellement
Reverse proxy (Traefik/Nginx) sur le 443, avec TLS	https://termix.sio.internal servi en vrai HTTPS, et tout service futur sur le même port — la solution canonique

Le reverse proxy résout aussi le problème de fond : chaque port ouvert dans le pare-feu est une ligne à justifier. Un point d’entrée unique en réduit le nombre à un.

Validation : Termix répond depuis poste-win11 (VLAN 40), ce qui valide la règle 4 de l’onglet USERS.

Étape 21 — Accès distant par Tailscale (subnet router)

Objectif : joindre l’intégralité du lab depuis n’importe où, sans ouvrir le moindre port entrant sur le réseau de l’établissement.

A — Pourquoi Tailscale, et pourquoi sur pfSense

Le lab est derrière le NAT de l’établissement, que l’on ne maîtrise pas : aucune redirection de port n’est possible, et un VPN classique (WireGuard, OpenVPN) exigerait un port entrant depuis Internet. Un tunnel sortant contourne cette contrainte : c’est l’agent qui va vers le service.

Le choix du subnet router — plutôt qu’un agent sur chaque machine — permet d’exposer des réseaux entiers avec un seul nœud enrôlé.

Et ce nœud doit être pfSense, pas srv-docker :

Cohérent avec toute l’architecture : pfSense reste le point de passage unique entre le lab et l’extérieur. Tailscale devient sa troisième patte, à côté du WAN et du trunk.

B — Isolation vis-à-vis du réseau personnel

Un tailnet dédié au BTS a été créé, avec une identité distincte de celle du réseau personnel déjà existant.

Une même identité = un même tailnet. Se reconnecter avec le compte Google personnel aurait ramené sur le tailnet existant. Il faut une identité différente (adresse scolaire, second compte, GitHub…).

L’alternative aurait été un tailnet unique avec des tags et des ACL — plus souple (les deux réseaux visibles simultanément), mais demandant d’écrire une politique JSON. Le compte séparé garantit l’isolation par construction, au prix d’une bascule de profil (tailscale switch).

C — Configuration du paquet pfSense

System → Package Manager → installer Tailscale, puis VPN → Tailscale

Onglet Authentication

Onglet Settings

D — Côté console Tailscale

E — Côté poste de travail

Installation du client, connexion au tailnet BTS, puis — l’étape que l’on oublie : cocher « Use Tailscale subnets ». Sans elle, le nœud pfSense est visible mais aucun des réseaux 10.0.x.0/24 n’est joignable.

F — La règle de pare-feu

Le paquet crée une interface tailscale0, placée dans un groupe pf nommé Tailscale — ce qui fait apparaître un onglet dédié dans Firewall → Rules, sans assignation d’interface.

L’onglet est vide à la création : « No rules are configured for this interface ». Règle d’or n°3 — rien ne passe.

Pourquoi any en source plutôt que la plage CGNAT 100.64.0.0/10 :

L’interface est elle-même la frontière. Sur Tailscale, il n’arrive que du trafic sorti du tunnel WireGuard, donc que des machines authentifiées du tailnet. Le filtrage réel a déjà eu lieu — il est assuré par Tailscale (clés, identités, appareils autorisés), pas par pfSense.

De plus, 100.64.0.0/10 casserait l’IPv6 : Tailscale attribue aussi une adresse fd7a:115c:a1e0::/48 à chaque nœud.

La bonne granularité n’est pas toujours la plus fine : ici, la restriction utile se configure dans la console Tailscale, pas dans le pare-feu.

Décision à assumer : cette règle fait du tailnet une zone de confiance disposant d’un accès complet au lab. C’est l’objectif recherché, mais c’est une entrée de plus dans la matrice de flux, au même titre que le WAN.

G — Validation

PS> tailscale status
100.84.62.27  sio2527-pfsense-axel  freebsd  active; direct 10.1.0.197:41641, tx 572 rx 156

PS> ping 10.0.30.12
Réponse de 10.0.30.12 : octets=32 temps=12 ms
Paquets : envoyés = 2, reçus = 2, perdus = 0 (0% de perte)

PS> ssh [email protected]
Linux SRV-WEB 6.12.107+deb13-amd64

Le poste de travail joint l’intégralité du lab — SSH direct, interfaces web, interface d’administration de pfSense — sans rebond, sans tunnel manuel, et sans aucun port ouvert sur le réseau de l’établissement.

Ce que révèle tailscale status : direct 10.1.0.197:41641 signifie que la liaison est pair-à-pair, sans passer par les serveurs relais de Tailscale — les deux machines étant sur le réseau de l’établissement. Depuis l’extérieur, la mention deviendrait relay "..." : plus lent, mais fonctionnel.

Et tx 572 rx 156 prouve que des octets circulent dans les deux sens. C’est ce qui a permis d’écarter le réseau et de conclure au pare-feu lors du diagnostic.

Étape 22 — Configuration du bastion : identifiants et hôtes

Termix sépare les identifiants des hôtes : un même identifiant se réutilise sur plusieurs machines, et un changement de mot de passe se fait à un seul endroit. Même principe que les alias de pfSense — définir une fois, réutiliser partout.

Identifiants

Hôtes

Pour pfSense, viser 10.0.30.1 et non 10.1.0.197. Termix se connecte depuis srv-docker, situé dans le VLAN 30 : il doit viser pfSense sur son propre réseau. C’est la règle d’or n°1 appliquée au client — on vise le pare-feu sur le réseau d’où l’on vient.

Clé dédiée pour pfSense

pfSense étant configuré en SSHd Key Only, le bastion a reçu sa propre paire de clés plutôt que de réautoriser les mots de passe :

ssh-keygen -t ed25519 -C "termix-pfsense" -f ~/.ssh/termix_pfsense -N ""

La clé publique est ajoutée sur une nouvelle ligne dans User Manager → admin → Authorized SSH Keys, sous celle du poste de travail. La clé privée est importée comme identifiant dans Termix.

Résultat : pfSense n’accepte aucun mot de passe en SSH. Deux clés seulement y ont accès — celle du poste de travail et celle du bastion. Voir l’incident G-05 pour le détail du diagnostic.

Deux paramètres à corriger

Validation : les quatre hôtes s’ouvrent dans le navigateur depuis n’importe où via Tailscale — trois terminaux SSH et le bureau Windows 11 en RDP.

Cela valide les deux ports de la règle 4 de l’onglet ADM :

SRV_BASTION → LAB_NETS : PORTS_ADMIN (22, 3389)
                                      ▲▲   ▲▲▲▲
                                   SSH    RDP 

L’image à garder pour le dossier : le bureau d’une machine du VLAN 40, affiché dans un navigateur, servi par un bastion du VLAN 30, depuis un poste extérieur au lab connecté en Tailscale. Toute l’architecture tient dans une capture.

Serveur SSH sur le poste Windows

Windows 11 installe le client OpenSSH par défaut, pas le serveur. La première tentative de session SSH échouait donc en timeout — et non en connexion refusée, signe que le pare-feu Windows jetait le paquet faute de règle pour le port 22.

PowerShell en administrateur, sur la VM :

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

L’installation de la fonctionnalité crée automatiquement la règle OpenSSH-Server-In-TCP dans le pare-feu Windows — comme pour le Bureau à distance. Seul l’ICMP demande une intervention manuelle (incident E-04).

Optionnel — obtenir PowerShell plutôt que cmd.exe à l’ouverture de session :

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell `
  -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force

Une seule règle de pare-feu pour deux protocoles. poste-win11 est désormais administrable en SSH et en RDP, et l’alias PORTS_ADMIN (22, 3389) couvrait les deux cas dès le départ — sans qu’il ait fallu y revenir. C’est le bénéfice concret d’avoir conçu la matrice de flux avant de toucher à l’interface.

Étape 23 — Agent QEMU sur pfSense

Permet à Proxmox d’afficher l’adresse IP de la VM, de l’arrêter proprement et de réaliser des sauvegardes cohérentes.

Installation

Le paquet figure dans le dépôt officiel pfSense — ce n’est donc pas un ajout non supporté :

pkg install -y qemu-guest-agent

Côté Proxmox : VM 103 → Options → QEMU Guest Agent → Enabled, puis Shutdown + Start.

Un reboot ne suffit pas. Le périphérique virtio-serial fait partie du matériel virtuel : Proxmox ne peut l’ajouter qu’au démarrage du processus QEMU. Un redémarrage vu de l’intérieur ne détruit pas ce processus.

Règle générale : tout changement de matériel dans Proxmox demande un cycle Shutdown → Start ; tout changement logiciel se contente d’un reboot. C’est la même contrainte que pour l’ajout de la carte net1 à l’étape 3.

Vérification du canal de communication :

ls -l /dev/vtcon/
org.qemu.guest_agent.0 -> ../ttyV0.1

Démarrage automatique — par Shellcmd

La commande sysrc qemu_guest_agent_enable="YES" proposée par le paquet ne suffit pas : pfSense possède son propre processus de démarrage (/etc/rc.bootup) et ne traite pas /etc/rc.conf comme un FreeBSD standard. Le service ne repartait pas après redémarrage.

System → Package Manager → Shellcmd, puis Services → Shellcmd :

Pourquoi Shellcmd plutôt qu’un fichier système : la commande est enregistrée dans la configuration XML de pfSense. Elle est donc incluse dans les sauvegardes, restaurée automatiquement, et visible dans l’interface — donc documentée. Une ligne ajoutée à la main dans /etc/rc.conf disparaîtrait à la première restauration.

Sur un équipement à configuration gérée, on n’édite pas les fichiers système : on utilise le mécanisme d’extension prévu.

On appelle le service, pas l’exécutable : le script rc connaît le chemin, les arguments et gère le fichier PID. Si une mise à jour déplace le binaire, la commande continue de fonctionner.

Validation : après redémarrage, service qemu-guest-agent status répond running as pid ... sans intervention, et Proxmox affiche l’adresse IP dans l’onglet Résumé.

Étape 24 — srv-mysql : la base de données

Objectif : déployer la 4ᵉ VM, y installer le SGBD, le durcir, puis l’ouvrir au seul flux qui en a besoin — srv-web sur le port 3306.

24.1 — Création de la VM sous Proxmox

24.2 — Installation de Debian

Le message « La configuration automatique du réseau a échoué » est attendu : le DHCP est volontairement absent du VLAN 20. Configuration manuelle :

24.3 — Installation de MariaDB et de l’agent QEMU

sudo apt update && sudo apt upgrade -y
sudo apt install -y mariadb-server qemu-guest-agent

À faire pendant que la fenêtre est ouverte. La règle 4 de l’onglet BDD autorise temporairement la sortie Internet ; elle sera décochée ensuite (tâche 6.3). Après quoi aucun paquet ne pourra plus être téléchargé depuis ce VLAN.

Validation de l’agent — trois contrôles :

uptime -s
systemctl status qemu-guest-agent --no-pager
ls -l /dev/virtio-ports/

L’agent démarre à l’heure exacte du démarrage système, donc au boot.

systemctl is-enabled répond static, ce qui n’est pas un problème : sous Debian l’agent est lancé par une règle udev dès que le périphérique virtio apparaît, et non par un lien dans multi-user.target.wants.

24.4 — Sécurisation

sudo mariadb-secure-installation

Debian 13 affiche désormais : « MariaDB is secure by default in Debian. Running this script is useless at best ». C’est exact — le script est conservé par compatibilité avec le monde MySQL amont. On le lance quand même pour pouvoir prouver l’état, pas le supposer.

Validation fonctionnelle — la commande qui tranche :

mariadb -u root

(sans sudo, donc en tant qu’ipfixe)

ERROR 1698 (28000): Access denied for user 'root'@'localhost'

Le code 1698 est la signature de unix_socket : il signifie que le greffon d’authentification a refusé, et non qu’un mot de passe était faux (ce serait 1045).

La vue mysql.user affiche pourtant mysql_native_password. La source de vérité est mysql.global_priv :

"plugin": "mysql_native_password",
"authentication_string": "invalid",
"auth_or": [ { }, { "plugin": "unix_socket" } ]

auth_or énumère les méthodes alternatives. La première est verrouillée : le champ authentication_string contient le mot invalid, qui n’est pas une empreinte valide — aucun mot de passe ne peut produire cette valeur. Seul unix_socket fonctionne. La vue mysql.user ne lit que le champ plugin de premier niveau et ignore auth_or.

24.5 — Écoute réseau : bind-address

Par défaut Debian lie MariaDB à la boucle locale. Aucun service n’étant posté sur 10.0.20.10:3306, une connexion de srv-web serait refusée — pas bloquée : le paquet arrive, mais personne n’écoute.

sudo sed -i 's/^bind-address.*/bind-address            = 10.0.20.10/' /etc/mysql/mariadb.conf.d/50-server.cnf
grep -n '^bind-address' /etc/mysql/mariadb.conf.d/50-server.cnf
sudo systemctl restart mariadb && sudo ss -tlnp | grep 3306

Validation :

AVANT   LISTEN 0 80 127.0.0.1:3306
APRÈS   LISTEN 0 80 10.0.20.10:3306

Pourquoi l’adresse explicite plutôt que 0.0.0.0 — le joker exposerait automatiquement le service sur toute interface ajoutée plus tard. L’adresse explicite ne bouge pas, et le fichier documente l’intention. C’est le principe de moindre exposition.

Effet de bord assumé : mariadb -h 127.0.0.1 ne fonctionne plus en local. sudo mariadb continue de fonctionner — il passe par la socket Unix, qui est de toute façon le bon moyen en local.

24.6 — Base wp_lab et compte distant

sudo mariadb -e "CREATE DATABASE wp_lab CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'wp_user'@'10.0.10.10' IDENTIFIED BY '<mot-de-passe-wp_user>'; GRANT ALL PRIVILEGES ON wp_lab.* TO 'wp_user'@'10.0.10.10';"

Ne jamais écrire 'wp_user'@'%'. Le joker % autorise la connexion depuis n’importe quelle adresse. Le mot de passe figurant en clair dans wp-config.php, la restriction d’origine est ce qui le rend inexploitable en cas de fuite.

FLUSH PRIVILEGES est inutile ici : il ne sert que si l’on modifie les tables de droits à la main par INSERT/UPDATE. CREATE USER et GRANT rechargent les privilèges seuls.

Validation :

| wp_lab |

GRANT USAGE ON *.* TO `wp_user`@`10.0.10.10` IDENTIFIED BY PASSWORD '*2DB29C...'
GRANT ALL PRIVILEGES ON `wp_lab`.* TO `wp_user`@`10.0.10.10`

GRANT USAGE ON *.* ne donne aucun droit : USAGE signifie littéralement « aucun privilège ». Cette ligne matérialise l’existence du compte et porte l’empreinte du mot de passe. Le privilège réel est sur la seconde ligne.

24.7 — Les trois verrous, récapitulés

C’est le point à retenir de cette étape : l’accès à la base est protégé par trois mécanismes indépendants, chacun couvrant la défaillance des autres — c’est la défense en profondeur.

Étape 25 — WordPress sur srv-web et validation du flux inter-VLAN

Objectif : monter la chaîne applicative complète et démontrer qu’une application d’un VLAN consomme une base d’un autre VLAN, routée et filtrée par pfSense.

25.1 — Apache, PHP et le client MariaDB

sudo apt install -y apache2 libapache2-mod-php php php-mysql php-gd php-curl php-xml php-mbstring php-zip php-intl mariadb-client curl

Versions obtenues : Apache 2.4.68, PHP 8.4.24, client MariaDB 11.8.6.

curl n’est pas présent sur une installation Debian minimale — il faut l’ajouter.

25.2 — Le test du flux 3306, avant toute application

mariadb -h 10.0.20.10 -u wp_user -p wp_lab

MariaDB [wp_lab]>

Validation — à exécuter dans l’invite :

SELECT @@hostname, USER(), CURRENT_USER();
SHOW DATABASES;

La démonstration du moindre privilège : la même commande renvoie 5 bases en root sur srv-mysql et 2 depuis wp_user. MariaDB masque ce à quoi le compte n’a pas droit.

Une erreur de frappe sur le mot de passe a fourni la meilleure preuve du TP :

ERROR 1045 (28000): Access denied for user 'wp_user'@'10.0.10.10' (using password: YES)

Ce message est revenu de srv-mysql : le routage inter-VLAN et la règle de pare-feu étaient donc déjà franchis. Le serveur a même reconnu exactement le compte créé. Seul le verrou 3 a joué. Les trois couches sont ainsi démontrées indépendamment.

Code	Signification
1045	mot de passe incorrect
1698	le greffon d’authentification a refusé (cf. étape 24.4)

25.3 — Déploiement des fichiers

cd /tmp && curl -O https://fr.wordpress.org/latest-fr_FR.tar.gz
tar xzf latest-fr_FR.tar.gz && sudo mv wordpress /var/www/wordpress
sudo chown -R www-data:www-data /var/www/wordpress
sudo find /var/www/wordpress -type d -exec chmod 755 {} \;
sudo find /var/www/wordpress -type f -exec chmod 644 {} \;

Pourquoi retirer x des fichiers, et ne jamais faire chmod -R 777. Si un attaquant dépose un fichier dans wp-content/uploads, le bit d’exécution lui permettrait de le lancer comme programme. Sans lui, le fichier reste une donnée inerte — une des protections les plus efficaces contre le dépôt de webshell. PHP n’a pas besoin de ce bit : Apache lit le fichier et le passe à l’interpréteur.

25.4 — VirtualHost dédié

/etc/apache2/sites-available/wordpress.conf :

<VirtualHost *:80>
    ServerName srv-web.sio.internal
    ServerAlias 10.0.10.10
    DocumentRoot /var/www/wordpress

    <Directory /var/www/wordpress>
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog  ${APACHE_LOG_DIR}/wordpress-error.log
    CustomLog ${APACHE_LOG_DIR}/wordpress-access.log combined
</VirtualHost>

sudo a2ensite wordpress && sudo a2dissite 000-default && sudo a2enmod rewrite
sudo apache2ctl configtest && sudo systemctl restart apache2

apache2ctl configtest avant tout rechargement. Il valide la syntaxe sans toucher au service : recharger une configuration invalide arrête Apache.

Validation intermédiaire, avant même de configurer la base :

curl -I http://localhost
→ HTTP/1.1 302 Found
→ Location: http://localhost/wp-admin/setup-config.php

WordPress est servi et réclame sa configuration : la couche web est validée indépendamment de la couche données.

25.5 — wp-config.php, la jonction entre les deux serveurs

cd /var/www/wordpress && sudo -u www-data cp wp-config-sample.php wp-config.php
sudo -u www-data sed -i "s/'database_name_here'/'wp_lab'/; s/'username_here'/'wp_user'/; s/'password_here'/'<mot-de-passe-wp_user>'/; s/'localhost'/'10.0.20.10'/" wp-config.php

DB_HOST est la ligne qui matérialise toute l’architecture. Dans une installation LAMP classique elle vaut localhost : web et base sur la même machine. Ici elle désigne une machine d’un autre VLAN — chaque requête de WordPress traverse pfSense. C’est cette seule ligne qui transforme un WordPress banal en démonstration de segmentation réseau.

Clés de sécurité (salts) :

curl -s https://api.wordpress.org/secret-key/1.1/salt/ | sudo tee /tmp/salts.txt > /dev/null
sudo sed -i '/put your unique phrase here/d' wp-config.php
sudo sed -i '/^\$table_prefix/r /tmp/salts.txt' wp-config.php && sudo rm /tmp/salts.txt
sudo chown www-data:www-data wp-config.php && sudo chmod 640 wp-config.php

WordPress ne stocke pas le mot de passe dans le cookie de session : il y place une signature cryptographique calculée à partir de huit chaînes secrètes. Les valeurs par défaut du fichier d’exemple étant publiques, n’importe qui pourrait forger un cookie valide sans les remplacer.

Effet de bord utile : changer les salts invalide toutes les sessions en cours. C’est la façon canonique de déconnecter tout le monde après une compromission.

chmod 640 : le fichier contient le mot de passe de la base en clair. ipfixe ne peut pas le lire sans sudo — vérifié : grep renvoie « Permission non accordée ». C’est aussi la raison d’être de la restriction @'10.0.10.10' sur le compte.

Validation :

curl -I http://localhost
→ Location: http://localhost/wp-admin/install.php

Le passage de setup-config.php à install.php est la preuve que WordPress a joint la base à travers le pare-feu. S’il n’y parvenait pas, il afficherait « Erreur lors de la connexion à la base de données » au lieu de proposer l’installation.

25.6 — Installation depuis poste-win11 (VLAN 40)

L’assistant est lancé depuis le poste Windows, à l’adresse http://10.0.10.10, afin de valider simultanément le flux USERS → WEB.

25.7 — La chaîne complète, démontrée

   poste-win11              srv-web                 srv-mysql
    VLAN 40      ──80──►    VLAN 10    ──3306──►    VLAN 20
   10.0.40.100            10.0.10.10              10.0.20.10
        │                      │                       │
   règle USERS n°5       règle WEB n°3          bind-address
   → SRV_WEB : 80/443    → SRV_MYSQL : 3306     + GRANT @'10.0.10.10'

Trois VLAN, deux règles de pare-feu distinctes, trois verrous sur la base. Aucun de ces sauts n’est possible sans une autorisation explicitement écrite et justifiée.

Validation finale, depuis srv-mysql :

sudo mariadb -e "SHOW TABLES FROM wp_lab;"

Une douzaine de tables wp_* créées à distance, depuis l’autre VLAN, par le compte wp_user — preuve que ses privilèges CREATE s’appliquent, et uniquement sur wp_lab.

25.8 — Le test miroir : prouver que ce qui doit être bloqué l’est (test 7.3)

Démontrer que le flux autorisé passe ne suffit pas. Il faut démontrer que tout le reste est refusé, et le prouver par un journal — un pare-feu qui bloque sans le tracer ne démontre rien.

Depuis poste-win11 (VLAN 40), en PowerShell :

Test-NetConnection 10.0.20.10 -Port 3306

SourceAddress          : 10.0.40.100
PingSucceeded          : True
TcpTestSucceeded       : False

Ces deux dernières lignes ensemble constituent la preuve. Même machine, même destination, deux protocoles, deux résultats opposés :

Il ne reste qu’une explication : un filtrage volontaire, sur ce protocole et ce port précis.

La trace côté pfSense

Status → System Logs → Firewall → Advanced Log Filter — Source IP 10.0.40.100, Destination IP 10.0.20.10

La description saisie à la création de la règle apparaît telle quelle dans le journal. C’est le retour sur investissement des descriptions rédigées une par une : un journal lisible par un tiers, là où @4:6 n’aurait rien signifié. Le nombre entre parenthèses est le Rule Tracker ID, utilisable comme critère de filtre.

TCP:S = drapeau SYN seul. Aucun paquet autre qu’un SYN n’apparaît : la poignée de main TCP n’a jamais dépassé sa première étape. Ni session, ni octet de donnée.

Les ports source 49729 puis 49849 correspondent à deux exécutions successives de la commande. Ils tombent tous deux dans la plage éphémère 49152-65535 — démonstration concrète de la raison pour laquelle on ne filtre jamais sur le port source (§4, matrice de flux) : il change à chaque connexion.

Synthèse des deux tests

     srv-web (10.0.10.10)      → srv-mysql:3306   connexion établie, 12 tables créées
     poste-win11 (10.0.40.100) → srv-mysql:3306   SYN rejetés, tracés, nommés

Même destination, même port, deux sources différentes, deux résultats opposés. C’est le moindre privilège en action : la règle 3 de l’onglet WEB vise SRV_WEB en hôte à hôte, et non le réseau entier.

Phase 10 — Haute disponibilité

Passage d’une architecture mono-serveur à une architecture redondée : cluster Galera à 3 nœuds pour la base, répartiteur HAProxy devant deux serveurs web.

La distinction à poser d’emblée : HAProxy est une machine, Galera n’en est pas une.

   HAProxy INTERCEPTE le trafic          Galera COORDONNE des serveurs
   ────────────────────────────          ────────────────────────────
   client ─► srv-ha ─► srv-web-01        srv-mysql-01 ◄══╗
                   └─► srv-web-02        srv-mysql-02 ◄══╬══ pair-à-pair
                                         srv-mysql-03 ◄══╝
   il est SUR le chemin                  rien ne s'intercale
   → il lui faut sa propre VM            → AUCUNE VM supplémentaire

Galera est la bibliothèque /usr/lib/galera/libgalera_smm.so, livrée avec mariadb-server et déjà présente depuis l’étape 24.3 — on l’a vue défiler dans la sortie d’apt (Paramétrage de galera-4). On ne l’installe pas : on l’active par configuration.

Étape 26 — Renommage srv-web-01 et srv-mysql-01

Préalable à tout le reste : une numérotation homogène entre les membres d’un même cluster.

sudo hostnamectl set-hostname srv-web-01
sudo sed -i "s/^10\.0\.10\.10.*/10.0.10.10\tsrv-web-01.sio.internal\tsrv-web-01/" /etc/hosts && exec bash

sudo hostnamectl set-hostname srv-mysql-01
sudo sed -i "s/^10\.0\.20\.10.*/10.0.20.10\tsrv-mysql-01.sio.internal\tsrv-mysql-01/" /etc/hosts && exec bash

Pourquoi réécrire la ligne entière au lieu de s/ancien/nouveau/g. Un remplacement de srv-web par srv-web-01 est dangereux rejoué : la seconde exécution produirait srv-web-01-01. En ancrant sur l’adresse IP (^10.0.10.10) et en réécrivant toute la ligne, la commande devient idempotente.

Validation : hostname renvoie le nouveau nom, et /etc/hosts contient 10.0.10.10 srv-web-01.sio.internal srv-web-01.

L’avertissement sudo: impossible de résoudre l'hôte est attendu : sudo lit le nom de la machine au lancement, donc avant que sed n’ait modifié le fichier.

Répercussion : les 7 livrables, les alias pfSense, les hôtes Termix.

Étape 27 — Clonage Proxmox et régénération des identités

Le principe central : un clone n’est pas une nouvelle machine tant qu’on n’a pas régénéré ce qui doit être unique.

27.1 — Préparation

1. Shutdown de srv-mysql-01 — jamais Stop. L’agent QEMU permet l’extinction propre : MariaDB ferme ses fichiers. Un clone pris pendant une écriture donne une image incohérente, qu’on dupliquerait ensuite deux fois.
2. Clic droit → Clone → Full Clone.

Le sélecteur Mode n’apparaît pas lorsque la source est une VM ordinaire : Proxmox n’autorise le Linked Clone que depuis un template. La copie est donc forcément complète.

Et c’est heureux. Un linked clone n’enregistre que les différences par rapport au disque parent, dont il reste dépendant à vie. Pour un cluster ce serait un contresens : trois nœuds sur un même disque parent, c’est un seul point de panne déguisé en trois.

27.2 — Déconnecter la carte réseau avant le premier démarrage

Onglet Hardware → Network Device (net0) → décocher Connected.

Le clone a hérité de 10.0.20.10. Le démarrer tel quel provoquerait un conflit d’adresses avec la machine d’origine — deux hôtes répondant à la même adresse, et des symptômes incompréhensibles sur tout le VLAN.

On corrige l’adresse par la console Proxmox, réseau coupé, puis on rebranche :

sudo sed -i 's/10\.0\.20\.10/10.0.20.11/' /etc/network/interfaces

Le motif 10\.0\.20\.10 exige un 0 final : la passerelle 10.0.20.1 n’est pas touchée. Les points sont échappés pour désigner des points littéraux.

27.3 — Les cinq identités à régénérer

sudo rm -f /etc/machine-id /var/lib/dbus/machine-id
sudo systemd-machine-id-setup
sudo ln -sf /etc/machine-id /var/lib/dbus/machine-id

Les DEUX fichiers, pas seulement /etc/machine-id. systemd-machine-id-setup cherche une source dans l’ordre : /etc/machine-id → /var/lib/dbus/machine-id → UUID SMBIOS → aléatoire. En n’effaçant que le premier, il recopie celui du clone et les deux machines restent jumelles. Le message affiché est la seule alerte :

Message	Verdict
from D-Bus machine ID	identifiant recopié du clone
from SMBIOS/DMI UUID	UUID unique fourni par Proxmox
from random generator	tirage aléatoire

Incident complet : H-11 du Troubleshooting.

Effet de bord à connaître : après ce changement, journalctl répond « No journal files were found ». Le démon écrit dans un répertoire nommé d’après l’ancien identifiant, alors que journalctl cherche avec le nouveau. Correction : sudo systemctl restart systemd-journald.

Validation — depuis le bastion, les trois identifiants doivent différer :

for h in 10.0.20.10 10.0.20.11 10.0.20.12; do echo -n "$h : "; ssh ipfixe@$h cat /etc/machine-id; done

Les trois empreintes ED25519 affichées à la connexion doivent différer également — ce qui valide du même coup la régénération des clés d’hôte.

27.4 — Vider le répertoire de données des futurs nœuds Galera

sudo systemctl stop mariadb && sudo systemctl disable mariadb
sudo rm -rf /var/lib/mysql && sudo install -d -o mysql -g mysql -m 700 /var/lib/mysql

Pourquoi effacer des données qu’on vient de copier ? Le clone contient une copie figée de wp_lab. S’il rejoignait le cluster avec ses propres données, Galera verrait deux historiques divergents. Un répertoire vide l’oblige à demander un SST — une copie intégrale et cohérente, prise à l’instant de la jonction.

disable empêche MariaDB de tenter un démarrage au prochain boot sur un répertoire vide. On réactivera après la jonction réussie.

Dette héritée : srv-web-02, clone de srv-web-01, hérite de son environnement de bureau — dette H-3.

Étape 28 — Le cluster Galera à 3 nœuds

28.1 — Préalables

Rouvrir temporairement la règle 4 de l’onglet BDD (dette T-3), le temps des installations, puis la refermer.

sudo apt install -y mariadb-backup curl

Sur les trois nœuds : chacun peut devenir donneur ou receveur.

Compte de synchronisation, sur srv-mysql-01 uniquement — les autres le recevront par SST :

sudo mariadb -e "CREATE USER 'sst_user'@'localhost' IDENTIFIED BY '<mot-de-passe-sst_user>'; GRANT RELOAD, PROCESS, LOCK TABLES, BINLOG MONITOR ON *.* TO 'sst_user'@'localhost';"

BINLOG MONITOR s’appelait REPLICATION CLIENT avant MariaDB 10.5 ; l’ancien nom reste accepté comme alias.

Surtout pas GRANT ALL, que donnent la moitié des tutoriels. Même raisonnement que wp_user limité à wp_lab.* : un compte de service n’a que les privilèges de son service.

28.2 — 60-galera.cnf, une commande pour les trois nœuds

sudo tee /etc/mysql/mariadb.conf.d/60-galera.cnf > /dev/null <<EOF
[mysqld]
bind-address             = 0.0.0.0

[galera]
wsrep_on                 = ON
wsrep_provider           = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name       = galera-sio
wsrep_cluster_address    = gcomm://10.0.20.10,10.0.20.11,10.0.20.12

wsrep_sst_method         = mariabackup
wsrep_sst_auth           = sst_user:<mot-de-passe-sst_user>

binlog_format            = ROW
default_storage_engine   = InnoDB
innodb_autoinc_lock_mode = 2

wsrep_node_address       = $(ip -4 -br addr show ens18 | awk '{print $3}' | cut -d/ -f1)
wsrep_node_name          = $(hostname)
EOF

Le <<EOF sans guillemets autorise le shell à évaluer les $( ) avant d’écrire : chaque nœud y inscrit sa propre adresse et son nom. Une seule commande pour trois machines, zéro risque de recopier la mauvaise valeur. (À l’inverse, le <<'EOF' du VirtualHost Apache — étape 25.4 — protégeait ${APACHE_LOG_DIR} de toute substitution.)

Les trois directives que l’on oublie toujours :

bind-address = 0.0.0.0 — renoncement assumé, à ne pas masquer. L’étape 24.5 avait posé bind-address = 10.0.20.10 comme premier verrou. Galera impose de l’élargir : le processus doit écouter sur plusieurs ports pour la réplication.

Ce n’est pas un recul, pour deux raisons : le verrou 2 reste entier — la règle SRV_HA → GALERA_NODES : 3306 est la seule porte depuis l’extérieur du VLAN 20 — et le verrou 3 aussi, le GRANT restreint par adresse d’origine.

Effet de bord bienvenu : les clones avaient hérité de bind-address = 10.0.20.10, une adresse qu’ils ne portent pas — MariaDB aurait refusé de démarrer avec Can't assign requested address. 60-galera.cnf étant lu après 50-server.cnf (ordre alphabétique), sa valeur écrase la précédente et corrige le problème au passage.

28.3 — Amorçage — l’ordre est impératif

# sur srv-mysql-01 UNIQUEMENT
sudo systemctl stop mariadb
sudo galera_new_cluster

# puis sur srv-mysql-02, attendre « Synced », ENSUITE srv-mysql-03
sudo systemctl start mariadb
sudo systemctl enable mariadb

galera_new_cluster ne se lance qu’une fois, et sur un seul nœud. Elle démarre MariaDB avec --wsrep-new-cluster, ce qui signifie : « je ne cherche personne, le cluster commence avec moi, mes données font référence ».

   galera_new_cluster  →  « je suis la semence »     → CRÉE le cluster
   systemctl start     →  « je cherche un cluster »  → le REJOINT

L’exécuter sur deux nœuds produirait deux clusters distincts portant le même nom, chacun convaincu d’être le vrai : c’est le split-brain, irréparable sans sacrifier des données.

C’est srv-mysql-01, et lui seul, parce qu’il détient WordPress.

Un nœud à la fois. Deux SST simultanés font travailler le donneur deux fois, sans gain.

enable à ne pas oublier sur les nœuds 2 et 3 : on les avait désactivés à l’étape 27.4. Sans cela, un redémarrage de VM les sortirait du cluster sans prévenir.

28.4 — Validation

sudo mariadb -e "SHOW STATUS WHERE Variable_name IN ('wsrep_cluster_size','wsrep_cluster_status','wsrep_local_state_comment','wsrep_incoming_addresses');"

Résultat obtenu, identique sur les trois nœuds :

| wsrep_local_state_comment | Synced                                 |
| wsrep_incoming_addresses  | 10.0.20.11:0,10.0.20.12:0,10.0.20.10:0 |
| wsrep_cluster_size        | 3                                      |
| wsrep_cluster_status      | Primary                                |

Primary ne signifie pas « nœud principal ». C’est l’état de la partition. On retrouvera ce mot au test 7.11, où il basculera en non-Primary avec deux nœuds arrêtés.

28.5 — Le vocabulaire à maîtriser

Pourquoi trois nœuds et non deux. Avec deux nœuds, la perte de l’un laisse le survivant avec 50 % des voix — pas la majorité. Il passerait en non-Primary et refuserait d’écrire. Deux nœuds n’apportent donc aucune disponibilité supplémentaire, seulement une copie des données. Le premier nombre utile est trois.

Procédure réutilisable complète : MO-2-Cluster-Galera.md

Étape 29 — srv-web-02 par clonage

Clone de srv-web-01, adressé en 10.0.10.11. Procédure identique à l’étape 27, à une différence majeure près : ici on n’efface rien.

   Nœuds Galera  →  /var/lib/mysql VIDÉ    (forcer un SST cohérent)
   Serveur web   →  on garde TOUT          (fichiers, wp-config.php, salts)

Les salts identiques sont indispensables. Ils signent les cookies de session. Avec des salts différents, un visiteur connecté sur un nœud serait vu déconnecté dès que le répartiteur l’enverrait sur l’autre. Le clonage garantit cette identité gratuitement — deuxième raison de cloner plutôt que réinstaller.

srv-web-01 utilise NetworkManager, pas ifupdown — conséquence de son environnement de bureau (dette H-3). L’adresse se change par nmcli, pas par /etc/network/interfaces. Incident H-12.

Une démonstration involontaire du verrou n°3

Au premier démarrage, srv-web-02 affiche « Error establishing a database connection » alors que srv-web-01 sert le site au même instant. 39-srv-web-02-grant-refuse.png

   GRANT ALL PRIVILEGES ON wp_lab.* TO 'wp_user'@'10.0.10.10'
                                                    ▲▲▲▲▲▲▲▲▲▲▲
                                        le clone arrive en 10.0.10.11

Une machine clonée à l’identique — mêmes fichiers, même mot de passe — est refusée uniquement parce que son adresse a changé. C’est la valeur concrète de la restriction d’origine posée à l’étape 24.6. Avec un 'wp_user'@'%', le clone aurait fonctionné du premier coup… et n’importe quelle machine du lab aurait pu joindre la base.

Un contrôle de sécurité qui te gêne toi est un contrôle qui gênerait aussi un attaquant.

Validation : compte temporaire créé pour 10.0.10.11, puis constaté répliqué sur le nœud 3 sans intervention — Galera réplique aussi les tables système.

Étape 30 — srv-ha et HAProxy

VM dédiée 10.0.10.5, Debian 13 sans bureau, HAProxy 3.0.11.

Nouvelle règle de pare-feu — SRV_HA → GALERA_NODES : 3306, placée avant le Reject de l’onglet WEB. 42-regle-web-srv-ha-galera.png

Avant cette règle, les trois nœuds apparaissaient DOWN avec L4CON in 0ms. L4CON = échec au niveau transport ; 0ms = refus immédiat, donc un Reject renvoyant un TCP RST — et non un Block silencieux, qui aurait produit un délai d’attente. 41-haproxy-galera-down.png puis 43-haproxy-stats-tout-vert.png — la même page, une règle d’écart.

Mis à jour le 05/11 : le contrôle mysql-check du bloc listen galera est remplacé par une sonde de synchronisation sur le port 9200 (tâche 10.23) : voir l’étape 62.

Procédure réutilisable complète : MO-3-HAProxy.md

Étape 31 — Bascule de WordPress derrière le répartiteur

L’oubli de la règle USERS a produit un ERR_CONNECTION_REFUSED depuis poste-win11, alors que le DNS résolvait correctement. 44-users-vers-srv-ha-refuse.png Le message du navigateur indique la couche en échec : ERR_NAME_NOT_RESOLVED aurait désigné le DNS, ERR_CONNECTION_REFUSED désigne le filtrage.

Validation : HTTP/2 200 avec l’en-tête link: <https://www.sio.internal/wp-json/> — trois preuves en une réponse (pas de boucle, WP_SITEURL appliqué, chaîne complète fonctionnelle).

Nettoyage — troisième temps de la migration : suppression des comptes [email protected] et @10.0.10.11, puis désactivation de l’ancienne règle WEB n°3.

Le bilan de la phase 10 sur la surface d’accès à la base :

	Avant	Après
Machines autorisées à joindre la base	1	1
Machines ayant besoin d’y accéder	1	2
Machines déployées	5	9

L’infrastructure a presque doublé, les autorisations n’ont pas bougé.

Étape 32 — lsyncd et le confinement par clé

Synchronisation à sens unique de wp-content, de srv-web-01 vers srv-web-02.

La clé SSH de root est enfermée dans une seule commande :

command="/usr/bin/rrsync -wo /var/www/wordpress/wp-content",no-agent-forwarding,
no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-ed25519 AAAA…

Validation en trois temps :

Une clé root qui ne donne aucun accès root. Le privilège appartient à la commande forcée, pas au compte. Motif réutilisable pour toute automatisation : sauvegardes, supervision, déploiements.

rrsync confine par remappage, pas par refus — quel que soit le chemin demandé, il est préfixé par le répertoire autorisé. Plus robuste qu’une logique de refus, qui devrait anticiper toutes les formes d’échappement.

Deux pièges rencontrés : www-data a pour interpréteur /usr/sbin/nologin et ne peut donc pas servir de compte SSH ; et lsyncd ajoute par défaut l’option --protect-args (-s), que rrsync refuse — elle déplacerait les chemins hors de la ligne de commande et le rendrait aveugle. Correction : protect_args = false.

Procédure réutilisable complète : MO-3-HAProxy.md §4 et §7

Étape 33 — AD-Core-01 : contrôleur de domaine sio.internal

Objectif : disposer d’un annuaire centralisé — un compte par personne, créé à un seul endroit et valable sur toutes les machines du laboratoire.

A — Pourquoi Server Core, et pourquoi une seule fois

L’installation retenue est Server Core : pas d’interface graphique, administration en ligne de commande et à distance.

Le mode d’installation est définitif. Depuis Windows Server 2016, on ne convertit plus une installation Core en installation avec interface graphique, ni l’inverse. La VM AD-GUI qui existait auparavant a donc été supprimée, et son adresse 10.0.30.10 réattribuée à la nouvelle machine.

B — Préparer avant de promouvoir

Quatre éléments devaient être figés avant la promotion, parce qu’ils sont inscrits dans l’annuaire au moment où il se crée :

La promotion exige d’être connecté en tant qu’Administrateur local de la machine. C’est une exigence documentée par Microsoft, pas une recommandation : un autre compte d’administration, même membre du groupe des administrateurs locaux, ne suffit pas pour créer une nouvelle forêt.

C — Installer le rôle, puis créer la forêt

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

-IncludeManagementTools n’est pas facultatif. Sans lui, le rôle s’installe mais les commandes qui le pilotent — Install-ADDSForest, Get-ADDomain — n’existent pas. Sur Core, aucune console graphique ne vient compenser.

Un instantané Proxmox a été pris avant la promotion : c’est la seule opération de la séquence qui transforme la machine.

Install-ADDSForest -DomainName "sio.internal" -DomainNetbiosName "SIO" -InstallDns:$true -Force

Le mot de passe de restauration (DSRM) n’est pas le mot de passe administrateur. Il permet de démarrer le contrôleur en mode réparation quand l’annuaire lui-même est hors d’usage — donc le jour où les comptes du domaine, qui vivent dans l’annuaire, sont inutilisables. Il est demandé de façon masquée, et se note ailleurs que sur cette machine.

L’avertissement sur la délégation DNS est normal et ne se corrige pas. Le suffixe .internal n’existe pas sur Internet : il n’y a aucune zone parente à qui déléguer.

Niveaux fonctionnels : non précisés, donc laissés par défaut — ce qui donne ici Windows2025Domain et Windows2025Forest, les plus élevés disponibles.

Conséquence à connaître : un second contrôleur devra être un Windows Server 2025. Une version antérieure serait refusée. Élever un niveau fonctionnel est irréversible ; ici la valeur par défaut est déjà le maximum, ce qui ferme la porte aux contrôleurs plus anciens.

D — Le DNS

Après promotion, le contrôleur s’interroge lui-même — la promotion bascule le résolveur sur 127.0.0.1 sans intervention. Il fait autorité sur sio.internal ; pour tout le reste, il transmet la question :

Set-DnsServerForwarder -IPAddress 10.0.30.1 -PassThru

Dette T-11 — la sortie affiche UseRootHint : True : si le résolveur de pfSense ne répond pas, le contrôleur interroge directement les serveurs racine d’Internet, ce que la règle 6 de l’onglet ADM lui permet effectivement. Conservé délibérément : le pare-feu reste le point de passage unique, seul le résolveur cesse de l’être, et uniquement en mode dégradé. Voir §5.1 et MO-6 §8.3.

E — L’autorité de temps

AD-Core-01 détient le rôle PDC Emulator : dans un domaine, ce rôle est l’horloge de référence sur laquelle tous les membres s’alignent.

w32tm /config /reliable:yes /update

La panne que ce réglage évite est la plus déroutante d’un domaine. Un poste dont l’horloge a dérivé de plus de cinq minutes ne peut plus s’authentifier — et le message parle de mot de passe incorrect, de ticket invalide, de relation d’approbation rompue. Jamais de l’heure.

F — La relation d’approbation, et le piège des instantanés

Le mot désigne deux choses différentes, et la confusion coûte du temps :

Le message « La relation d’approbation entre cette station de travail et le domaine principal a échoué » désigne toujours le premier. Quand un poste rejoint le domaine, il y reçoit un compte d’ordinateur (POSTE-WIN11$) doté d’un mot de passe que les deux côtés conservent, et qui se renouvelle seul tous les 30 jours. La relation d’approbation, c’est la concordance de ces deux copies — rien de plus.

Ce qui la casse ici en priorité : la restauration d’un instantané Proxmox. Une VM jointe au domaine, restaurée à un état antérieur au dernier changement de mot de passe de machine, revient avec un secret périmé. Ce n’est pas une raison de renoncer aux instantanés — c’est une raison de savoir que, après une restauration, c’est la première panne à suspecter.

Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Repair -Credential (Get-Credential SIO\Administrateur)

Ne pas sortir le poste du domaine pour le rejoindre ensuite. C’est le réflexe répandu, et il est destructeur : l’objet ordinateur est supprimé puis recréé, avec ses appartenances à des groupes et ses stratégies ciblées. -Repair remet les deux secrets d’accord en quelques secondes, sans redémarrage.

Validation

dcdiag /q signale un échec du test DFSREvent, et c’est normal ici. Ce test lit le journal de réplication DFS sur 24 heures — fenêtre qui englobe la promotion. L’avertissement 6016 (« configuration non mise à jour dans AD ») a été émis à 10:30:21, pendant que l’annuaire démarrait ; 4602 confirme SYSVOL initialisé six secondes plus tard, et 6018 à 10:35:25 montre que le service a refait l’opération avec succès.

La méthode à retenir : devant une erreur dans un journal, chercher d’abord s’il existe un événement postérieur qui l’annule. Beaucoup d’avertissements de démarrage sont des tentatives qui finissent par aboutir.

Un point à surveiller : la zone contient aussi une adresse IPv6 lien-local (fe80::…) pour le contrôleur. Un client qui la reçoit en premier peut tenter de la joindre, échouer, puis basculer sur IPv4 — ce qui se traduit par des ouvertures de session lentes, sans message d’erreur. Première piste si la jonction d’un poste traîne.

Procédure réutilisable complète : MO-6-Windows-Server-Core.md — §6 la forêt, §8 le DNS, §11 la relation d’approbation

Étape 34 — Jonction de poste-win11 au domaine

Objectif : qu’un compte de l’annuaire ouvre une session sur le poste utilisateur, sans avoir jamais été créé localement.

A — L’ordre, et pourquoi il n’est pas interchangeable

   1. RENOMMER le poste            il s'appelait encore 26-09-MDS-01
   2. Basculer le DNS du VLAN 40   le poste doit pouvoir TROUVER le domaine
   3. Joindre
   4. Verifier des DEUX cotes

Renommer avant de joindre. Le nom du poste au moment de la jonction devient le nom de l’objet ordinateur dans l’annuaire. Le renommer ensuite impose de reprendre cet objet, ou laisse un orphelin portant l’ancien nom.

Rename-Computer -NewName "poste-win11" -Restart

Basculer le DNS avant de joindre, et non l’inverse. Un poste ne trouve pas un domaine par une adresse : il interroge le DNS. Avec 10.0.40.1 comme résolveur, il demanderait à pfSense, qui ne connaît pas sio.internal — la jonction échouerait sur un message ne mentionnant jamais le DNS.

B — Le DNS distribué au VLAN 40

Services → DHCP Server → onglet USERS → Servers

Ne pas conserver 10.0.40.1 en résolveur secondaire. C’est le réflexe naturel et c’est un piège : un membre du domaine qui dispose d’un second résolveur ignorant le domaine y basculera au moindre délai de réponse du premier, recevra NXDOMAIN sur un enregistrement de service, et conclura que le domaine n’existe pas. Les échecs deviennent intermittents, donc très difficiles à reproduire.

La résilience ne vient pas d’un second résolveur étranger au domaine, mais d’un second contrôleur — c’est l’objet de la dette T-8 et de AD-Core-02.

C — La vérification qui décide

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.sio.internal

_ldap._tcp.dc._msdcs.sio.internal   SRV   ad-core-01.sio.internal   Priority 0  Weight 100  Port 389
ad-core-01.sio.internal              A     10.0.30.10               Section: Additional

C’est littéralement ainsi qu’un poste trouve un domaine. Tout Active Directory repose sur ces enregistrements de service — d’où le fait qu’une panne de domaine soit presque toujours une panne de résolution de noms.

D — Joindre

$c = New-Object System.Management.Automation.PSCredential("SIO\Administrateur",(Read-Host "Mot de passe" -AsSecureString))
Add-Computer -DomainName "sio.internal" -Credential $c -Verbose
Restart-Computer -Force

Get-Credential ne fonctionne pas en session SSH : il ouvre une fenêtre graphique, qu’aucun bureau n’affiche. Read-Host -AsSecureString fait la même chose en console, avec une saisie masquée.

-Restart séparé de la jonction, volontairement. Tant que la jonction n’est pas confirmée, on ne redémarre pas : un redémarrage effacerait le message d’erreur. On sépare l’opération de sa conséquence.

-Force sur le redémarrage parce qu’une autre session était ouverte (la console de l’hyperviseur). À peser sur un serveur en production : la commande coupe le travail des utilisateurs connectés sans préavis.

E — Vérifier des deux côtés

Une seule vérification ne suffit pas. La relation d’approbation a deux moitiés : le poste peut se croire membre alors que l’objet a disparu de l’annuaire. C’est exactement la panne décrite au §F de l’étape 33.

Côté poste

(Get-CimInstance Win32_ComputerSystem) | Format-List Name, Domain, PartOfDomain
Test-ComputerSecureChannel
(Get-NetConnectionProfile).NetworkCategory

Côté contrôleur

Get-ADComputer poste-win11 -Properties Created | fl Name,DNSHostName,Created,Enabled

Validation

La preuve la plus parlante est la dernière ligne. Ce compte n’a jamais été créé sur poste-win11. Il vient de l’annuaire, et il y ouvre une session comme il en ouvre une sur le contrôleur. C’est l’objectif de l’étape, démontré : un compte par personne, créé à un seul endroit, valable partout.

Trois pertes d’accès SSH ont jalonné cette étape, pour trois causes différentes — une commande coupant sa propre session, un profil réseau basculé en Public, et une règle de pare-feu liée à un seul profil. Le détail et les enseignements sont dans l’incident H-15.

Procédure réutilisable complète : MO-6-Windows-Server-Core.md — §10 la jonction, §11 la relation d’approbation

Étape 35 — L’arborescence de l’annuaire

Objectif : ranger l’annuaire avant d’y créer quoi que ce soit, parce que l’emplacement d’un objet décide des stratégies qu’il recevra.

CN=Users et CN=Computers ne sont pas des unités d’organisation. Ce sont des conteneurs : aucune stratégie de groupe ne peut s’y lier. Un compte laissé là ne reçoit jamais que la stratégie du domaine entier.

   DC=sio,DC=internal
     └── OU=SIO                        racine de l'organisation
           ├── OU=Utilisateurs
           │     ├── OU=Direction
           │     ├── OU=Administratif
           │     └── OU=Technique
           ├── OU=Ordinateurs
           └── OU=Groupes

$racine = "DC=sio,DC=internal"
New-ADOrganizationalUnit -Name "SIO"          -Path $racine
New-ADOrganizationalUnit -Name "Utilisateurs" -Path "OU=SIO,$racine"
New-ADOrganizationalUnit -Name "Ordinateurs"  -Path "OU=SIO,$racine"
New-ADOrganizationalUnit -Name "Groupes"      -Path "OU=SIO,$racine"
foreach ($s in "Direction","Administratif","Technique") {
    New-ADOrganizationalUnit -Name $s -Path "OU=Utilisateurs,OU=SIO,$racine"
}

Pourquoi une racine OU=SIO. La racine du domaine contient OU=Domain Controllers, où vit AD-Core-01. Une stratégie posée à la racine retomberait aussi sur le contrôleur. Avec une racine d’organisation distincte, on vise toute l’entreprise sans jamais toucher à l’annuaire lui-même.

Un DistinguishedName se lit de droite à gauche : OU=Direction,OU=Utilisateurs,OU=SIO,DC=sio,DC=internal va du plus précis au plus général. Un chemin écrit à l’envers donne « objet introuvable », sans jamais dire que l’ordre est faux.

Validation : les sept unités sont créées (SIO, Utilisateurs, Direction, Administratif, Technique, Ordinateurs, Groupes).

Étape 36 — Rediriger les emplacements par défaut, et ranger le poste

redirusr "OU=Utilisateurs,OU=SIO,$racine"
redircmp "OU=Ordinateurs,OU=SIO,$racine"
Move-ADObject -Identity (Get-ADComputer poste-win11).DistinguishedName -TargetPath "OU=Ordinateurs,OU=SIO,$racine"

redircmp corrige une limite réelle d’Active Directory : au moment de la jonction, un poste ne peut pas indiquer où il veut atterrir. Sans cette redirection, chaque poste joint doit être déplacé à la main, et celui qu’on oublie ne reçoit aucune stratégie machine, sans qu’aucun message ne le signale.

POSTE-WIN11 avait été joint avant la redirection : il était dans CN=Computers. Le déplacement le range, en conservant son SID et sa relation d’approbation.

Validation

Étape 37 — Les comptes utilisateurs

Six comptes, deux par service : de quoi démontrer un groupe et une stratégie ciblée.

$mdp = Read-Host "Mot de passe initial" -AsSecureString

$users = @(
  @{P="Axel";   N="Gouirand"; I="a.gouirand"; S="Technique"},
  @{P="Marie";  N="Durand";   I="m.durand";   S="Technique"},
  @{P="Claire"; N="Moreau";   I="c.moreau";   S="Direction"},
  @{P="Julien"; N="Petit";    I="j.petit";    S="Direction"},
  @{P="Sophie"; N="Lefevre";  I="s.lefevre";  S="Administratif"},
  @{P="Thomas"; N="Bernard";  I="t.bernard";  S="Administratif"}
)

foreach ($u in $users) {
  $p = @{
    Name                  = "$($u.P) $($u.N)"
    GivenName             = $u.P
    Surname               = $u.N
    DisplayName           = "$($u.P) $($u.N)"
    SamAccountName        = $u.I
    UserPrincipalName     = "$($u.I)@sio.internal"
    Path                  = "OU=$($u.S),OU=Utilisateurs,OU=SIO,$racine"
    AccountPassword       = $mdp
    Enabled               = $true
    ChangePasswordAtLogon = $true
  }
  New-ADUser @p
  Write-Host "cree : $($u.I) -> $($u.S)"
}

Trois pièges rencontrés pendant cette étape.

Piège	Ce qui s’est passé	Parade
Collage tronqué	La commande New-ADUser sur une seule ligne a été coupée par le terminal : -Path et la suite ont disparu, Write-Host s’est retrouvé collé derrière, d’où « paramètre positionnel introuvable ». Les six appels ont échoué, rien n’a été créé	Le splatting ci-dessus : une table de hachage, un paramètre par ligne, passée avec @p
Bloc en attente	Les >> en début de ligne signalent un bloc multiligne non terminé : PowerShell n’exécute que sur une ligne vide	Appuyer sur Entrée une fois de plus
Variables perdues	Une nouvelle session SSH a effacé $users, $mdp et $racine : la boucle s’est exécutée sur une variable vide, sans erreur ni création	Reposer les variables. Dès qu’une suite de commandes en dépend, en faire un fichier .ps1

Une boucle sur une variable vide ne signale rien : zéro itération, zéro message. Un silence n’est pas un succès : il faut toujours contrôler le résultat.

Validation : les six comptes sont créés dans les trois unités de service (confirmé).

Étape 38 — Les groupes, selon la règle AGDLP

   A                    G                      DL                            P
   a.gouirand  ──►  GG-Technique  ──►  DL-Partage-Technique-Modifier  ──►  le dossier
   m.durand                                                                 (plus tard)
   QUI                 le rôle              la ressource + le niveau

$grp = "OU=Groupes,OU=SIO,$racine"
foreach ($s in "Direction","Administratif","Technique") {
  New-ADGroup -Name "GG-$s" -GroupScope Global -GroupCategory Security -Path $grp
  $m = Get-ADUser -Filter * -SearchBase "OU=$s,OU=Utilisateurs,OU=SIO,$racine"
  Add-ADGroupMember -Identity "GG-$s" -Members $m
}
New-ADGroup -Name "DL-Partage-Technique-Modifier" -GroupScope DomainLocal -GroupCategory Security -Path $grp
Add-ADGroupMember -Identity "DL-Partage-Technique-Modifier" -Members "GG-Technique"

-GroupCategory Security est obligatoire. Un groupe de distribution ne donne aucun droit : on lui attribue des permissions et rien ne s’applique.

Pourquoi deux groupes au lieu d’un. Qui est dans une équipe change souvent ; quelles ressources elle atteint change rarement. Avec cette chaîne, une arrivée se règle par un seul Add-ADGroupMember dans GG-Technique, sans jamais rouvrir les permissions d’un dossier.

Un seul groupe DL- a été créé, celui qui démontre la chaîne : en créer six maintenant, c’est six objets à maintenir pour rien.

Validation : la console Utilisateurs et ordinateurs Active Directory liste dans OU=SIO → Groupes les quatre groupes de sécurité attendus.

Étape 39 — La console graphique sur poste-win11 (RSAT)

Objectif : retrouver la console classique pour explorer l’annuaire, alors que le contrôleur est en Server Core et n’en a pas.

Add-WindowsCapability -Online -Name "Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0"
runas /user:SIO\Administrateur "mmc dsa.msc"

Les quatre tildes font partie du nom : Windows nomme ses composants Nom~Éditeur~Architecture~Langue~Version, et les champs vides laissent les séparateurs.

Être administrateur local ne donne aucun droit dans l’annuaire. POSTE-WIN11\admin suffit pour installer les outils, pas pour les utiliser : d’où runas avec SIO\Administrateur. Ce sont deux autorités distinctes que la jonction ne mélange pas.

L’installation a d’abord semblé bloquée

La barre de progression est restée figée plus de 20 minutes. Le diagnostic a porté sur la résolution de noms :

Le contraste entre les tests est ce qui a désigné la cause. Les deux serveurs DNS répondaient quand on les interrogeait directement, mais le test passant par le résolveur du système échouait : c’est le cache DNS du poste qui servait un échec mémorisé. Windows met en cache les échecs, pas seulement les succès.

Piège de lecture : Resolve-DnsName … | select -First 2 n’affichait que les CNAME de la chaîne, sans adresse. Une colonne IPAddress vide ne signifie pas un échec. Pour voir l’adresse : | ? IPAddress | select Name, IPAddress.

La cause exacte de la lenteur de l’installation n’est pas établie. Le vidage du cache a rétabli la résolution, l’installation a été relancée, puis s’est terminée. Rien ne prouve que le cache en était la seule responsabilité.

Validation : la console s’ouvre sur poste-win11 et affiche sio.internal avec l’arborescence SIO (Groupes, Ordinateurs, Utilisateurs).

Procédures réutilisables : MO-9-Comptes-Active-Directory.md — les unités, les comptes, les groupes et le quotidien d’un administrateur

Étape 40 — Un accès externe sans rien ouvrir côté lab (Pangolin)

Objectif : permettre à une personne extérieure (formateur, puis examinateurs) de voir le lab, sans ouvrir le moindre port sur le réseau de l’école et sans donner l’accès à tout le réseau comme le fait le tailnet (dette T-6).

Le principe : le lab ne reçoit rien, il sort. Un conteneur « connecteur » installé sur srv-docker ouvre un tunnel WireGuard sortant (UDP 51820) vers un serveur Pangolin placé hors du lab (sur l’hyperviseur personnel d’Axel, qui a une adresse publique). Les visiteurs arrivent sur ce serveur, s’authentifient, puis sont acheminés à travers le tunnel vers une ressource précise.

Aucune règle de pare-feu n’a été ajoutée au lab. Le connecteur agit depuis srv-docker, déjà dans l’onglet ADM : la règle n°1 de l’onglet (ADM subnets → ADM address : PORTS_ADMIN_FW) laisse passer le flux vers l’interface d’administration, et la règle n°6 (ADM subnets → any) laisse sortir le tunnel.

Le tunnel hérite de ce que srv-docker atteint. Le connecteur se trouve dans le VLAN 30, donc tout ce que ce VLAN peut joindre, le tunnel le peut. La parade n’est pas dans Pangolin mais dans le pare-feu du lab : borner ce que srv-docker peut atteindre, et ne publier que des ressources ciblées. Voir la dette T-12.

Validation :

• docker logs pangolin-site affiche Tunnel connection to server established successfully!, sans Ping attempt … failed ensuite ;
• la liste d’états de pfSense (Diagnostics → States, filtrée sur l’adresse publique du serveur) montre une ligne UDP vers le port 51820, côté ADM et côté WAN ;
• dans une fenêtre de navigation privée, l’URL d’une ressource affiche l’écran d’authentification de Pangolin, pas l’application.

Procédure complète : MO-10-Pangolin.md — installation du serveur, DNS, certificat joker, connecteur, ressources, diagnostic. Incident documenté : H-17.

56-pangolin-ressource-termix-saine.png · à déposer : 61-pangolin-tunnel-etabli.png, 62-pangolin-auth-navigation-privee.png

Étape 41 — Publier l’interface de pfSense : les noms alternatifs

Objectif : atteindre l’interface d’administration de pfSense par un nom de domaine (pfsense.pangolin.<domaine>) à travers Pangolin, en plus de l’adresse IP.

Contexte : la cible de la ressource est https://10.0.30.1:443 (HTTP/2 200 constaté depuis srv-docker ; le port 80 ne répond pas). pfSense a un certificat auto-signé.

Le problème rencontré : appelée par son nouveau nom, l’interface répond

Potential DNS Rebind attack detected, see https://en.wikipedia.org/wiki/DNS_rebinding
Try accessing the router by IP address instead of by hostname.

pfSense ne sert son interface qu’aux noms qu’il connaît (son nom d’hôte, ses adresses). Un nom inconnu est traité comme une possible attaque par « DNS rebinding » : un site hostile qui ferait pointer son propre nom vers l’adresse privée du pare-feu pour atteindre son interface depuis le navigateur d’un administrateur.

La modification de pfSense (il s’agit d’un changement de configuration du pare-feu) :

Ne pas cocher « Disable DNS Rebinding Checks » : ce serait contourner la protection au lieu de déclarer ce nom comme légitime.

Le nom alternatif dit à pfSense : « ce nom m’appartient », sans désactiver la vérification pour les autres. C’est le même principe qu’un certificat qui énumère les noms qu’il couvre.

Validation :

1. https://pfsense.pangolin.<domaine> affiche l’écran de connexion de pfSense (et non le message rouge). Aucune connexion n’est nécessaire pour le test.
2. En navigation privée, l’écran d’authentification de Pangolin s’affiche d’abord.

Non vérifié : le comportement de pfSense après connexion (vérification de l’en-tête Referer) n’a pas été éprouvé : seul l’écran de connexion a été constaté. À contrôler avant tout usage.

On publie ici l’administration du pare-feu. C’est un essai, sans aucun compte externe sur cette ressource. Les deux barrières sont l’authentification de Pangolin puis le mot de passe de pfSense (voir H-08). À retirer à la fin de l’essai : supprimer la ressource et le nom alternatif. Dette T-12.

60-pfsense-dns-rebind.png · à déposer : 63-pfsense-alternate-hostnames.png, 64-pfsense-connexion-par-pangolin.png

Procédure : MO-10-Pangolin.md § 10.5 · Incident : H-17 dans Troubleshooting.md

Étape 42 — Publier la page de statistiques de HAProxy : un alias et une règle très étroite

Objectif : afficher la page de statistiques de HAProxy (http://10.0.10.5:8404, VLAN 10) dans l’accès externe, sans élargir ce que le connecteur peut atteindre.

Constat : depuis srv-docker, le test était resté sans réponse :

curl -sI --max-time 5 http://10.0.10.5:8404/ | head -1

Normal : le connecteur est sur SRV_BASTION, dont la règle ADM 4 n’autorise que PORTS_ADMIN (22 et 3389) vers LAB_NETS, et la règle 5 refuse le reste. La page est joignable depuis le poste de travail par Tailscale (non filtré), pas depuis le bastion.

Modification du pare-feu (deux temps, selon la convention « un alias = un usage ») :

Une règle plus large aurait suffi à faire marcher la page, et c’est précisément ce qu’on évite : SRV_BASTION → LAB_NETS : tout donnerait à l’accès externe un chemin vers tout le lab. Ici, un hôte et un port.

Validation : le même curl répond désormais HTTP/1.1 401 Unauthorized. Le 401 est la bonne nouvelle : la page est atteinte et réclame son propre identifiant. La colonne States de la règle se remplit (4 / 7 KiB constaté).

Le deuxième piège : « no available server »

La ressource Pangolin (type HTTP, cible http://10.0.10.5:8404) affichait « no available server » même après authentification. Le contrôle de santé de Pangolin demandait la page d’accueil, recevait un 401, et jugeait la cible hors service : le reverse proxy ne lui envoyait alors plus personne. Retirer le contrôle de santé de cette cible a réglé le problème. Incident H-18.

Contrepartie : sans contrôle de santé, Pangolin ne détecte plus que cette cible tombe. C’est acceptable pour une page de statistiques (elle est justement un indicateur), pas pour un service critique.

La page de statistiques affiche l’état des serveurs web et du cluster : à traiter comme les autres ressources d’essai (dette T-12).

Procédure : MO-10-Pangolin.md § 10.6 · Incident : H-18 dans Troubleshooting.md

Étape 43 — Sauvegarder les VM du lab sur le NAS de l’école, et restaurer pour prouver

Objectif : une sauvegarde automatique et testée de toutes les VM du pool SIO2527_Axel, sur le stockage réseau déjà déclaré dans Proxmox. L’annexe II.E exige une solution de sauvegarde ; jusque-là il n’existait que des exports manuels (DAT §8.4).

État des lieux (lecture seule) : stockage Syno (NFS, /mnt/pve/NAS-01, contenu « Backup » autorisé), 766 Go utilisés sur 2,87 To ; aucune tâche de sauvegarde dans Datacenter → Backup ; 11 VM dans le pool.

Essai sur une VM (srv-web-01, VM 110, mode snapshot, zstd) :

Test de restauration : l’archive restaurée en VM 136 (nouvel identifiant) sur storage-images en 3 min 20 s. La copie démarre, hostname = srv-web-01, Apache actif, fichiers de WordPress présents dans /var/www/wordpress. La copie de test a ensuite été supprimée et la VM d’origine relancée.

Une sauvegarde jamais restaurée n’est pas une sauvegarde. Le test a eu lieu avant la planification.

Deux pièges : restaurer sur l’identifiant d’origine écraserait la VM en service ; et sans la case « Unique », la copie garde la même adresse MAC que l’original (conflit si elle démarre en réseau). Voir MO-11 §5.3.

La tâche planifiée (Datacenter → Backup → Add) :

« Pool based » : sur un hyperviseur partagé, la tâche ne touche que ses propres VM. Réglée sur « All », elle sauvegarderait toutes les VM de tous les élèves.

Validation : la tâche apparaît dans Datacenter → Backup avec son Next Run. Première exécution automatique contrôlée le 15/10 : lancée à 02:00:03, terminée à 04:25:39 (2 h 25), TASK OK, les 11 VM sauvegardées, ≈ 75 Go d’archives pour la nuit (poste Windows 41 Go, contrôleur de domaine 14 Go, les autres de 0,8 à 5,5 Go). Deux avertissements : l’agent invité de la VM Windows ne tourne pas (pas de gel du système de fichiers) et le gel a échoué sur la VM du pare-feu (Resource deadlock avoided) ; dans les deux cas la sauvegarde s’est terminée.

Limites constatées (dette T-13) : plusieurs VM avaient leur disque sur le même NAS que leur sauvegarde, et chaque nuit recopiait tout (≈ 75 Go). Ces deux points sont traités à l’étape 44.

Procédure : MO-11-Sauvegarde-Proxmox.md

Étape 44 — Passer à des sauvegardes incrémentales : Proxmox Backup Server

Objectif : ne plus recopier chaque nuit ce qui n’a pas changé, et séparer les disques des VM de leurs sauvegardes. Réalisé le 15/10/2026.

44.1 Préalable : déplacer les disques des VM hors du NAS et du NVMe

Défait les 22-23/10 : les disques des VM sont revenus sur Syno (plus rapide) et c’est le datastore de PBS qui est passé sur storage-images. Voir l’étape 49.2.

Action : VM → Hardware → disque → Disk Action → Move Storage, cible storage-images, « Delete source » décoché (l’ancien disque reste en Unused Disk pour un retour arrière). Fait pour les 10 VM (disques système, efidisk et tpmstate des VM Windows compris), chaque tâche TASK OK. Filet de sécurité : les sauvegardes vzdump de la nuit.

Avertissement de Proxmox sur AD-Core-01 : moving disk with snapshots, snapshots will not be moved! : ses instantanés Proxmox ne suivent pas le disque. Les anciens disques ne seront supprimés qu’après décision sur ces instantanés (tâche 13.12).

Rallumage : le cluster Galera a dû être redémarré à froid (incident H-19) ; ensuite, tests réseau depuis le poste de travail : bases 3306 (×3 et via HAProxy), sites 200, AD (DNS, LDAP, Kerberos, SMB, RDP), Termix, pfSense, poste Windows : tous OK.

44.2 Le serveur PBS

44.3 La modification de pfSense : la première règle entrante du WAN

L’hyperviseur (10.1.0.253, côté WAN) ne connaît pas les réseaux du lab : il vise l’adresse WAN de pfSense, qui redirige vers PBS.

Une source, un port, une destination : toute autre machine de l’école reste refusée. C’est une exception assumée au « zéro règle entrante » de la phase 8 (voir T-1 et la matrice de flux §4.5).

Validation : depuis l’hyperviseur, curl -k https://10.1.0.197:8007/ → 200.

44.4 Branchement, sauvegarde, restauration

44.5 Rétention et planification

Le jeton de Proxmox ne peut pas supprimer : la rétention doit être faite par PBS. Si l’hyperviseur était compromis, l’historique des sauvegardes ne pourrait pas être effacé par lui.

Validation : configuration relevée sur captures. Première nuit automatique vers PBS (16/10), journal lu : lancée à 02:00:03, terminée à 02:36:11 (36 min, contre 2 h 25 en vzdump), 11 VM sauvegardées sans erreur (la plus longue : le poste Windows, 13 min ; la VM web, déjà suivie par sa carte des blocs modifiés : 25 s). La VM du serveur PBS a échoué (http upgrade request timed out) : elle a été sortie du pool (incident H-21), correction confirmée par la nuit suivante (voir ci-dessous). Relevés du même jour : Prune de 05:00 et Garbage Collection de 06:00 OK (0 B supprimé, 26,56 Mo en attente : un bloc n’est supprimé qu’après 24 h 05) ; Content : 11 groupes, un instantané daté du 16/10 pour chacun (deux pour la VM web) ; Summary : 75,95 Go utilisés sur 500 (15 %), facteur de déduplication 11,75 pour 795 Gio de disques provisionnés. Deuxième nuit (journal du 17/10 lu) : lancée à 02:00:05, terminée à 02:16:42 (16 min 37 s), 11 VM, TASK OK, VM du serveur PBS absente : la sortie du pool a réglé l’échec. Toutes les sauvegardes sont incrémentales (carte des blocs conservée) : ≈ 31 Gio modifiés au total, dont 23,2 Gio pour le poste Windows, 5,1 Gio pour le contrôleur de domaine et moins de 0,6 Gio pour chacune des 9 autres. Le datastore passe à 104,94 Go sur 500 (21 %), soit +29 Go en une nuit. Premier Verify réussi (54 min 52 s, tableau de bord PBS du 17/10). Anciennes archives vzdump supprimées le 17/10 (11 archives de la nuit du 15/10, 33 fichiers, ≈ 75 Go) : contrôle du nombre et de la taille avant, suppression nommée, fichiers d’autres personnes laissés (une archive de VM 101 de janvier 2025 : le numéro de VM ne suffit pas à désigner ses fichiers sur un NAS partagé). Reste : les anciens disques « Unused » (13.12).

Procédure : MO-12-Proxmox-Backup-Server.md · Incidents : H-19, H-20

Étape 45 — Préparer le pare-feu pour la supervision et les journaux (phase 14)

Objectif : poser à l’avance les alias et les règles dont auront besoin les deux futures machines de la supervision (VLAN 30, pas encore créées : srv-metriques 10.0.30.14 avec Prometheus, srv-supervision 10.0.30.15 avec Grafana, la réception des journaux et un accès au cluster Galera). Projet cadré le 15/10 ; rien n’est installé.

45.1 Quatre alias

45.2 Quatre règles

Toutes sont des « Pass » au-dessus du refus de leur onglet, sans journalisation. Les alias sont utilisés tels quels (un alias = un usage) ; seul le port 3306 est saisi en clair, comme la règle du répartiteur vers Galera.

45.3 Ce qui est volontairement laissé de côté

45.4 Un piège rencontré : la règle sans port de destination

La première version de la règle BDD avait été enregistrée sans port : la colonne Port affichait *, donc tout le TCP de la zone BDD vers SRV_SUPERVISION passait. Repéré à la lecture de la capture, corrigé le jour même (champ Destination Port Range → PORTS_SYSLOG). C’est le cas décrit en B-04 (règle sans port de destination).

84-pfsense-regle-bdd-sans-port.png (la règle avant correction)

Validation : alias et règles relevés sur captures, bandeau « The changes have been applied successfully » à chaque onglet. Les flux eux-mêmes ne sont pas testés : les deux machines n’existent pas encore (test à la construction : 14.3 et 14.5). Adresses .14 et .15 vérifiées libres le 18/10 : aucune réponse au ping ni au SSH depuis le poste d’administration (par Tailscale), alors que .12 et .13 répondent (témoins).

Matrice de flux : Matrice-de-flux.md §2, §3, §4.2, §4.3, §4.4 · Incident voisin : B-04

Étape 46 — Construire la supervision (1/2) : deux machines, Prometheus et les premières sondes (phase 14)

Objectif : poser les deux machines du projet de supervision (cadré le 15/10) et mettre en service la mesure de disponibilité : Prometheus lit des sondes de service, un blackbox exporter les exécute. La partie journaux (rsyslog vers le cluster), Grafana et les alertes restent à faire (tâche 14.5 et suivantes).

46.1 Les deux machines