Ordre de montage — VM / infra / applications (archi distribuée)

Internet est réel (les VPS et les homelabs ont de vraies sorties publiques). Londres est le hub : tous les tunnels IPsec des sites distants y terminent.

Placement (qui héberge quoi)

Emplacement physique	Rôle projet	Réseaux
Cluster 3 nœuds d'Alban (Ceph + SDN)	Londres – Siège (prod) + hub IPsec + Sydney (VNet)	LAN users 10.10.10.0/24 · LAN serveurs 10.10.20.0/24 · Sydney 10.40.10.0/24
Nœud Proxmox de Quentin	USA – Ponte-Vedra	10.20.10.0/24
VPS #1 (IP publique)	Datacenter Cloud (Nextcloud) — joignable en HTTPS via Internet, sans tunnel	172.16.50.0/24
VPS #2 (IP publique)	Monaco – PRA	LAN PRA = 10.10.20.0/24 (L2 étiré depuis Londres)

VPN : IPsec (IKEv2) en étoile, terminant à Londres. USA, Sydney et Monaco montent chacun un tunnel vers Londres. Le datacenter ne monte pas de tunnel (liaison Internet/HTTPS). Les nomades arrivent aussi sur Londres (IKEv2 road-warrior).

---

ÉTAPE 0 — Fondations (avant toute VM service)

• 0.1 Cluster d'Alban : vérifier quorum, santé Ceph (ceph -s), activer la HA (groupe HA + ressources).
• 0.2 Point d'entrée public de Londres (indispensable car Londres est le hub IPsec) : IP fixe ou DDNS, + redirection sur la box des ports UDP 500 / UDP 4500 (NAT-T) et ESP vers le FW-LON. Si le FAI le rend impossible, faire initier les tunnels par les sites distants (Londres en répondeur) ou conserver un relais sur un VPS — la terminaison logique reste Londres.
• 0.3 SDN Proxmox (cluster) : créer la zone VXLAN/EVPN (servira au stretch L2 du PRA) + les VNets : LON-users, LON-serveurs, SYD-LAN.
• 0.4 VM — PBS (Proxmox Backup Server) · Linux · sur le cluster → backups + réplication dès le départ, indispensable pour le RPO du PRA.

---

ÉTAPE 1 — Firewalls / routeurs par site (T4 partie 1)

Une VM OPNsense (ou pfSense) par emplacement. WAN + LAN, NAT, accès Internet, règles de base. Les FW des VPS portent une vraie IP publique ; ceux des homelabs (Alban, Quentin) sont derrière NAT.

• 1.1 VM — FW-LON · OPNsense · cluster d'Alban · 3 IF : WAN, LAN-users (10.10.10.1), LAN-serveurs (10.10.20.1) — concentrateur IPsec
• 1.2 VM — FW-USA · OPNsense · nœud de Quentin · WAN + LAN (10.20.10.1)
• 1.3 VM — FW-DC · OPNsense · VPS #1 · WAN public + LAN (172.16.50.1) (ou le VPS sert directement de passerelle)
• 1.4 VM — FW-MON · OPNsense · VPS #2 · WAN public + LAN-PRA
• 1.5 VM — FW-SYD · OPNsense · cluster d'Alban (VNet) · WAN + LAN (10.40.10.1)

---

ÉTAPE 2 — Tunnels IPsec inter-sites (T4 partie 2) — config, pas de VM

