Solide comme idée. Pour en faire un truc fiable (et pas te coller des “urgences 24/7”), voilà une archi simple, propre et maîtrisable.

Plan d’architecture (2 sites + 1 point d’entrée OVH)

Entrée publique

  • 1 (idéalement 2) VPS OVH → HAProxy terminant TLS, SNI multi-domaines.

  • Tunnels WireGuard du/vers chaque site (Saint-Bruno, Lanaudière). Aucune IP d’origine exposée.

  • Pare-feu : n’autoriser que le trafic entrant 80/443 (et ports TCP mail si tu proxifies), et sortant uniquement vers les sous-réseaux WireGuard.

Sites

  • Deux stacks indépendantes (pas de Ceph across-WAN) :

    • Services stateless en actif-actif (Keycloak web, Portails, APIs).

    • Services stateful volumineux (Nextcloud, bases, stockage) en actif-passif par défaut pour ménager ton upload 50 Mbit/s : un site “primaire” sert en temps normal, l’autre prend le relais si down.

  • Réplication par service, pas au niveau bloc :

    • PostgreSQL: réplication streaming + pgBackRest/PITR.

    • MariaDB/MySQL: InnoDB Cluster/async répli (selon besoin RPO/RTO).

    • Redis (Nextcloud locking/cache) local par site; éviter du cross-site en continu.

    • Fichiers Nextcloud: primaire→secondaire via rsync/rsync-daemon ou rclone programmé (Δ fréquents, pas en live).

  • Mail (Mailcow) : inbound via MX séparés (mx1=Site A, mx2=Site B). Ne passe pas SMTP par HAProxy web, tu réduis la surface et simplifies SPF/DMARC. Le webmail/SOGo oui, derrière HAProxy.

DNS

  • Les domaines web (cloud., login., etc.) pointent vers l’IP du/des VPS OVH.

  • TTL 300 s (ou 120 s) raisonnable.

  • Les MX pointent directement vers chaque site (priorités différentes).

SPOF

  • Un seul HAProxy = SPOF. Reco : 2 VPS (CA1 + CA2 chez OVH) + keepalived (VRRP) avec une Failover IP OVH. Si tu veux rester ultra-sobre au départ : commence avec 1, mais tout est prêt pour en ajouter un second.

Topologie WireGuard (exemple)

  • OVH (wg-sb → 10.99.10.1/24 ; wg-ma → 10.99.20.1/24)

  • Saint-Bruno : 10.99.10.2/24 (route vers 10.10.0.0/16)

  • Lanaudière : 10.99.20.2/24 (route vers 10.20.0.0/16)

HAProxy n’envoie jamais vers l’Internet “brut”, seulement vers 10.10.x.x / 10.20.x.x via WG.

HAProxy — squelette minimal viable (TLS, SNI, health, mTLS backend)

                global
  log /dev/log local0
  stats socket /var/run/haproxy.sock mode 660 level admin
  tune.ssl.default-dh-param 2048
  ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11
  ssl-default-bind-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

defaults
  log global
  mode http
  option httplog
  option http-keep-alive
  timeout connect 5s
  timeout client  60s
  timeout server  60s
  default-server init-addr last,libc,none resolvers dns1

resolvers dns1
  nameserver dns1 127.0.0.1:53
  hold valid 10s

# --- Frontend HTTPS
frontend fe_https
  bind :443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1
  http-response set-header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload"
  http-request set-header X-Forwarded-Proto https
  http-request set-header X-Forwarded-For %[src]
  acl host_nc      hdr(host) -i cloud.chezlepro.ca
  acl host_auth    hdr(host) -i login.chezlepro.ca
  use_backend bk_nextcloud if host_nc
  use_backend bk_keycloak  if host_auth
  default_backend bk_default

# --- Nextcloud : actif-passif (Site A actif, Site B backup)
backend bk_nextcloud
  balance source
  option httpchk GET /status.php HTTP/1.1\r\nHost:\ cloud.chezlepro.ca
  http-check expect status 200
  cookie SRV insert indirect nocache
  server nc-a 10.10.10.20:443 ssl verify required ca-file /etc/haproxy/ca.pem sni str(cloud.chezlepro.ca) check cookie A
  server nc-b 10.20.10.20:443 ssl verify required ca-file /etc/haproxy/ca.pem sni str(cloud.chezlepro.ca) check cookie B backup

