Landing zone OVHcloud : architecture hub-and-spoke avec OPNsense HA

Table des matières :

1. Landing zone OVHcloud : ce que “hub-and-spoke” change vraiment (et ce que ça ne résout pas)
2. Contraintes OVHcloud qui dictent le design : vRack, Failover IP, Anti-DDoS, routage
3. OPNsense HA : CARP/pfsync/XMLRPC, et les pièges spécifiques OVHcloud
4. Blueprint hub-and-spoke : adressage, zones, routage inter-spokes, egress contrôlé
5. Spokes e-commerce : placement de HAProxy, isolation MySQL/Redis, et exploitation (monitoring + runbooks)

Landing zone OVHcloud : ce que “hub-and-spoke” change vraiment (et ce que ça ne résout pas)

Une landing zone OVHcloud n’est pas un slogan “cloud”, c’est un socle d’architecture : plan d’adressage, segmentation, routage, identité, journalisation, et chemins de déploiement répétables. En hub-and-spoke, le hub centralise les fonctions transverses (pare-feu, VPN, egress, inspection, DNS internes, éventuellement proxy) et les spokes hébergent les workloads (front e-commerce, backoffice, ETL, observabilité, CI, etc.). L’intérêt est surtout opérationnel : réduire la surface d’attaque et éviter que “tout parle à tout”, ce que le cœur d’OVHcloud (comme la plupart des providers) ne vous impose pas par défaut.

Le bénéfice réel, côté e-commerce, c’est la maîtrise du trafic Est-Ouest (entre composants) autant que Nord-Sud (Internet). Une boutique PrestaShop typique finit vite avec : front + backoffice, workers, MySQL, Redis, ElasticSearch, outils internes, jobs, monitoring. Sans segmentation, un seul hôte compromis peut pivoter. La landing zone impose des zones (DMZ / App / Data / Admin) et des règles minimales, ce qui s’intègre naturellement à votre modèle de menaces (accès BO, API, webhooks, flux ERP).

Un point souvent sous-estimé : le hub-and-spoke ne sert pas uniquement à “bloquer”, il sert aussi à rendre explicites des dépendances qui existent déjà mais sont implicites (et donc difficiles à auditer). Exemple concret en contexte e-commerce :

• Le front doit accéder à un service de paiement (sortant 443 vers des FQDN spécifiques).
• Les workers doivent accéder à l’ERP (sortant 443 + parfois VPN/IPsec).
• Le backoffice doit accéder à l’admin (entrant via VPN uniquement, pas “ouvert” au monde).
• La base ne doit jamais initier de flux sortants “généraux”.

Avec un hub, vous pouvez documenter ces flux, les appliquer, puis les surveiller (journaux, alertes, métriques). Et en incident, la question “qui parle à quoi ?” a une réponse reproductible.

Sur le plan sécurité, ce design colle à l’approche “assume breach”. NIST définit le Zero Trust comme suit : « Zero Trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. » (NIST SP 800-207, 2020 : NIST SP 800-207). Traduction opérationnelle : vous n’accordez pas la confiance “parce que c’est dans le même VLAN”, vous la gagnez par règle explicite, identité, et journalisation.

Ce que hub-and-spoke ne résout pas (et c’est important de le dire) :

• Les vulnérabilités applicatives : une RCE dans un module PrestaShop reste une RCE. La segmentation limite le blast radius, mais ne “corrige” pas l’appli.
• Les erreurs de configuration : un NAT trop large, une règle “any/any”, ou un DNS mal routé peuvent casser la prod aussi sûrement qu’une panne.
• La performance L7 : un design réseau propre évite du bruit et des chemins incohérents, mais ne remplace pas l’optimisation (cache, DB, PHP-FPM, CDN).
• La gouvernance : si les droits d’admin, les secrets, et les processus de change ne sont pas maîtrisés, l’architecture ne vous sauvera pas.

Enfin, côté “GEO”/contexte : OVHcloud est très souvent choisi en France/Europe pour des contraintes de localisation des données et de conformité (RGPD). Une landing zone bien conçue aide à démontrer des contrôles (journalisation, séparation des environnements, moindre privilège réseau), mais n’est pas une preuve de conformité à elle seule : c’est un élément du dispositif (technique + organisationnel).

