aller au contenu
FRFlo
Table des matières

Gérer sa propre infrastructure en auto-hébergement (self-hosting) implique souvent un compromis difficile entre commodité, autonomie et sécurité. Dans le modèle traditionnel, multiplier les services implique d’ouvrir des dizaines de ports publics, de configurer un reverse proxy exposé aux attaques, et de sécuriser manuellement chaque brique.

Mon infrastructure de production adopte une approche radicalement différente : une stack complète de plus de 20 conteneurs Docker (développement, productivité, IA, gaming, bases de données) pilotée par une architecture Zero Trust.

Le principe fondamental ? Aucun socket applicatif n’écoute sur une interface publique. Les flux entrants transitent par des tunnels QUIC sortants, les accès sont conditionnés par une fédération d’identité multi-IdP, et l’administration des services internes (bases de données, serveurs MCP) se fait via un réseau privé maillé sous protocole MASQUE.

Voici le deep dive technique complet de cette stack VPS et de sa couche de sécurité.

Vue d’ensemble de l’infrastructure

L’ensemble de la stack tourne sur un serveur dédié Linux (Debian 12) hébergé chez OVH.

flowchart TB
    subgraph Clients["Clients & Postes d'Administration"]
        Browser["Navigateur / Client Web"]
        AdminDev["Poste Admin (Client WARP)"]
        DiscordClient["Discord (Bots & Agents)"]
    end

    subgraph Edge["Cloudflare Edge & Zero Trust"]
        Access["Cloudflare Access (IAP / IdP)"]
        Gateway["Cloudflare Gateway (Filtrage L4/L7/DNS)"]
        VNet["Virtual Network (Teamnet Mesh)"]
        CFMail["smtp.mx.cloudflare.net:465"]
    end

    subgraph Host["Serveur Dédié OVH (Debian 12)"]
        subgraph Daemons["Démons Système"]
            CFTunnel["cloudflared (Tunnel Ingress QUIC)"]
            WARPConn["WARP Connector (Tunnel Mesh MASQUE)"]
        end

        subgraph DockerEngine["Docker Engine (Monorepo vps)"]
            subgraph NetApp["Bridge: applications"]
                AppWeb["Services Web Frontaux<br>Dockhand, Pocket ID, Gitea<br>Kaneo, Agents IA, Beszel Hub"]
            end

            subgraph NetRes["Bridge: resources"]
                DBs["Bases de données<br>PostgreSQL, Redis, MariaDB, MongoDB"]
                InternalServ["Services Internes<br>Postfix SMTP Relay, Serveurs MCP"]
            end

            subgraph NetWings["Bridge: wings"]
                WingsDaemon["Pelican Wings Daemon"]
                GameContainers["Serveurs de jeux isolés"]
            end
        end
    end

    Browser -->|HTTPS et HTTP3| Access
    Access -->|Tunnel QUIC sortant UDP 7844| CFTunnel
    CFTunnel -->|Loopback 127.0.0.1| NetApp

    AdminDev -->|Tunnel MASQUE| Gateway
    Gateway --> VNet
    VNet -->|Routage Prive| WARPConn
    WARPConn -->|Netfilter conntrack| NetRes
    WARPConn -->|Netfilter conntrack| NetApp

    InternalServ -->|TLS Wrappermode port 465| CFMail

1. Orchestration & Gestion de la Stack : Dockhand

La gestion d’une vingtaine de conteneurs avec leurs volumes, secrets et variables d’environnement peut vite devenir ingérable en ligne de commande pure.

Pour centraliser cette administration sans jamais exposer le socket Docker (/var/run/docker.sock) sur le web, la stack est orchestrée par Dockhand, une solution d’administration Docker moderne et réactive.

flowchart LR
    subgraph HostEnv["Environnement Serveur"]
        Socket["/var/run/docker.sock"]
        Compose["docker-compose.yml (Monorepo vps)"]
        EnvFiles[".env (Variables chiffrées)"]
    end

    subgraph DockhandUI["Dockhand Engine"]
        UI["Interface Web d'administration"]
        Metrics["Collecte métriques & Activity"]
        AutoPrune["Image Prune & Auto-Updates"]
    end

    UI --> Socket
    UI --> Compose
    UI --> EnvFiles