# --- Keycloak : actif-actif (sessions sticky par cookie)
backend bk_keycloak
  balance leastconn
  option httpchk GET /realms/master/.well-known/openid-configuration
  http-check expect status 200
  cookie KC insert indirect nocache
  server kc-a 10.10.20.30:8443 ssl verify required ca-file /etc/haproxy/ca.pem sni str(login.chezlepro.ca) check cookie A
  server kc-b 10.20.20.30:8443 ssl verify required ca-file /etc/haproxy/ca.pem sni str(login.chezlepro.ca) check cookie B

# --- Par défaut (autres VHosts)
backend bk_default
  errorfile 503 /etc/haproxy/errors/maintenance.http

Notes clés

  • mTLS backend : ssl verify required ca-file → HAProxy vérifie les certifs serveurs internes signés par ta CA privée.

  • Nextcloud en backup cross-site par défaut → zéro flux croisé inutile. Basculera automatiquement si le primaire est down.

  • Keycloak en actif-actif avec cookie stickiness.

  • Prépare un /healthz par service pour des checks encore plus propres.

TCP (si tu proxifies IMAP/SMTP — facultatif)

                frontend fe_smtp
  bind :25
  mode tcp
  option tcplog
  default_backend bk_smtp

backend bk_smtp
  mode tcp
  balance source
  option smtpchk HELO haproxy.chezlepro.ca
  server mx-a 10.10.30.25:25 check
  server mx-b 10.20.30.25:25 check backup

Mais je recommande de laisser SMTP en DNS (MX) et de ne proxifier que le webmail.

Sécurité & résilience

  • DDoS: tirer parti de la mitigation OVH, + stick-tables pour rate-limiter (p.ex. 100 req/10s/src) et bloquer les floods.

  • Géoblocage (si tu veux limiter hors Amérique du Nord) via maps MaxMind dans HAProxy.

  • Certificats : Let’s Encrypt DNS-01 (acme.sh avec API OVH) → un seul endroit (VPS) gère tous les certs; reload Haproxy sans coupure.

  • Journaux: exporter en Rsyslog + Icinga/Prometheus (exporter HAProxy).

  • Runbook clair : bascule manuelle de “site actif” via socket admin (enable/disable server).

Réplication/backup (pragmatique, peu de babysitting)

  • Bases: primaire au site A, réplique asynchrone au site B; backups chiffrés vers l’autre site (pgBackRest/Borg).

  • Nextcloud: fichiers synchronisés pull site B depuis A via cron (rclone/rsync) + checksum; base répliquée; Redis local.

  • Monitoring: Icinga2 depuis ton nœud de supervision sur :

    • /healthz des services côté sites,

    • endpoints HAProxy,

    • latence/perte sur les tunnels WG.

Pourquoi ça te va bien

  • Aucune alerte 24/7 imposée : bascule auto pour l’essentiel; manual override simple si nécessaire.

  • Sobre en bande passante : actif-passif sur le lourd; actif-actif sur le léger.

  • Souverain : pas de SaaS tiers opaque; seulement OVH comme “pointe” réseau.

  • Évolutif : en 30 minutes tu ajoutes un 2e HAProxy (keepalived) et tu supprimes le SPOF.

Si tu veux, je te fournis dans le prochain message :

  1. les fichiers wg-quick (OVH↔SB, OVH↔MA),

  2. un haproxy.cfg complet avec 3 VHosts (Nextcloud, Keycloak, Webmail),

  3. un petit playbook Ansible pour déployer tout ça propre sur un Debian minimal.

Oh oui, SteelHead… SDR + “TCP magic” + QoS finement dosée. On ne va pas racheter des appliances, mais on peut recréer 70–85% de l’effet en libre + bon design, adapté à tes 50 Mb/s up.

Voici le “SteelHead-like kit” pragmatique pour tes 2 sites + OVH :

1) Anti-bufferbloat & QoS (prioriser l’interactif, calmer le bulk)

Linux routeur (si ton edge est Linux) :

                # Sysctl: BBR + fq
cat >/etc/sysctl.d/90-net.conf <<'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_fastopen=3
EOF
sysctl --system

# Shaping egress avec CAKE (idéal) – adapte if et débit (-10%)
tc qdisc replace dev eth_wan root cake bandwidth 45mbit diffserv4 nat