Contraintes OVHcloud qui dictent le design : vRack, Failover IP, Anti-DDoS, routage

Sur OVHcloud, une landing zone sérieuse s’appuie quasi systématiquement sur vRack (L2 privé) pour isoler les flux inter-serveurs et éviter de faire transiter du trafic interne sur le réseau public. Le vRack sert de “backplane” à vos spokes (subnets privés) et au hub (interfaces internes du firewall). Sans vRack, vous vous retrouvez à bricoler du VPN inter-nœuds ou à accepter une exposition inutile. Référence OVHcloud vRack : OVHcloud vRack

Dans la pratique, le vRack devient votre switch logique. Deux implications d’architecture :

• Vous restez maître de la segmentation (par sous-réseaux, VLAN si vous les utilisez, et politiques firewall au hub).
• Vous devez penser aux domaines de broadcast et aux erreurs L2 : une boucle, un mauvais trunk, un VLAN mal tagué… et vous pouvez créer des pannes “bizarres” difficiles à diagnostiquer. Autrement dit, le vRack est un accélérateur… aussi pour les mauvaises pratiques.

La HA d’un pare-feu en IaaS dépend ensuite d’un point très concret : comment vous tenez une IP stable côté Internet. Sur des serveurs dédiés, OVHcloud propose les Failover IP (IP basculables) et le mécanisme de Virtual MAC, ce qui permet d’attacher une IP à un nœud actif et de la déplacer en cas de failover (manuellement ou via API). Dans les faits, c’est souvent plus fiable que de vouloir faire du VRRP/CARP “comme on-prem” sur un WAN provider qui filtre/prohibe certains protocoles.

À ce stade, une règle de design simple (et très “terrain”) :

• VIP interne (CARP) = dans le vRack pour servir de passerelle aux spokes.
• IP publique stable = mécanisme provider (Failover IP) pour éviter la dépendance à des protocoles L2/L3 non garantis côté WAN.

Enfin, ne confondez pas Anti-DDoS réseau d’OVHcloud avec une politique applicative. Le “scrubbing” au niveau opérateur protège de nombreuses attaques volumétriques, mais ne remplace ni un WAF, ni des ACL L7, ni de la limitation de débit au bon endroit. Typiquement : vous pouvez être “protégé” d’un SYN flood et quand même tomber à cause d’une saturation CPU sur TLS, d’une explosion de requêtes coûteuses, ou d’un endpoint applicatif abusé.

Un mini-checklist “réalité OVHcloud” avant de figer le design :

• Avez-vous un vRack rattaché à tous les nœuds concernés (hub et spokes) ?
• Votre plan IP évite-t-il les collisions avec des réseaux courants (ex. 192.168.0.0/16 qu’on retrouve dans beaucoup de VPN d’entreprise) ?
• Vos Failover IP (si utilisées) sont-elles bien documentées : où elles pointent, comment elles basculent, qui a le droit de le faire ?
• Avez-vous distingué accès d’admin (VPN/bastion) et accès public (reverse-proxy/DMZ) ?
• Avez-vous prévu une sortie Internet contrôlée (egress) plutôt qu’un “NAT open bar” ?

Pour une approche plus “ops” des VPS/OVHcloud (DDoS, sécurité, SMTP), vous pouvez recouper avec : VPS OVHcloud : sécurité, anti-DDoS, SMTP 25 et bonnes pratiques admin.

OPNsense HA : CARP/pfsync/XMLRPC, et les pièges spécifiques OVHcloud

Référence de versions pour cadrer les comportements : OPNsense 25.1 (FreeBSD 14.x), car c’est une base largement déployée en prod. Prérequis matériels : 2 nœuds (physiques ou instances), idéalement 3 interfaces par nœud (WAN, LAN/vRack, SYNC dédié). Prérequis réseau : L2 commun sur LAN (vRack), et un mécanisme stable pour l’IP publique (Failover IP ou équivalent). Risque évident : une mauvaise config HA vous coupe l’egress (NAT) et/ou l’inbound (VIP), donc prévoyez une fenêtre et un plan de rollback.