• 2.1 Sur FW-LON (hub), créer une connexion IPsec IKEv2 par site distant : USA, Sydney, Monaco. Phase 1 : AES-256 / SHA-256 / DH 14. Phase 2 : réseaux locaux à interconnecter (ex. 10.10.20.0/24 ↔ 10.20.10.0/24).
• 2.2 Config miroir sur FW-USA, FW-SYD, FW-MON. Activer NAT-T (homelabs derrière box). Côté qui initie : les sites distants vers Londres si Londres n'a pas d'IP fixe.
• 2.3 Règles de filtrage sur l'interface IPsec : n'autoriser que le trafic utile (AD, RDP, DNS, supervision…).
• 2.4 Datacenter (VPS #1) : aucun tunnel — la liaison Nextcloud ↔ Londres se fait en HTTPS via Internet.
• 2.5 Test : ping Londres → USA et Londres → Sydney à travers les tunnels.

---

ÉTAPE 3 — Identité : Active Directory + DNS (T2 partie 1)

• 3.1 VM — DC1-LON · Windows Server · cluster d'Alban · AD DS (forêt atp.local) + DNS · IP 10.10.20.10
• 3.2 VM — DC2-USA · Windows Server · nœud de Quentin · DC additionnel + DNS · IP 10.20.10.10 (réplication via le tunnel IPsec)
• 3.3 Config AD Sites & Services (un site AD par localisation) + vérifier la réplication inter-sites.
• 3.4 Test HA réelle : migrer/éteindre le nœud d'Alban hébergeant DC1 → la HA Proxmox le relance ailleurs, et l'auth tient via DC2.
• (option) 3.5 VM — CA · rôle AD CS (sur DC1 ou VM dédiée) → certificats pour RDS Gateway et VPN nomade.

---

ÉTAPE 4 — Bureaux virtuels RDS (T2 partie 2)

• 4.1 VM — RDS-LON · Windows Server · cluster d'Alban · rôles RD Session Host + Connection Broker + RD Web Access + RD Gateway · joint à atp.local · IP 10.10.20.20
• (option HA) 4.2 VM — RDS-LON-2 · 2e Session Host derrière le Broker.
• 4.3 Publier un bureau / RemoteApp pour le groupe « staff arbitral ». Test session interne.

---

ÉTAPE 5 — Accès nomades (T5)

• 5.1 Serveur VPN road-warrior IKEv2 sur FW-LON (cohérent avec l'IPsec inter-sites) → terminaison à Londres.
• (option) 5.2 Rôle NPS/RADIUS sur DC1 → auth des nomades via comptes AD.
• 5.3 VM — NOMADE · client Windows de test · placé hors site (sur un VPS ou en réseau extérieur).
• 5.4 Test bout-en-bout : NOMADE → VPN Londres → RDS → bureau virtuel.

---

ÉTAPE 6 — Plateforme cloud de fichiers (T3)

• 6.1 VM — NEXTCLOUD-DC · Debian/Ubuntu · VPS #1 · IP 172.16.50.10 · exposé en HTTPS public
• 6.2 Brancher l'auth sur l'AD (LDAP, via Internet/HTTPS) + créer les groupes (devops, cybersécurité…).
• 6.3 Vérifier les 4 besoins : lien web · consultation navigateur · groupes/répertoires communs · client de synchro.
• 6.4 PCA : synchro régulière des données vers Londres (rsync/tâche planifiée, en HTTPS).
• 6.5 Préparer la copie (snapshot/export PBS) destinée au PRA.

---

ÉTAPE 7 — Supervision & alerting (T6)

• 7.1 VM — ZABBIX-LON · Debian/Ubuntu · cluster d'Alban · IP 10.10.20.30
• 7.2 Agent Zabbix sur tous les serveurs + SNMP sur les OPNsense.
• 7.3 Centralisation syslog (firewalls + serveurs) + seuils d'alerte (triggers).
• 7.4 Tableau de bord + action d'alerte (mail/notif). Provoquer une panne en démo.
• (option) 7.5 Grafana sur la même VM pour des dashboards plus visuels.

---

ÉTAPE 8 — PRA sur Monaco (T7) — le morceau délicat

Le tunnel L2 du PRA est distinct des tunnels IPsec L3 inter-sites : il sert à garder le même plan d'adressage que Londres.

• 8.1 Stretch L2 : étendre le VNet LAN-serveurs de Londres jusqu'à Monaco via la zone SDN VXLAN/EVPN (ou un tunnel L2 type OpenVPN-TAP si le VPS ne supporte pas le VXLAN) → même /24 des deux côtés, rien à reconfigurer à la bascule.
• 8.2 VM — DC-PRA · Windows Server · VPS #2 · DC additionnel + DNS dormant · IP 10.10.20.11
• 8.3 VM — NEXTCLOUD-PRA · copie répliquée de Nextcloud · VPS #2
• 8.4 VM — RDS-PRA · copie répliquée du RDS · VPS #2
• 8.5 Réplication pvesr / PBS des VM critiques vers Monaco → viser RPO ≤ 36 h.
• 8.6 Plan de bascule DNS + procédure (= livrable C4). Test de bascule chronométré → RTO ≤ 48 h.

---

ÉTAPE 9 — Clients & validation

• 9.1 VM — WIN-CLIENT-LON · Windows 10/11 · cluster d'Alban · joint au domaine · test ouverture session + accès fichiers.
• 9.2 Répéter la démo complète + préparer le plan de repli (tout reproductible sur le seul cluster d'Alban si un lien distant lâche le jour J).

---

Récap — inventaire des VM

Firewalls (5) : FW-LON (hub IPsec) · FW-USA · FW-DC · FW-MON · FW-SYD Windows (5–7) : DC1-LON · DC2-USA · RDS-LON · DC-PRA · RDS-PRA (+ RDS-LON-2, CA en option) Linux (4) : PBS · NEXTCLOUD-DC · NEXTCLOUD-PRA · ZABBIX-LON Clients (2) : WIN-CLIENT-LON · NOMADE

➡️ ~16 VM cœur (jusqu'à ~19 avec les options).

---

Répartition du travail (suggestion)

• Alban : cluster Londres (SDN, HA, FW-LON hub IPsec, DC1, RDS, Zabbix, PBS) + stretch L2.
• Quentin : site USA (FW-USA, DC2) + montage du tunnel IPsec vers Londres.
• VPS : datacenter Nextcloud (#1) et PRA Monaco (#2) — à répartir dans l'équipe.