Fonctionnalités clés de l’orchestration :

  • Stack unique déclarative (vps) : Tous les services, réseaux et volumes sont décrits dans un fichier Docker Compose structuré et versionné.
  • Déploiement GitOps via webhook Dockhand : Un workflow GitHub Actions déclenche automatiquement le webhook de déploiement de Dockhand à chaque commit validé sur le dépôt d’infrastructure, garantissant l’alignement continu de la stack sans requérir d’accès SSH direct.
  • Healthchecks systématiques : Chaque service critique (PostgreSQL, MariaDB, MongoDB, Redis, Gitea, Kaneo, Pelican, ownCloud, ocis-qdrant-indexer, etc.) intègre des sondes de santé (CMD-SHELL, pg_isready, mongosh ping, probe HTTP /health couplée à la disponibilité vectorielle) assurant un ordonnancement de démarrage parfait via les conditions depends_on: service_healthy.
  • Politique de mise à jour automatisée : Suivi des digests d’images (latest, lts) et nettoyage automatique des images orphelines (image pruning).
  • Isolation de l’agent : Dockhand s’exécute lui-même dans un conteneur dédié, avec son propre volume persistant.

2. Le Catalogue Applicatif : Panorama des Services

La stack répond à plusieurs besoins quotidiens : développement, gestion d’identité, productivité, écosystème IA, gaming et multimédia.

A. Identité, Authentification & Sécurité

  • Pocket ID : Fournisseur d’identité OIDC moderne et ultra-léger développé en Go/Svelte. Il prend en charge nativement les Passkeys (FIDO2 / WebAuthn) pour une connexion biométrique sécurisée sans mot de passe.
  • phpMyAdmin : Console d’administration web pour les bases de données MariaDB.

B. Développement, GitOps & CI/CD

  • Gitea : Forge logicielle Git auto-hébergée, adossée à PostgreSQL pour la persistance des données et Postfix pour les e-mails de notification.
  • Gitea Mirror : Service automatisé qui synchronise en continu les dépôts GitHub distants vers mon instance Gitea locale pour garantir des sauvegardes autonomes et pérennes.
  • act-runner : Runner CI/CD natif pour exécuter des workflows GitHub Actions directement sur le VPS sans dépendance envers l’infrastructure externe.

C. Productivité & Outils Métier

  • Kaneo : Application moderne de gestion de projets et ticketing (alternative fluide à Linear/Jira), directement intégrée à Pocket ID en SSO OAuth/OIDC avec flux PKCE.
  • ownCloud Infinite Scale (oCIS) : Plateforme collaborative moderne de stockage et de synchronisation de fichiers. Connectée en SSO OIDC natif à Pocket ID (avec mapping personnalisé des claims et rôles), elle supporte les jetons d’application via l’extension ocis-app-tokens, intègre des extensions web dédiées (mdpresentation-viewer pour la visualisation de présentations Markdown et unzip pour l’extraction d’archives) et s’appuie sur un extracteur Apache Tika pour l’analyse de documents. Sa Content Security Policy (csp.yaml) est durcie pour autoriser explicitement les origines d’assertion Cloudflare Access et l’IdP Pocket ID (frame-src, connect-src), garantissant la fluidité des flux OIDC et des intégrations iframe.
  • BentoPDF : Suite complète d’outils de manipulation et traitement de fichiers PDF.