La HA “classique” OPNsense repose sur trois briques :

• CARP : Virtual IP “partagée” entre nœuds (actif/passif) pour que les clients aient une passerelle stable.
• pfsync : synchronisation des states du pare-feu (table d’états pf) pour éviter de casser toutes les connexions lors d’une bascule.
• XML-RPC config sync : synchronisation de configuration (règles, objets, etc.).

Docs OPNsense : Docs OPNsense — HA/CARP

Ce que ces briques impliquent concrètement (et qui déclenche la plupart des incidents) :

• CARP traite la présence de l’IP (VIP) et l’élection master/backup.
• pfsync traite la continuité des connexions… mais uniquement si vos flux repassent bien par le nouveau master (sinon, vous créez de l’asymétrie).
• XML-RPC sync traite la convergence de configuration (éviter “master a une règle, backup une autre”).

Le piège OVHcloud le plus fréquent : vouloir faire CARP sur l’interface WAN publique. CARP utilise IP protocol 112 + multicast, et selon votre contexte OVH (groupe de produits, filtrage anti-spoofing, topologie L2), ça peut simplement ne pas passer. En pratique, vous faites souvent :

• CARP sur LAN/vRack (VIP interne = passerelle des spokes)
• IP publique stable via Failover IP attachée au nœud actif (mécanisme provider), plutôt qu’un CARP WAN.

Autre piège : croire que pfsync “suffit”. Si vous ne séparez pas l’interface SYNC (au minimum VLAN dédié dans le vRack), vous mélangez trafic de prod et sync des states. Résultat : jitter, latence, et au pire une congestion qui provoque des fausses détections de panne. Dans OPNsense, on évite aussi de synchroniser n’importe quoi : les certificats, les secrets VPN, et certains plugins demandent une stratégie explicite (export chiffré, vault, GitOps), sinon vous créez un couplage dangereux.

Un autre piège (plus subtil) en hub-and-spoke : l’asymétrie de routage. Exemple typique :

• Spoke A envoie vers Internet via le hub (OK).
• Le retour Internet arrive via l’IP publique basculée (OK).
• Mais un flux inter-spoke (A → B) peut, selon les routes, contourner le hub si vous avez “optimisé” des routes directes. Résultat : pfsync ne sert plus, et vous avez des symptômes bizarres (connexions qui “collent” à un nœud, timeouts aléatoires).

Pour réduire ce risque, vous cherchez le comportement suivant : tous les flux inter-spokes passent par le hub (au moins pour les zones sensibles). Ça coûte un peu de performance, mais ça achète énormément en lisibilité et en contrôle.

À garder en tête, parce que beaucoup de HA “marchent en labo” : la complexité se paie. RFC 1925 (The Twelve Networking Truths) rappelle : « It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. » (RFC 1925, 1996 : RFC 1925). Traduction : ne mettez pas dans la HA du firewall la résolution de vos problèmes d’adressage, de DNS, de CM, et de monitoring. Stabilisez d’abord le réseau.

Enfin, une note pragmatique “prod” : la HA réseau est souvent mise en place pour réduire le risque d’arrêt… mais l’impact financier d’un incident de sécurité est généralement plus élevé. À titre d’ordre de grandeur, IBM rapporte un coût moyen mondial d’une violation de données de 4,88 M$ (IBM, Cost of a Data Breach Report 2024 : IBM Cost of a Data Breach Report 2024). Ça ne remplace pas une analyse de risque, mais ça rappelle pourquoi la journalisation, l’egress control et la segmentation méritent du temps.

Blueprint hub-and-spoke : adressage, zones, routage inter-spokes, egress contrôlé

Un hub-and-spoke propre commence par un plan IP lisible. Exemple minimal (à adapter) :

• Hub (OPNsense HA) sur vRack :
• 10.0.0.0/24 : LAN-hub (VIP CARP 10.0.0.1)
• 10.0.1.0/24 : SYNC (pfsync/XMLRPC), non routé
• Spoke e-commerce (prod) : 10.10.0.0/22
• Spoke données : 10.20.0.0/24 (MySQL/Redis)
• Spoke admin/outillage : 10.30.0.0/24 (bastion, CI, monitoring)

