Wie ich den ZimaCube 2 in einen Zero-Trust-Ingress-Controller für mein gesamtes Homelab verwandelt habe

Dein Homelab hat eine Haustür. Wenn du wie die meisten Self-Hoster bist, ist diese Haustür eine Portweiterleitung an deinem Router – und sie steht weit offen.

Ich habe Wochen damit verbracht, meinen neu aufzubauen. Das Ergebnis: eine produktionsreife Ingress-Schicht, die vollständig auf einem ZimaCube 2 läuft. Keine offenen Ports an meinem Router. Keine öffentlich erreichbaren Ursprungsserver. Ende-zu-Ende-TLS bei jeder Verbindung. Und das alles steht leise neben meinem Fernseher.

Hier ist genau beschrieben, wie ich es gebaut habe, was unterwegs kaputtging und warum der ZimaCube 2 sich als perfekte Plattform für die Aufgabe erwies.

Das Problem mit traditionellem Homelab-Ingress

Viele Homelabs sehen immer noch so aus.:

• Port 443 am Router weitergeleitet → zeigt auf einen Reverse Proxy.
• Port 80 weitergeleitet → leitet auf 443 um.
• Dienste sind direkt erreichbar, wenn man die IP kennt.
• Die Ursprungsinfrastruktur ist nur einen Port-Scan von der Entdeckung entfernt.

Das schafft echte Probleme. Öffentlich zugängliche Ingress-Ports. Direkt erreichbare Ursprungsserver. Admin-Oberflächen, die vor der Authentifizierung antworten. Selbst mit HTTPS bleibt die Infrastruktur sichtbar – und Sichtbarkeit lädt zur Aufklärung ein.

Ich wollte ein ganz anderes Modell. Etwas, das näher an der modernen Cloud-Infrastruktur für Ingress liegt: nur ausgehendes Vertrauen, keine eingehende Exposition und verschlüsselte Tunnel, die den Ursprung verbergen.

Warum der ZimaCube 2

Diese Art von Architektur verlangt eine spezifische Hardwareausstattung. Nicht rohe Leistung – Zuverlässigkeit, Flexibilität und Stille.

Der ZimaCube 2 erfüllte alle Anforderungen:

An diesem Punkt ist der ZimaCube 2 effektiv zu vier Dingen in einer Maschine geworden: einem Docker-Host, einer Reverse-Proxy-Plattform, einer Ingress-Schicht und einem zentralisierten Infrastrukturgerät. Für modernes Self-Hosting ist diese Kombination äußerst praktisch.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Die neue Architektur

Anstatt Ports an meinem Router zu öffnen, funktioniert das neue Design so:

1. Cloudflare Tunnel erstellt nur ausgehende verschlüsselte Verbindungen zum Cloudflare-Edge
2. Nginx Proxy Manager übernimmt Routing, SSL-Terminierung und ACLs
3. Docker-Bridge-Netzwerke trennen Edge-Traffic von internen Workloads
4. Keine eingehenden NAT-Regeln — der Router hat keine Ahnung, dass etwas bereitgestellt wird

Das fühlte sich sofort moderner an als traditionelle Port-Weiterleitung beim Self-Hosting.

Docker-Netzwerksegmentierung: Edge ≠ Intern

Eine der wichtigsten Änderungen war die Trennung des Verkehrs durch Docker-Bridge-Netzwerke.

Das Edge-Netzwerk trägt genau zwei Container: Cloudflare Tunnel und Nginx Proxy Manager. Das war’s. Anwendungen laufen auf separaten internen Docker-Netzwerken — vollständig isoliert von der Ingress-Schicht.

Der ZimaCube 2 handhabt diese Segmentierung sauber. Mehrere Bridge-Netzwerke verursachen keine Leistungsüberlastung auf der Plattform, und der NVMe-Speicher sorgt dafür, dass Container-Start und Netzwerk-I/O auch bei wachsender Netzwerktopologie schnell bleiben.

Das TLS-Problem, das mich fast zum Scheitern brachte

Dies wurde die interessanteste technische Lektion im gesamten Projekt.