D. Écosystème IA, Agents & MCP

  • Executor : Runtime d’exécution de code sécurisé et serveur MCP (Model Context Protocol), exposant des endpoints sécurisés pour l’exécution d’outils d’IA.
  • Hermes Agent : Agent IA autonome (basé sur NousResearch Hermes) opérant comme un bot Discord d’administration et d’interaction, connecté à la passerelle CLI Proxy API.
  • Pi Bridge : Passerelle de communication et d’exécution pour l’agent pi, synchronisé avec Discord.
  • CLI Proxy API : Proxy d’API unifiant les requêtes vers les modèles d’IA avec authentification par Service Token, gestion distante d’administration et collecte d’historique de consommation.
  • Qdrant & Apache Tika : Infrastructure vectorielle et d’analyse documentaire dédiée aux workflows RAG (Retrieval-Augmented Generation).
  • ocis-qdrant-indexer : Sidecar RAG temps réel multi-utilisateur rattaché au bus d’événements NATS d’ownCloud Infinite Scale (nats://owncloud:9233). Il assure une isolation stricte des accès par utilisateur (collections vectorielles Qdrant partitionnées par hash d’identifiant et filtrage par espace autorisé), un stockage chiffré des jetons d’accès (PATs) en base SQLite locale (users.sqlite sur volume persistant dédié), l’extraction multimodale Tika/PaddleOCR, et expose un endpoint MCP Streamable HTTP avec authentification HTTP Basic native.
  • ocis-mcp-server : Serveur MCP officiel ownCloud Infinite Scale (ghcr.io/frflo/ocis-mcp-server:latest) déployé dans la stack Docker. Il expose plus de 80 outils dédiés (navigation de fichiers, gestion des partages, métadonnées, espaces de travail) pour les agents IA et Executor, avec autorisation HTTP interne (OCIS_MCP_INSECURE=true).
  • PaddleOCR CPU : Moteur de reconnaissance optique de caractères haute performance (ghcr.io/frflo/ocis-paddleocr:latest) déployé sur le réseau interne resources (port d’écoute interne 8868, délai étendu à 15 minutes). Il intervient en synergie avec Apache Tika pour l’extraction de texte sur les documents numérisés et images.
  • Google Chrome persistant : Navigateur Chrome conteneurisé (chrome) offrant à la fois une interface graphique interactive noVNC sécurisée par Cloudflare Access et un proxy DevTools Protocol (CDP sur le port interne 9222) pour l’automatisation avancée et les agents IA.
  • GTFS MCP : Serveur MCP privé fournissant des outils d’analyse et de requêtage sur les flux de transports en commun (Ilévia, SNCF, IDFM).
  • Open-Meteo MCP : Serveur MCP interne exposant les prévisions météorologiques et données historiques pour Executor.
  • Google Maps MCP : Serveur MCP interne fournissant géocodage, lieux, itinéraires, trafic et fuseaux horaires à Executor.
  • Moodle MCP : Serveur MCP interne assurant l’interconnexion avec une plateforme d’apprentissage.

E. Gaming & Virtualisation de Jeux

  • Pelican Panel : Panel de gestion de serveurs de jeux nouvelle génération (successeur moderne de Pterodactyl), connecté à PostgreSQL et Postfix.
  • Pelican Wings : Démon de contrôle gérant le cycle de vie des conteneurs de jeux (Minecraft Bedrock, serveurs SteamCMD) sur un réseau bridge dédié.

F. Multimédia & Utilitaires

  • Cobalt : Instance privée de téléchargement et traitement de contenus multimédias, respectueuse de la vie privée.
  • VERT : Moteur de conversion vidéo haute performance accéléré par CPU.
  • Your Spotify : Dashboard analytique complet traquant les écoutes et statistiques Spotify personnelles, couplé à une base MongoDB.

G. Observabilité, Sauvegardes & Monitoring

  • Beszel : Hub central de monitoring système pour le suivi en temps réel du CPU, de la RAM, de l’I/O disque et de l’état des conteneurs (connexion par mot de passe désactivée, sécurisation déléguée à Cloudflare Access).
  • Beszel Agent : Agent léger déployé avec montage en lecture seule du socket Docker (/var/run/docker.sock:ro) pour collecter les métriques matérielles en continu.
  • Arkeep : Solution de sauvegarde continue des volumes Docker et des configurations (arkeep-server et arkeep-agent), adossée à une base MariaDB dédiée.
  • CPA Manager Plus : Console d’administration et tableau de bord d’observabilité dédié à la passerelle d’IA cli-proxy-api. Déployé sur le port local 8018 avec stockage persistant SQLite (/data/usage.sqlite), il centralise la métrologie des tokens consommés, les temps de réponse et les quotas par modèle sans perturber le trafic d’inférence en production.
  • Sondes de santé conteneurisées (Healthchecks) : Les sondes de santé des conteneurs (notamment phpMyAdmin) privilégient des vérifications de sockets réseau TCP directs et non-bloquants (fsockopen) plutôt que des wrappers HTTP de haut niveau, prévenant les faux positifs d’instabilité lors des redirections locales.

3. Ingress Layer 7 : Cloudflare Tunnel & QUIC

Pour rendre ces applications accessibles depuis le web sans ouvrir aucun port HTTP/HTTPS sur le pare-feu du serveur, le flux Ingress repose sur Cloudflare Tunnel (cloudflared).

sequenceDiagram
    participant Edge as Cloudflare Edge (PoPs)
    participant Cloudflared as Démon cloudflared (Serveur)
    participant LocalApp as Application Docker (127.0.0.1:local_port)

    Note over Cloudflared,Edge: Démarrage : 4 tunnels QUIC sortants vers l'Edge
    Cloudflared->>Edge: Connexion sortante persistante (UDP/7844)
    Edge-->>Cloudflared: Tunnels actifs établis

    Note over Edge: Requête utilisateur vers un service
    Edge->>Cloudflared: Multiplexage de la requête dans le flux QUIC
    Cloudflared->>LocalApp: Proxy HTTP local sur 127.0.0.1
    LocalApp-->>Cloudflared: Réponse HTTP 200 OK
    Cloudflared-->>Edge: Retour du paquet dans le stream QUIC

Mécanisme d’Ingress sécurisé

Chaque conteneur web est lié exclusivement sur la boucle locale 127.0.0.1 sur un port dédié non exposé au réseau externe :

# Exemple de configuration Ingress cloudflared
ingress:
  - hostname: ssh
    service: ssh://ssh
  - hostname: docker
    service: http://docker
  - hostname: pocket-id
    service: http://pocket-id
  - hostname: beszel
    service: http://beszel
  - hostname: pelican
    service: http://pelican
  - hostname: vert
    service: http://vert
  - hostname: pdf
    service: http://pdf
  - hostname: media
    service: http://media
  - hostname: gitea
    service: http://gitea
  - hostname: gitea-mirror
    service: http://gitea-mirror
  - hostname: phpmyadmin
    service: http://phpmyadmin
  - hostname: cli-proxy-api
    service: http://cli-proxy-api
  - hostname: owncloud
    service: http://owncloud
  - hostname: kaneo
    service: http://kaneo
  - hostname: wings
    service: http://wings
  - hostname: executor
    service: http://executor
  - hostname: spotify
    service: http://spotify
  - hostname: spotify-api
    service: http://spotify-api
  - hostname: hermes
    service: http://hermes
  - hostname: pi-bridge
    service: http://pi-bridge
  - hostname: cpa
    service: http://cpa-manager-plus
  - hostname: arkeep
    service: http://arkeep
  - hostname: chrome
    service: http://chrome
  - service: http_status:404

Grâce à cette approche :

  • Absence de port public d’écoute : netstat ou ss ne montrent aucune écoute sur 0.0.0.0:80 ou 0.0.0.0:443.
  • DDoS Shield natif : Le trafic passe d’abord par le réseau Anycast mondial de Cloudflare avant d’être injecté dans le tunnel QUIC sortant.
  • Isolation stricte des services d’infrastructure : Les briques internes (bases de données PostgreSQL/Redis/MongoDB/MariaDB, bus NATS oCIS, moteur vectoriel Qdrant, extracteur Tika ou relais Postfix) n’ont aucune règle d’ingress publique. Elles ne sont joignables que sur les bridges Docker internes ou via le maillage sécurisé MASQUE.
  • Ségrégation stricte de l’observabilité IA : L’endpoint d’inférence en production, dont dépendent les inférences des agents autonomes, reste dédié exclusivement aux flux d’exécution. Le panneau de contrôle et de métriques est entièrement découplé sur son propre sous-domaine dédié vers le port local 8018, éliminant tout risque d’interférence ou de surcharge sur l’API d’inférence.

4. Authentification & IAP : Identity Broker multi-IdP

L’exposition des applications est verrouillée par Cloudflare Access (Identity Aware Proxy).

sequenceDiagram
    participant Client as Navigateur Web
    participant Access as Cloudflare Access (IAP)
    participant OIDCProvider as Fournisseur OIDC
    participant Service as Application Web

    Client->>Access: Requête vers l'application
    Access->>Client: Redirection vers l'IdP Broker
    Client->>OIDCProvider: Authentification
    OIDCProvider-->>Access: Assertion OIDC signée
    Note over Access: Évaluation politiques + Signature JWT RS256
    Access->>Client: Cookie de session chiffré
    Access->>Service: Requête avec Header Cf-Access-Jwt-Assertion
    Service-->>Client: Réponse 200 OK

Fédération multi-fournisseurs (IdPs) :

  1. Pocket ID : IdP principal auto-hébergé avec clés de sécurité FIDO2 et WebAuthn.
  2. Discord OIDC : IdP pour les applications liées aux agents communautaires.
  3. GitHub & Google OAuth : Fournisseurs secondaires pour secours et administration.

Règles d’accès et Service Tokens :

  • Politique Admin (allow) : Accès complet pour l’administrateur authentifié.
  • Posture Appareil WARP (non_identity) : Accès direct transparent pour les machines enrolées avec le client WARP et certificat actif.
  • Service Tokens M2M : Authentification machine-to-machine via headers CF-Access-Client-Id et CF-Access-Client-Secret pour les scripts et automatisations.
  • Règles de Bypass ciblées : Accès public sélectif pour les points d’entrée nécessaires aux intégrations externes (ex: métadonnées OAuth d’un serveur MCP).
  • Bypass granulaire par sous-chemin (Public Path Bypass) : Pour les services nécessitant une exposition publique partielle (comme le partage de fichiers sur ownCloud Infinite Scale), une application Access secondaire est dédiée aux routes de partage (/s/*, /dav/public-files/*) avec une politique bypass (everyone: {}). Les visiteurs externes accèdent directement aux téléchargements sans authentification préalable, tandis que la racine et les consoles privées restent hermétiquement verrouillées par Zero Trust.
  • Filtrage multicouche pour les consoles sensibles : Sur des services d’observabilité d’administration comme CPA Manager Plus, les politiques Cloudflare Access combinent l’autorisation nominative du groupe Admin (allow), le contrôle de posture d’appareil WARP (non_identity), et des exceptions d’IP de confiance pour une protection hermétique en profondeur.
  • SSH sans port 22 ouvert : La connexion SSH utilise le hostname du service ssh, ce qui encapsule le protocole SSH dans un flux HTTPS authentifié par Access.

5. Layer 4 Mesh : WARP Connector & Protocole MASQUE

Pour administrer directement les bases de données (PostgreSQL, MariaDB, Redis, MongoDB) ou les serveurs MCP depuis un poste local avec des outils bureautiques (DBeaver, TablePlus, VS Code), le serveur exécute un WARP Connector rattaché au réseau virtuel Cloudflare (Teamnet).

flowchart LR
    subgraph DevMachine["Poste Développeur (Client WARP)"]
        DBeaver["DBeaver / TablePlus (SQL)"]
        MongoCompass["MongoDB Compass"]
        MCPClient["Client MCP / VS Code"]
    end

    subgraph CFMesh["Cloudflare Virtual Network"]
        VNet["Réseau Virtuel Privé"]
        CGNAT["Plage CGNAT : 100.64.0.0/10"]
    end

    subgraph VPS["Serveur Dédié (WARP Connector)"]
        WARPInt["Interface CloudflareWARP (MASQUE)"]
        Netfilter["Netfilter / conntrack"]

        subgraph Subnets["Sous-réseaux Docker Annoncés"]
            SubRes["Réseau resources (Bases de données)"]
            SubApp["Réseau applications (Outils & MCP)"]
            SubWings["Réseau wings (Gaming)"]
        end
    end

    DBeaver -->|TCP SQL| WARPInt
    MongoCompass -->|TCP NoSQL| WARPInt
    MCPClient -->|HTTP MCP| WARPInt
    WARPInt --> Netfilter
    Netfilter --> SubRes
    Netfilter --> SubApp

Le protocole MASQUE (RFC 9298 / RFC 9484)

Le tunnel utilise le protocole MASQUE (Multiplexed Application Substrate over QUIC Encryption), qui encapsule les paquets IP (TCP/UDP) dans des flux HTTP/3 sur QUIC.

Par rapport à un VPN WireGuard traditionnel :

  • Le trafic traverse n’importe quel pare-feu d’entreprise sans être bloqué (apparence de trafic HTTPS standard sur le port 443).
  • Le multiplexage QUIC élimine les blocages de tête de ligne pour les flux d’administration simultanés.

Split Tunneling (Mode Include) :

Côté client, le trafic routé dans le tunnel est strictement limité aux ressources nécessaires :

  • Sous-réseaux Docker privés du serveur
  • Espace CGNAT WARP : 100.64.0.0/10 (RFC 6598)
  • Noms de domaine de production spécifiques

Exposition des bases de données et services internes sur le Mesh WARP

Pour concilier l’accès d’administration directe et l’absence totale d’exposition publique, les services internes et bases de données sont liés exclusivement à l’adresse IP de l’interface Cloudflare WARP (${CLOUDFLARE_MESH_IP}), interdisant toute écoute sur 0.0.0.0 ou exposition via le tunnel Cloudflare Ingress L7.

Ce cloisonnement s’articule autour de deux plages cohérentes :

  • Bases de données sur leurs ports standards : PostgreSQL, MariaDB, Redis, et MongoDB, permettant aux clients SQL/NoSQL (DBeaver, TablePlus, Compass) de se connecter nativement via le mesh MASQUE sans translation de port exotique.
  • Services internes et serveurs MCP sur les ports 90xx :
    • Chrome DevTools / noVNC
    • Arkeep Server (gRPC)
    • Gitea (SSH)
    • Pocket ID (interface interne)
    • Wings (démon Pelican)
    • Serveurs MCP spécialisés (google-maps-mcp, gtfs-mcp, moodle-mcp, open-meteo-mcp)
    • ocis-qdrant-indexer (Streamable HTTP)
    • paddleocr (service d’OCR)
    • Postfix (relais SMTP)
    • Apache Tika (extraction documentaire)
    • Qdrant (endpoints REST et gRPC)

6. Micro-segmentation Docker : 3 Réseaux Bridge Isolés

Pour limiter drastiquement le rayon d’impact (blast radius) en cas de faille applicative, les conteneurs sont cloisonnés en 3 réseaux virtuels indépendants :

flowchart TD
    subgraph NetApp["Bridge: applications"]
        A1["Dockhand"]
        A2["Pocket ID"]
        A3["Gitea"]
        A4["Kaneo"]
        A5["Executor MCP"]
    end

    subgraph NetRes["Bridge: resources"]
        R1[("PostgreSQL")]
        R2[("Redis")]
        R3[("MariaDB")]
        R4[("MongoDB")]
        R5["Postfix SMTP Relay"]
    end

    subgraph NetWings["Bridge: wings"]
        W1["Pelican Wings Daemon"]
        W2["Serveurs de jeux dédiés"]
    end

    A3 -->|Requetes SQL| R1
    A4 -->|Requetes SQL| R1
    A2 -->|Requetes SQL| R1
    A3 -->|Envoi SMTP| R5
    A2 -->|Envoi SMTP| R5
    W1 -->|Stockage SQL| R3
  1. applications : Regroupe les frontaux web. Ces conteneurs ne peuvent pas communiquer avec le réseau resources sauf s’ils y sont explicitement rattachés.
  2. resources : Héberge les bases de données et outils internes. Aucun port n’est exposé sur l’extérieur ; les connexions proviennent uniquement des applications autorisées ou du tunnel WARP.
  3. wings : Dédié aux instances de serveurs de jeux instanciées par Pelican Wings, totalement étanches par rapport aux bases de données principales et aux outils de production.

7. Egress SMTP Sécurisé via Cloudflare Email Routing

L’envoi des e-mails transactionnels (confirmations de compte, notifications, alertes système) évite les relais SMTP publics ou non chiffrés :

sequenceDiagram
    participant App as Service (Gitea / Pocket ID)
    participant Postfix as Conteneur Postfix Relay (Interne)
    participant CFMail as Cloudflare Email (smtp.mx.cloudflare.net:465)
    participant Recipient as Destinataire final

    App->>Postfix: SMTP non chiffré interne (port 25)
    Note over Postfix: Chiffrement TLS + Auth SASL (API Token)
    Postfix->>CFMail: Connexion TLS Wrappermode (port 465)
    CFMail-->>Recipient: Distribution avec signatures SPF / DKIM / DMARC

Le conteneur postfix agit comme relais interne sur le réseau resources et transfère tous les flux sortants vers [smtp.mx.cloudflare.net]:465 en mode TLS implicite avec un Token API Cloudflare dédié.

# Extrait du service Postfix dans docker-compose.yml
postfix:
  container_name: postfix
  image: mwader/postfix-relay:latest
  networks:
    - resources
  environment:
    - POSTFIX_mynetworks=10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 100.64.0.0/10
    - POSTFIX_relayhost=[smtp.mx.cloudflare.net]:465
    - POSTFIX_smtp_tls_security_level=encrypt
    - POSTFIX_smtp_tls_wrappermode=yes
    - POSTFIX_smtp_sasl_auth_enable=yes
    - POSTFIX_smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd
    - POSTMAP_sasl_passwd=[smtp.mx.cloudflare.net]:465 api_token:${CF_SMTP_API_TOKEN}

8. Interaction Linux Kernel : Netfilter, Conntrack et Routage

Pour orchestrer le routage entre l’interface réseau virtuelle du WARP Connector (CloudflareWARP) et les ponts Docker internes, le noyau Linux exploite la table de suivi des connexions (nf_conntrack) avec le routage IPv4 activé :

Terminal window
# Activation du transfert de paquets au niveau du noyau
sysctl -w net.ipv4.ip_forward=1


# Autorisation du flux entrant depuis l'interface WARP vers les sous-réseaux Docker
iptables -I FORWARD 1 -i CloudflareWARP -d 172.18.0.0/16 -j ACCEPT


# Autorisation du trafic retour via la machine à états conntrack
iptables -I FORWARD 2 -o CloudflareWARP -s 172.18.0.0/16 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Lorsqu’un administrateur interroge une base de données interne via DBeaver sur le tunnel WARP :

  1. Le paquet TCP SYN pénètre par l’interface CloudflareWARP.
  2. Le module nf_conntrack enregistre le nouveau flux dans sa table d’états.
  3. Le paquet est transféré directement vers le bridge Docker correspondant.
  4. La réponse TCP SYN-ACK émise par le service est automatiquement autorisée par la règle RELATED,ESTABLISHED sans nécessiter d’ouverture de port public.

9. Filtrage Gateway : Protection DNS, HTTP et L4

En amont du serveur, l’ensemble du trafic bénéficie des règles d’inspection et de sécurité Cloudflare Gateway :

Filtre Règle appliquée Action Effet
DNS Anti-Malware Block Neutralise la résolution des domaines malveillants
DNS Anti-Phishing Block Bloque les tentatives d’hameçonnage
DNS Whitelist / Domaines de confiance Allow Priorité DNSSEC et exemptions de confiance
HTTP Inspection des menaces Block Détection et blocage des URLs compromises
L4 / Network Filtrage réseau Malwares & Phishing Block Drop immédiat au niveau paquet sur les FQDNs ciblés

Conclusion

Cette infrastructure prouve qu’il est tout à fait possible d’exploiter une stack auto-hébergée riche, moderne et productive sans faire de compromis sur la sécurité :

  • Productivité maximale : Plus de 20 services conteneurisés couvrant l’ensemble des besoins (Dev, IA, Projets, Médias, Gaming), orchestrés de manière fluide avec Dockhand.
  • Surface d’attaque publique nulle : Aucun port web ou SSH n’est ouvert sur Internet. Les scans automatisés ne voient qu’un hôte muet.
  • Identité continue : Chaque interaction est validée par Pocket ID (Passkeys) et Cloudflare Access avec signature cryptographique JWT.
  • Administration transparente : L’accès direct aux bases de données et services internes s’effectue via le protocole MASQUE sans configuration de VPN complexe ni exposition de bastions.

Une architecture robuste, moderne, et pensée pour durer.