Deux conseils de design qui évitent des migrations douloureuses :

• Réservez de la place (ex. 10.40.0.0/22, 10.50.0.0/22…) même si vous n’avez pas encore les workloads : c’est moins cher qu’un renumérotage.
• Évitez les plages “trop classiques” si vous devez interconnecter avec des VPN d’entreprise (les collisions 192.168.0.0/16 et 10.0.0.0/24 sont fréquentes).

Chaque spoke a une passerelle vers le VIP du hub (ex. 10.0.0.1) et des routes statiques (ou dynamiques) côté hub vers les subnets spoke. Vous pouvez rester en routes statiques si vous avez peu de spokes et que vous voulez du déterminisme. Si vous dépassez un certain seuil (ex. >10 spokes, multi-régions, liens interconnect), activer un protocole (OSPF/BGP via FRR) devient rationnel, mais c’est une marche de complexité.

La segmentation n’a de valeur que si vous appliquez une politique. Une base efficace pour l’e-commerce :

• DMZ → App : uniquement 80/443 vers reverse-proxy / ingress (HAProxy, Nginx), pas de DB.
• App → Data : 3306 (MySQL) et 6379 (Redis) strictement depuis les workers/web, pas depuis la DMZ.
• Admin → partout : uniquement via VPN + bastion, et journalisé.

Pour rendre ces règles plus actionnables (et auditables), vous pouvez formaliser un “contrat de flux” minimal. Exemple synthétique :

Source	Destination	Ports	Justification	Log recommandé
Internet	DMZ (reverse-proxy)	80/443	Trafic client	Oui (L7 + WAF si dispo)
DMZ	App (PHP-FPM/web)	80/443 (selon archi)	Reverse-proxy vers app	Oui (au moins deny + anomalies)
App	Data (MySQL)	3306	Requêtes DB	Logs sur refus + métriques DB
App	Data (Redis)	6379	Sessions/cache/locks	Logs sur refus + auth/ACL Redis
Admin (VPN)	Bastion	22/3389	Point d’entrée admin	Oui (auth + commandes si possible)
Bastion	Cibles internes	ports nécessaires	Admin contrôlée	Oui (corrélation)

L’idée n’est pas d’avoir 200 lignes dès le jour 1, mais d’éviter le piège “on ouvre large pour que ça marche”.

Pour la partie egress, contrôlez le NAT et les destinations. Dans OPNsense, vous pouvez imposer : DNS sortant uniquement vers vos résolveurs, SMTP sortant interdit (ou via relais), accès API externes whitelistés. Ça évite le “tout sort” après compromission. Côté PrestaShop, ce point est directement lié à la surface d’attaque du backoffice et des modules ; voir aussi Sécurité PrestaShop : protéger API backoffice, WAF et journalisation SIEM.

Deux patterns egress qui fonctionnent bien en e-commerce (sans sur-ingénierie) :

• Egress par zones : la DMZ n’a quasiment aucun egress (sauf OCSP/CRL si vous voulez être strict), l’App a un egress limité aux APIs nécessaires, l’Admin a un egress plus large mais authentifié et tracé.
• DNS contrôlé : si vous forcez le DNS interne (Unbound/dnsmasq) et bloquez le 53/853 sortant, vous réduisez une classe d’exfiltration et vous centralisez la visibilité (requêtes vers domaines suspects).

Spokes e-commerce : placement de HAProxy, isolation MySQL/Redis, et exploitation (monitoring + runbooks)

Le pattern le plus robuste en spoke e-commerce : un ingress L7 dédié (reverse-proxy) plutôt que d’exposer directement vos nœuds applicatifs. Typiquement :

• Spoke DMZ : HAProxy/Nginx (TLS, HSTS, ACL, rate-limit)
• Spoke App : nœuds PrestaShop (PHP-FPM), workers, cron
• Spoke Data : MySQL + Redis (non exposés)

Si vous voulez des exemples concrets de configuration L7 côté Linux, l’article HAProxy 3.2 : déploiement systemd, configuration frontend/backend, ACL donne une base saine (ACL, séparation frontend/backend, pratiques systemd).