Die Einrichtung schien zunächst unkompliziert. HTTP zwischen Cloudflare Tunnel und Nginx Proxy Manager funktionierte sofort:

http://reverse-proxy  →  ✅ Funktioniert

Also habe ich HTTPS aktiviert.

https://reverse-proxy  →  ❌ Fehlgeschlagen

Das Zertifikat war gültig. Das Ablaufdatum stimmte. Die Vertrauenskette war in Ordnung. Alles sah korrekt aus – und trotzdem verweigerte HTTPS die Verbindung.

Das eigentliche Problem war die TLS-Hostnamen-Validierung.

Das Zertifikat wurde für meine öffentlichen Domains (example.com, app.example.com) ausgestellt. Aber Cloudflare Tunnel verband sich intern mit reverse-proxy – einem Docker-Hostnamen, der mit keinem Namen im Zertifikat übereinstimmte. Die Hostnamen-Abweichung führte dazu, dass die TLS-Validierung stillschweigend fehlschlug.

Die Lösung: Cloudflare Tunnel mit Origin Server Name: example.com konfigurieren, während intern weiterhin zu https://reverse-proxy:443. Das bewahrte den verschlüsselten Transport, die korrekte Hostnamen-Validierung und die vollständige TLS-Überprüfung – ohne Sicherheitsprüfungen zu deaktivieren.

Das ist die Art von Lektion, die man nur durch eigenes Bauen lernt.

ACLs und die Lektion über Infrastruktur-Verkehrswege

Eine betriebliche Lektion, die ich sehr schnell gelernt habe: Reverse-Proxies sehen oft Docker-Bridge-IPs, Tunnel-IPs und interne Proxy-IPs statt der ursprünglichen Client-IP.

Das habe ich auf die harte Tour gelernt, als ich mich versehentlich aus dem Nginx Proxy Manager ausgesperrt habe.

Ich habe eine ACL konfiguriert, die nur mein LAN-Subnetz (192.168.x.x/24) zulässt. Die Logik schien sinnvoll – nur Geräte in meinem Heimnetzwerk sollten auf das Admin-Panel zugreifen dürfen.

NPM sah tatsächlich Verkehr vom Docker-Bridge-Netzwerk. Nicht von meinem LAN. Die Zugriffskontrolle blockierte alles, mich eingeschlossen.

Das Hinzufügen des Docker-Subnetzes zur Whitelist hat das Problem sofort gelöst. Aber es war eine sehr reale Erinnerung daran, dass Infrastruktur-Verkehrswege oft anders sind, als wir es auf dem Papier annehmen.

Warum diese Architektur auf dem ZimaCube 2 wichtig ist

Es gibt einen Grund, warum dieser Stack speziell auf dem ZC2 so gut funktioniert:

• Duale 2,5GbE bedeutet, dass die Ingress-Schicht dedizierte Bandbreite hat — dein interner Netzwerkverkehr konkurriert nicht mit internetseitigen Diensten
• NVMe-Speicher sorgt für schnelles Container-Netzwerk — Bridge-Netzwerk-Durchsatz wird nicht durch langsame Festplatten-I/O gebremst
• Leiser Dauerbetrieb bedeutet, dass die Ingress-Schicht rund um die Uhr in einem Wohnraum läuft — nicht in einem Keller-Rack
• Docker-native Plattform mit genug Kapazität, um Tunnel, Reverse Proxy, ACL-Engine und alle deine Dienste gleichzeitig zu betreiben
• Erweiterbarkeit bedeutet, dass du später eine dedizierte Netzwerkkarte oder Beschleunigerkarte hinzufügen kannst, wenn dein Netzwerkbedarf wächst

Der ZimaCube 2 hostet diese Dienste nicht nur. Er ist die richtige Plattform für sie.

Der finale Stack

Was jetzt auf dem ZimaCube 2 läuft:

• Cloudflare Tunnel — nur ausgehende verschlüsselte Verbindungen, keine offenen Ports
• Nginx Proxy Manager — Reverse Proxy, SSL, ACLs
• Docker-Bridge-Netzwerke — segmentierter Edge- vs. interner Traffic
• End-to-End-TLS — verschlüsselt vom Client bis zum Ursprung, nirgendwo Klartext
• Versteckter Ursprung — nichts antwortet auf einer öffentlichen IP

