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

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 la tâche.

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.

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 coche toutes les cases :

À 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

$799.00 - $2,499.00

Buy Now

La nouvelle architecture

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

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

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

Segmentation 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.

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.

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 si 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 fonctionnait immédiatement :

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

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 à un reverse-proxy — un nom d'hôte Docker qui ne correspondait à rien sur le certificat. Ce décalage de nom d'hôte a fait échouer silencieusement la validation TLS.

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 a préservé le transport chiffré, une validation correcte du nom d'hôte et une 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.

ACL 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 du tunnel 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 cohérente — seuls les appareils de mon réseau domestique devaient accéder au panneau d’administration.

NPM voyait en fait le trafic provenant du réseau 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 l’on suppose sur le papier.

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 ingress 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 de conteneurs rapide — le débit du réseau pont ne se bloque pas sur des E/S disque lentes
• Fonctionnement silencieux en continu signifie que la couche ingress 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 une carte accélératrice plus tard si vos besoins réseau augmentent

Le ZimaCube 2 ne se contente pas d’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 sortantes uniquement, 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 — aucune réponse sur une IP publique

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

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’ingress, 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é.

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 Cloudflare Tunnel 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 passe 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 Cloudflare Tunnel, Nginx Proxy Manager et plus de 10 conteneurs Docker simultanément — 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 goulets d’étranglement.

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

Si tous les conteneurs partagent le même réseau, un service compromis donne à 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.