Un détail d’architecture qui fait gagner du temps en incident : séparez explicitement ce qui relève :

• du routage/filtrage L3-L4 (hub OPNsense),
• de la politique HTTP/TLS (ingress L7 dans le spoke),
• et des contrôles applicatifs (PrestaShop, règles d’admin, durcissement PHP, permissions FS, etc).

Ça évite de transformer le firewall en “boîte noire” qui porte toutes les responsabilités.

Pour les performances, le hub-and-spoke ne “rend pas PrestaShop plus rapide” par magie, mais il vous permet de poser Redis/MySQL au bon endroit, et de limiter le bruit réseau. Redis, par exemple, doit rester en réseau privé à faible latence ; il ne doit pas transiter sur Internet, et il ne doit pas être accessible hors des nœuds applicatifs. Pour les implications perf/correctness, vous avez des éléments actionnables dans : Performance e-commerce : prévenir la concurrence sur les stocks avec Redis et Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur.

Côté exploitation, le point non négociable en HA, c’est de tester la bascule et d’observer. Trois tests simples (mais rarement faits) :

1. Failover CARP (débrancher l’interface LAN du primaire, vérifier que la VIP bascule, vérifier la continuité des sessions si pfsync est actif).
2. Failover WAN (si vous utilisez Failover IP/Virtual MAC : déplacer l’IP publique, vérifier NAT + retours, vérifier que les ACL ne dépendent pas d’un “interface ID” fixe).
3. Dégradation contrôlée (latence/packet loss sur SYNC, pour vérifier que vous ne déclenchez pas une bascule intempestive).

Pour rendre ces tests réellement utiles, définissez à l’avance des critères “OK/KO” (sinon on valide “à l’œil”). Exemple de critères pratico-pratiques :

• Le VIP LAN répond au ping et les spokes gardent leur passerelle.
• Un panier en cours (session) reste utilisable après bascule (ou, au minimum, l’impact est documenté).
• Les logs montrent clairement “CARP demotion/promotion” et le changement de nœud actif.
• Le temps de retour au nominal est mesuré (même si c’est 30–60 s au début).

Pour cadrer les runbooks de charge et d’observabilité côté boutique (qui vont rapidement mettre en évidence un problème réseau), vous pouvez aussi croiser avec : PrestaShop performance : monitoring, tests de charge et runbooks soldes.

Dans l’observabilité “réseau hub-and-spoke”, quelques signaux ont un excellent ROI car ils détectent des incidents avant la panne franche :

• Changements d’état CARP (flaps, promotions/demotions répétées).
• Perte de paquets / latence sur l’interface SYNC (précurseur de split-brain ou de bascules inutiles).
• Taille de la table d’états (state table) et taux de création de states : utile en cas d’attaque ou de bug applicatif.
• Erreurs d’interface (drops, overruns) sur WAN et vRack.
• Logs de deny sur les règles “sensibles” (Data/DB, Admin) : c’est souvent là que vous voyez un pivot ou un scan interne.

Techniquement, OPNsense expose suffisamment de hooks pour automatiser une partie du runbook. Sur FreeBSD, vous pouvez déclencher des scripts sur événements CARP (promotion/demotion) via rc.syshook.d/carp/ (selon version). C’est le point d’ancrage si vous voulez, par exemple, appeler l’API OVHcloud pour réassigner une Failover IP au nœud devenu master. Ne faites pas ça “à l’arrache” : secrets hors du filesystem (vault), logs minimaux, et surtout un mode dégradé clair (si l’API OVH ne répond pas, vous préférez quoi : rester en MASTER sans IP publique, ou forcer une demotion ?).

Une dernière recommandation de méthode (souvent ce qui différencie “ça marche” de “c’est opéré”) : documentez un runbook de crise en 1 page, avec :

• comment identifier le nœud master (et le confirmer côté IP publique),
• comment forcer une bascule (et comment revenir),
• quelles vérifications applicatives faire (checkout, BO, webhooks),
• et qui est “owner” de chaque couche (réseau, système, applicatif).