Es ist immer noch ein Homelab. Aber das Betriebsmodell ähnelt jetzt moderner Ingress-Engineering viel mehr als traditionellem portweitergeleitetem Self-Hosting.

Die wichtigste Erkenntnis aus diesem Projekt: modernes Self-Hosting erfordert zunehmend dasselbe Ingress-, Netzwerk- und Vertrauensgrenzen-Denken wie in Produktionsinfrastrukturen. Und die Hardware muss mithalten — leise, zuverlässig, vernetzt und immer eingeschaltet.

Der ZimaCube 2 liefert genau das.

Baue dein eigenes Zero-Trust-Homelab mit dem ZimaCube 2 →

Häufig gestellte Fragen

Was ist ein Cloudflare Tunnel und warum sollte ich ihn auf meinem ZimaCube 2 verwenden?

Ein Cloudflare Tunnel stellt eine ausschließlich ausgehende, verschlüsselte Verbindung von Ihrem ZimaCube 2 zum Cloudflare-Edge-Netzwerk her. Anstatt Ports an Ihrem Router zu öffnen (was Ihre Infrastruktur dem Internet aussetzt), fließt der gesamte Traffic durch diesen verschlüsselten Tunnel. Ihr Origin-Server – der ZimaCube 2 – bleibt vollständig vor der Öffentlichkeit verborgen.

Muss ich für diese Einrichtung Ports an meinem Router öffnen?

Nein. Genau das ist der Punkt. Cloudflare Tunnel stellt nur ausgehende Verbindungen her. Ihr Router benötigt keine einzige Portweiterleitungsregel. Das beseitigt den häufigsten Angriffsvektor im Homelab-Netzwerk.

Kann der ZimaCube 2 gleichzeitig einen Reverse Proxy und alle meine Dienste betreiben?

Ja. Michael ZC2 betreibt Cloudflare Tunnel, Nginx Proxy Manager und über 10 Docker-Container gleichzeitig – und das bei leisem, kühlem Betrieb. Die zwei 2,5GbE-Ports und der NVMe-Speicher sorgen dafür, dass Netzwerk- und Container-I/O keine Engpässe verursachen.

Warum ist die Segmentierung des Docker-Netzwerks wichtig?

Wenn alle Container dasselbe Netzwerk teilen, erhält ein kompromittierter Dienst einem Angreifer Zugang zu allem anderen. Indem Sie nur Cloudflare Tunnel und Nginx Proxy Manager in einem „Edge“-Netzwerk platzieren (und Anwendungen in separaten internen Netzwerken halten), schaffen Sie eine kontrollierte Grenze zwischen öffentlich zugänglichem Traffic und Ihren privaten Diensten.

Was war das Problem mit der TLS-Hostname-Übereinstimmung?

Als Cloudflare Tunnel intern über einen Docker-Hostnamen wie reverse-proxy mit Nginx Proxy Manager verbunden wurde, stimmte das TLS-Zertifikat – das für eine öffentliche Domain wie example.com ausgestellt wurde – nicht überein. Die Lösung bestand darin, Cloudflare Tunnel so zu konfigurieren, dass der korrekte Origin Server Name verwendet wird, während der interne Docker-Hostname weiterhin geroutet wird. So blieb die vollständige Verschlüsselung erhalten, ohne die Validierung zu deaktivieren.

Wie schneidet die Netzwerktechnik des ZimaCube 2 im Vergleich zu einem Standard-NAS für diesen Anwendungsfall ab?

Die meisten Consumer-NAS-Geräte werden mit einem einzelnen Gigabit-Ethernet-Anschluss geliefert. Der ZimaCube 2 verfügt über zwei 2,5GbE-Anschlüsse – das bedeutet, Sie können eine Schnittstelle für Edge-Traffic (Cloudflare + Reverse Proxy) und die andere für interne Dienste reservieren. Diese Trennung auf physikalischer Ebene ist mit Hardware mit nur einer Netzwerkkarte nicht möglich.