What is a Cloudflare Tunnel and why would I use it on my ZimaCube 2?

A Cloudflare Tunnel creates an outbound-only encrypted connection from your ZimaCube 2 to Cloudflare edge network. Instead of opening ports on your router (which exposes your infrastructure to the internet), all traffic flows through this encrypted tunnel. Your origin server — the ZimaCube 2 — remains completely hidden from public view.

Do I need to open any ports on my router for this setup?

No. That is the point. Cloudflare Tunnel only makes outbound connections. Your router does not need a single port forward rule. This eliminates the most common attack vector in [homelab networking](https://shop.zimaspace.com/blogs/zima-campaign-hub/ultimate-homelab-hardware-guide-self-hosting "Building a Homelab: Top Hardware Picks for Beginners to Pros").

Can the ZimaCube 2 handle running a reverse proxy and all my services at the same time?

Yes. Michael ZC2 runs Cloudflare Tunnel, Nginx Proxy Manager, and 10+ Docker containers simultaneously — all while maintaining quiet, cool operation. The dual 2.5GbE ports and NVMe storage ensure networking and container I/O do not become bottlenecks.

Why does Docker network segmentation matter?

If every container shares the same network, one compromised service gives an attacker a path to everything else. By placing only Cloudflare Tunnel and Nginx Proxy Manager on an "edge" network (and keeping applications on separate internal networks), you create a controlled boundary between public-facing traffic and your private services.

What was the TLS hostname mismatch issue?

When Cloudflare Tunnel connected to Nginx Proxy Manager internally using a Docker hostname like reverse-proxy, the TLS certificate — which was issued for a public domain like example.com — did not match. The fix was configuring Cloudflare Tunnel to use the correct Origin Server Name while still routing to the internal Docker hostname. This preserved full encryption without disabling validation.

How does the ZimaCube 2 networking hardware compare to a standard NAS for this use case?

Most consumer NAS devices ship with a single gigabit Ethernet port. The ZimaCube 2 has dual 2.5GbE — which means you can dedicate one interface to edge traffic (Cloudflare + reverse proxy) and the other to internal services. This physical-layer separation is something you cannot achieve on single-NIC hardware.

Comment j'ai transformé le ZimaCube 2 en contrôleur d'ingress Zero-Trust pour tout mon homelab

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

How I Turned the ZimaCube 2 Into a Zero-Trust Ingress Controller for My Entire Homelab - Zima Store Online

💡

Focus Communauté : Michael Luckenbill, Programme Pionnier ZimaCube 2

Votre homelab a une porte d’entrée. Si vous êtes comme la plupart des auto-hébergeurs, cette porte d’entrée est une redirection de port sur votre routeur — et elle est grande ouverte.

J’ai passé des semaines à reconstruire le mien. Le résultat : une couche d’ingress de qualité production fonctionnant entièrement sur un ZimaCube 2. Aucun port ouvert sur mon routeur. Aucun serveur d’origine accessible publiquement. TLS de bout en bout sur chaque connexion. Le tout posé tranquillement à côté de ma télévision.

Voici exactement comment je l’ai construit, ce qui a cassé en chemin, et pourquoi le ZimaCube 2 s’est avéré être la plateforme parfaite pour le travail.

Le problème avec l’ingress traditionnel des homelabs

Beaucoup de homelabs ressemblent encore à cela:

Port 443 redirigé sur le routeur → pointe vers un proxy inverse
Port 80 redirigé → redirige vers 443
Les services sont directement accessibles si vous connaissez l’IP
L’infrastructure d’origine est à un scan de port de la découverte

Cela crée de vrais problèmes. Ports d’ingress exposés publiquement. Serveurs d’origine directement accessibles. Interfaces d’administration qui répondent avant authentification. Même avec HTTPS, l’infrastructure elle-même reste visible — et la visibilité invite à la reconnaissance.

Je voulais un modèle complètement différent. Quelque chose de plus proche de la façon dont l’infrastructure cloud moderne gère l’ingress : confiance uniquement sortante, aucune exposition entrante, et des tunnels chiffrés qui cachent l’origine.

Diagramme d’architecture Homelab traditionnel montrant le flux de redirection de ports : Internet, routeur, proxy inverse et conteneurs Docker

Pourquoi le ZimaCube 2

Ce type d’architecture exige un ensemble spécifique de caractéristiques matérielles. Pas la puissance brute — la fiabilité, la flexibilité et le silence.

Le ZimaCube 2 a coché toutes les cases :

Toujours allumé : fonctionnement silencieux 24h/24 et 7j/7.
La couche d’ingress doit fonctionner en continu — la conception thermique du ZC2 lui permet de le faire sans dominer la pièce.

Double 2,5 GbE : une interface pour le réseau périphérique, une pour l’interne. La segmentation du trafic commence au niveau physique, pas seulement dans Docker.

Docker natif : stockage NVMe pour un I/O rapide des conteneurs. Plusieurs réseaux pont ne saturent pas le système. La plateforme a été conçue pour cela.

À ce stade, le ZimaCube 2 est devenu en fait quatre choses en une seule machine : un hôte Docker, une plateforme de proxy inverse, une couche d’ingress et un appareil d’infrastructure centralisé. Pour l’auto-hébergement moderne, cette combinaison est extrêmement pratique.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

La nouvelle architecture

Au lieu d’ouvrir des ports sur mon routeur, la nouvelle conception fonctionne ainsi :

Cloudflare Tunnel crée des connexions chiffrées sortantes uniquement vers le edge Cloudflare
Nginx Proxy Manager gère le routage, la terminaison SSL et les ACL
Les réseaux pont Docker segmentent le trafic edge des charges internes
Aucune règle NAT entrante — le routeur ne sait pas que quelque chose est servi

🔒 L’infrastructure d’origine est complètement cachée. Cloudflare se place devant tout le trafic public. Le ZimaCube 2 ne fait que des connexions sortantes. Rien n’écoute sur un port public.

Cela ressemblait immédiatement plus à une architecture d’entrée cloud moderne qu’à un auto-hébergement traditionnel avec redirection de ports.

Diagramme final de l’architecture sécurisée du homelab fonctionnant sur ZimaCube 2 avec Cloudflare Tunnel, Nginx Proxy Manager et chiffrement TLS de bout en bout

Segmentation du réseau Docker : Edge ≠ Interne

L’un des changements les plus importants a été de séparer le trafic en utilisant des réseaux pont Docker.

docker network create \

--subnet 172.x.x.x/24 \

edge

Le réseau edge ne transporte que deux conteneurs : Cloudflare Tunnel et Nginx Proxy Manager. C’est tout. Les applications vivent sur des réseaux Docker internes séparés — complètement isolés de la couche d’entrée.

🎁 Tous les conteneurs ne devraient pas être accessibles depuis Internet. Si votre serveur Plex, instance Vaultwarden ou runner CI/CD partage un réseau avec votre proxy inverse, un service compromis donne à un attaquant un accès à tout le reste.

Le ZimaCube 2 gère cette segmentation proprement. Plusieurs réseaux ponts ne créent pas de surcharge de performance sur la plateforme, et le stockage NVMe garantit que le démarrage des conteneurs et les E/S réseau restent rapides même lorsque la topologie réseau devient plus complexe.

Le problème TLS qui a failli me faire craquer

Cela s'est avéré être la leçon d'ingénierie la plus intéressante de tout le projet.

La configuration semblait simple au début. Le HTTP entre Cloudflare Tunnel et Nginx Proxy Manager a fonctionné immédiatement :

http://reverse-proxy → ✅ Ça marche

Alors j'ai activé HTTPS.

https://reverse-proxy → ❌ Échec

Le certificat était valide. La date d'expiration était correcte. La chaîne de confiance était vérifiée. Tout semblait correct — et pourtant HTTPS refusait de se connecter.

Le vrai problème était la validation du nom d'hôte TLS.

Le certificat avait été émis pour mes domaines publics (example.com, app.example.com). Mais Cloudflare Tunnel se connectait en interne au reverse-proxy — un nom d'hôte Docker qui ne correspondait à rien sur le certificat. Le décalage de nom d'hôte a fait échouer silencieusement la validation TLS.

💡 La validation TLS ne concerne pas seulement la confiance et l'expiration du certificat. Elle valide aussi l'identité du nom d'hôte et les attentes SNI. Si le nom dans l'URL ne correspond pas au nom sur le certificat, la connexion échoue — même si tout le reste est parfait.

La solution : configurer Cloudflare Tunnel avec le nom du serveur d'origine : example.com tout en continuant à router en interne vers https://reverse-proxy:443. Cela préservait le transport chiffré, la validation correcte du nom d'hôte et la vérification complète TLS — sans désactiver aucune vérification de sécurité.

C'est le genre de leçon qu'on n'apprend qu'en construisant.

Vue d'ensemble SSL/TLS Cloudflare panneau d'administration avec mode de chiffrement Full strict, diagramme du chiffrement du trafic du navigateur au serveur d'origine

ACLs et la leçon sur les chemins du trafic d'infrastructure

Une leçon opérationnelle que j'ai apprise très vite : les proxies inverses voient souvent les IP du pont Docker, les IP des tunnels et les IP des proxies internes au lieu de l'IP client d'origine.

J'ai appris cela à la dure quand je me suis accidentellement verrouillé hors de Nginx Proxy Manager.

J'ai configuré une ACL pour n'autoriser que mon sous-réseau LAN (192.168.x.x/24). La logique semblait solide — seuls les appareils de mon réseau domestique devraient accéder au panneau d'administration.

NPM voyait en fait le trafic provenant du réseau du pont Docker. Pas de mon LAN. Le contrôle d'accès bloquait tout, y compris moi.

Ajouter le sous-réseau Docker à la liste blanche a résolu le problème immédiatement. Mais cela a été un rappel très concret que les chemins du trafic d'infrastructure sont souvent différents de ce que nous supposons sur le papier.

🔄 Dans un environnement containerisé, l'IP client d'origine est réécrite à plusieurs étapes : Cloudflare edge → tunnel → pont Docker → proxy inverse. Chaque étape modifie l'adresse source. Vos règles de pare-feu doivent prendre en compte le chemin réel du trafic, pas celui que vous imaginez.

Pourquoi cette architecture est importante sur le ZimaCube 2

Il y a une raison pour laquelle cette pile fonctionne si bien spécifiquement sur le ZC2 :

Double 2.5GbE signifie que la couche d'entrée dispose d'une bande passante dédiée — votre trafic réseau interne ne concurrence pas les services exposés à Internet
Stockage NVMe garantit un réseau rapide pour les conteneurs — le débit du réseau pont ne se limite pas par un I/O disque lent
Fonctionnement silencieux en continu signifie que la couche d'entrée fonctionne 24h/24 et 7j/7 dans un espace de vie — pas dans un rack de sous-sol
Plateforme native Docker avec suffisamment de marge pour faire tourner le tunnel, le proxy inverse, le moteur ACL et tous vos services simultanément
Extensibilité signifie que vous pouvez ajouter une carte NIC dédiée ou un accélérateur plus tard si vos besoins réseau augmentent

Le ZimaCube 2 ne fait pas qu'héberger ces services. C'est la plateforme idéale pour eux.

La pile finale

Ce qui tourne actuellement sur le ZimaCube 2 :

Tunnel Cloudflare — connexions chiffrées uniquement sortantes, aucun port ouvert
Nginx Proxy Manager — proxy inverse, SSL, ACL
Réseaux pont Docker — trafic segmenté entre la périphérie et l'interne
TLS de bout en bout — chiffré du client à l'origine, aucun texte en clair nulle part
Origine cachée — rien ne répond sur une IP publique

C'est toujours un homelab. Mais le modèle opérationnel ressemble désormais beaucoup plus à l'ingénierie moderne d'entrée qu'à l'auto-hébergement traditionnel avec redirection de port.

La plus grande prise de conscience de ce projet : l'auto-hébergement moderne nécessite de plus en plus la même réflexion sur l'entrée, le réseau et les frontières de confiance que l'on trouve dans les infrastructures de production. Et le matériel doit suivre — silencieux, fiable, en réseau, et toujours allumé.

Diagramme de l'architecture moderne d'entrée de homelab comparant la conception de tunnel Cloudflare uniquement sortant à la configuration risquée de redirection de port traditionnelle

Le ZimaCube 2 offre exactement cela.

Construisez votre propre homelab zéro confiance avec ZimaCube 2 →

Questions fréquemment posées

Qu'est-ce qu'un tunnel Cloudflare et pourquoi l'utiliser sur mon ZimaCube 2 ?

Un Cloudflare Tunnel crée une connexion chiffrée sortante uniquement entre votre ZimaCube 2 et le réseau edge de Cloudflare. Au lieu d’ouvrir des ports sur votre routeur (ce qui expose votre infrastructure à Internet), tout le trafic transite par ce tunnel chiffré. Votre serveur d’origine — le ZimaCube 2 — reste complètement caché du public.

Dois-je ouvrir des ports sur mon routeur pour cette configuration ?

Non. C’est justement le but. Cloudflare Tunnel ne fait que des connexions sortantes. Votre routeur n’a pas besoin d’une seule règle de redirection de port. Cela élimine le vecteur d’attaque le plus courant dans le réseau homelab.

Le ZimaCube 2 peut-il gérer un reverse proxy et tous mes services en même temps ?

Oui. Michael ZC2 fait tourner simultanément Cloudflare Tunnel, Nginx Proxy Manager et plus de 10 conteneurs Docker — tout en restant silencieux et frais. Les deux ports 2,5 GbE et le stockage NVMe garantissent que le réseau et les entrées/sorties des conteneurs ne deviennent pas des goulots d’étranglement.

Pourquoi la segmentation réseau Docker est-elle importante ?

Si tous les conteneurs partagent le même réseau, un service compromis offre à un attaquant un accès à tout le reste. En plaçant uniquement Cloudflare Tunnel et Nginx Proxy Manager sur un réseau « edge » (et en gardant les applications sur des réseaux internes séparés), vous créez une frontière contrôlée entre le trafic public et vos services privés.

Quel était le problème de non-correspondance du nom d’hôte TLS ?

Lorsque Cloudflare Tunnel était connecté à Nginx Proxy Manager en interne via un nom d’hôte Docker comme reverse-proxy, le certificat TLS — émis pour un domaine public comme example.com — ne correspondait pas. La solution a été de configurer Cloudflare Tunnel pour utiliser le bon nom de serveur d’origine tout en continuant à router vers le nom d’hôte Docker interne. Cela a permis de conserver un chiffrement complet sans désactiver la validation.

Comment le matériel réseau du ZimaCube 2 se compare-t-il à un NAS standard pour ce cas d’usage ?

La plupart des NAS grand public sont équipés d’un seul port Ethernet gigabit. Le ZimaCube 2 dispose de deux ports 2,5 GbE — ce qui signifie que vous pouvez dédier une interface au trafic edge (Cloudflare + reverse proxy) et l’autre aux services internes. Cette séparation au niveau physique est impossible à réaliser avec un matériel à carte réseau unique.