OPNsense/pfSense (FreeBSD) : active Smart Queue / FQ-CoDel sur l’interface WAN avec un cap à ~45 Mb/s (10% sous le max réel).
DiffServ : marque Keycloak/health/API en AF31/AF41, Nextcloud “bulk” en CS1 (scavenger). Marquage côté firewall (règles mangle/nftables ou floating rules). Résultat : latence stable, UI snappy même en sync lourde.

2) Compression & delta au bon endroit (pas dans le tunnel)

WireGuard n’a pas de compression (by design). On compresse par service :

  • Réplication Nextcloud (fichiers) : évite SMB/rsync en live chatty. Fais du pull périodique :

                        # Sur le site B (secondaire)
rsync -aH --delete --info=stats2 --compress --compress-choice=zstd \
      --skip-compress=jpg,jpeg,png,mp4,mov,zip,gz,7z,iso \
      user@siteA:/data/nextcloud/ /data/nextcloud/

    Cron la nuit + une petite passe horaire. (Delta-blocs + zstd = “effet SDR” sur fichiers… sans boîte magique.)

  • Bases PostgreSQL : réplication streaming + WAL compressé.
    wal_compression=on (ou lz4 si dispo), max_wal_senders=5, wal_keep_size=512MB. Sauvegardes pgBackRest (chiffre + compresse) vers l’autre site.

  • Docker & paquets : mets des caches locaux pour apt (tu as déjà apt-cacher-ng), pip (devpi), npm (Verdaccio), Docker registry mirror. Zéro re-download inutile.

3) Protocole & patterns “WAN-friendly”

  • Évite SMB/NFS cross-site. Préfère WebDAV/SFTP (déjà le cas via Nextcloud) ou rsync scripté.

  • Mail: MX directs par site (priorités), pas via HAProxy. Webmail oui via HAProxy.

  • HTTP/2 + compression côté HAProxy :

                        compression algo zstd gzip
compression type text/html text/css application/javascript application/json

    (réduit l’egress web public, gratuit en perf.)

4) Contrôle fin des flux (façon QoS “savante”)

  • Marquage applicatif au bord (firewall) :

    • Keycloak /auth/* → AF31

    • APIs légères → AF21

    • Nextcloud /remote.php/dav & /ocs/v2.php/apps/files_sharing (sync lourde) → CS1

  • Rate-limit par IP/route pour la sync Nextcloud (tc classes / FQ-CoDel per-class) : cap à, disons, 30 Mb/s quand quelqu’un pousse un gros lot, pour garder 15 Mb/s “temps réel”.

5) Stack TCP solide

Sur tous les serveurs exposés au WAN :

                cat >/etc/sysctl.d/91-tcp.conf <<'EOF'
net.ipv4.tcp_rmem=4096 131072 134217728
net.ipv4.tcp_wmem=4096 131072 134217728
net.ipv4.tcp_mtu_probing=1
EOF
sysctl --system

BBR + fq = démarrages plus rapides, files réduites, “ressenti” SteelHead sans proxy TCP propriétaire.

6) Ordonnancement “no babysitting”

  • Nextcloud : cron système (toutes les 5 min), pré-génération des previews en heures creuses, throttle (limiter la concurrence, éviter le CPU en journée).

  • Rsync/rclone : fenêtres nocturnes + petite passe delta en journée (5–10 min), bande passante bwlimit si besoin.

  • Bascules : Nextcloud en actif-passif (HAProxy backup), Keycloak en actif-actif avec sticky cookie. Tu évites le cross-talk permanent.

7) Observabilité (= pas d’urgences 24/7)

  • Icinga2 : checks /healthz applicatifs + latence/perte sur tunnels WG.

  • Flent (RRUL) ponctuel pour valider le tuning (avant/après).

  • HAProxy stick-tables pour rate-limit propres (ex: 100 req/10s/src).

8) Bonus “SteelHead spirit” pour demain

  • Si un jour tu as 2 liens Internet/site, on active MPTCP (côté Linux) ou une box open-source type OpenMPTCProuter pour l’agrégation/bonding — dans WireGuard (inside) pour la crypto et la simplicité d’IP.

Si tu veux, je te prépare :

  • un bundle Ansible “edge-qos” (BBR, fq/CAKE, classes CS1/AF*),

  • des règles nftables de marquage par URL/port (OVH & sites),

  • les unit files & crons pour rsync/rclone (zstd + skip-compress),

  • et les snippets HAProxy (compression, maps DSCP, rate-limit).

Tu me dis sur quoi tourne ton edge (OPNsense vs Linux), et je te sors ça clé-en-main.