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.

Hur jag förvandlade ZimaCube 2 till en zero-trust ingresskontroller för hela mitt homelab

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

"Dual monitor home lab workstation showing Lucky in Prod blog page, mini server tower, keyboard and coding setup on office desk

💡

Community Spotlight: Michael Luckenbill, ZimaCube 2 Pioneer Program

Din homelab har en ytterdörr. Om du är som de flesta självhostare är den ytterdörren en portvidarebefordran på din router — och den är vidöppen.

Jag tillbringade veckor med att bygga om min. Resultatet: ett produktionsklart ingresslager som körs helt på en ZimaCube 2. Inga öppna portar på min router. Inga publikt nåbara ursprungsservrar. End-to-end TLS på varje anslutning. Allt sitter tyst bredvid min TV.

Här är exakt hur jag byggde det, vad som gick sönder på vägen och varför ZimaCube 2 visade sig vara den perfekta plattformen för jobbet.

Problemet med traditionell homelab-ingress

Många homelabs ser fortfarande ut så här:

Port 443 vidarebefordrad på routern → pekar på en omvänd proxy
Port 80 vidarebefordrad → omdirigerar till 443
Tjänster är direktåtkomliga om du känner till IP-adressen
Ursprungsinfrastrukturen är bara en portskanning från att upptäckas

Detta skapar verkliga problem. Publikt exponerade ingress-portar. Direktåtkomliga ursprungsservrar. Administrationsgränssnitt som svarar innan autentisering. Även med HTTPS förblir infrastrukturen synlig — och synlighet inbjuder till rekognosering.

Jag ville ha en helt annan modell. Något närmare hur modern molninfrastruktur hanterar ingress: endast utgående förtroende, noll inkommande exponering och krypterade tunnlar som döljer ursprunget.

Varför ZimaCube 2

Den här typen av arkitektur kräver en specifik uppsättning hårdvaruegenskaper. Inte rå kraft — utan tillförlitlighet, flexibilitet och tystnad.

ZimaCube 2 uppfyllde alla krav:

Alltid på: Tyst drift dygnet runt.
Ingresslagret måste köras kontinuerligt — ZC2:s termiska design gör att det kan göra det utan att dominera rummet.

Dubbel 2,5GbE: En gränssnitt för kantnätverket, en för internt. Trafiksegmentering börjar på den fysiska nivån, inte bara i Docker.

Docker Native: NVMe-lagring för snabb container-I/O. Flera bridge-nätverk överbelastar inte systemet. Plattformen är byggd för detta.

Vid det här laget har ZimaCube 2 effektivt blivit fyra saker i en maskin: en Docker-värd, en omvänd proxyplattform, ett ingresslager och en centraliserad infrastrukturapparat. För modern självhosting är den kombinationen extremt praktisk.

Featured

ZimaCube 2 Personlig molnhem-NAS

ZimaCube2

Den nya arkitekturen

Istället för att öppna portar på min router fungerar den nya designen så här:

Cloudflare Tunnel skapar utgående krypterade anslutningar till Cloudflares kant
Nginx Proxy Manager hanterar routing, SSL-terminering och ACL:er
Docker bridge-nätverk segmenterar kanttrafik från interna arbetsbelastningar
Inga inkommande NAT-regler — routern har ingen aning om att något serveras

🔒 Ursprunglig infrastruktur är helt dold. Cloudflare sitter framför all publik trafik. ZimaCube 2 gör bara utgående anslutningar. Ingenting lyssnar på en publik port.

Det kändes genast närmare modern molningångsarkitektur än traditionell portvidarebefordrad självhostning.

Docker-nätverkssegmentering: Edge ≠ Intern

En av de viktigaste förändringarna var att separera trafiken med Docker bridge-nätverk.

docker network create \

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

edge

Edge-nätverket bär exakt två containrar: Cloudflare Tunnel och Nginx Proxy Manager. Det är allt. Applikationer finns på separata interna Docker-nätverk — helt isolerade från ingresslagret.

🎁 Inte varje container bör vara internet-nära. Om din Plex-server, Vaultwarden-instans eller CI/CD-runner delar nätverk med din reverse proxy, ger en komprometterad tjänst en angripare tillgång till allt annat.

ZimaCube 2 hanterar denna segmentering smidigt. Flera bridge-nätverk skapar ingen prestandabelastning på plattformen, och NVMe-lagringen säkerställer att containerstart och nätverks-I/O förblir snabba även när nätverkstopologin blir mer komplex.

TLS-problemet som nästan knäckte mig

Det här blev den mest intressanta ingenjörslärdomen i hela projektet.

Installationen verkade enkel till en början. HTTP mellan Cloudflare Tunnel och Nginx Proxy Manager fungerade omedelbart:

http://reverse-proxy → ✅ Fungerar

Så jag aktiverade HTTPS.

https://reverse-proxy → ❌ Misslyckas

Certifikatet var giltigt. Utgångsdatumet var okej. Tillitskedjan kontrollerades. Allt såg korrekt ut — och ändå vägrade HTTPS att ansluta.

Det verkliga problemet var TLS-värdnamnsvalideringen.

Certifikatet utfärdades för mina publika domäner (example.com, app.example.com). Men Cloudflare Tunnel anslöt internt till reverse-proxy — ett Docker-värdnamn som inte matchade något på certifikatet. Värdnamnsavvikelsen orsakade att TLS-valideringen tyst misslyckades.

💡 TLS-validering handlar inte bara om certifikatets tillit och utgångsdatum. Den validerar också värdnamnsidentitet och SNI-förväntningar. Om namnet i URL:en inte matchar namnet på certifikatet misslyckas anslutningen — även om allt annat är perfekt.

Lösningen: konfigurera Cloudflare Tunnel med Origin Server Name: example.com samtidigt som den fortfarande dirigerar internt till https://reverse-proxy:443. Det bevarade krypterad transport, korrekt värdnamnsvalidering och full TLS-verifiering — utan att inaktivera några säkerhetskontroller.

Det här är den typ av lärdom man bara får genom att bygga.

ACL:er och lärdomen om infrastrukturens trafikvägar

En operativ lärdom jag snabbt insåg: omvända proxys ser ofta Docker bridge-IP:er, tunnel-IP:er och interna proxy-IP:er istället för den ursprungliga klient-IP:n.

Jag lärde mig detta på det hårda sättet när jag av misstag låste ute mig själv från Nginx Proxy Manager.

Jag konfigurerade en ACL för att endast tillåta mitt LAN-subnät (192.168.x.x/24). Logiken verkade rimlig — endast enheter i mitt hemnätverk skulle få åtkomst till adminpanelen.

NPM såg faktiskt trafik från Docker bridge-nätverket. Inte från mitt LAN. Åtkomstkontrollen blockerade allt, inklusive mig.

Att lägga till Docker-subnätet i tillåtlistan löste det omedelbart. Men det var en mycket verklig påminnelse om att infrastrukturens trafikvägar ofta skiljer sig från vad vi antar på papper.

🔄 I en containeriserad miljö skrivs den ursprungliga klient-IP:n om vid flera hopp: Cloudflare edge → tunnel → Docker bridge → omvänd proxy. Varje hopp ändrar källadressen. Dina brandväggsregler måste ta hänsyn till den faktiska trafikvägen, inte den du föreställer dig.

Varför denna arkitektur är viktig på ZimaCube 2

Det finns en anledning till att denna stack fungerar så bra just på ZC2:

Dubbel 2.5GbE betyder att ingresslagret har dedikerad bandbredd — din interna nätverkstrafik konkurrerar inte med internetvända tjänster
NVMe-lagring säkerställer snabb container-nätverkning — bridge-nätverkets genomströmning begränsas inte av långsam disk-I/O
Tyst alltid-på-drift betyder att ingresslagret körs dygnet runt i ett bostadsutrymme — inte i ett källarrack
Docker-native plattform med tillräckligt med kapacitet för att köra tunneln, omvänd proxy, ACL-motor och alla dina tjänster samtidigt
Utbyggbarhet betyder att du kan lägga till ett dedikerat nätverkskort eller accelerator senare om dina nätverksbehov växer

ZimaCube 2 är inte bara värd för dessa tjänster. Det är den rätta plattformen för dem.

Den slutgiltiga stacken

Vad som körs på ZimaCube 2 nu:

Cloudflare Tunnel — utgående krypterade anslutningar, inga öppna portar
Nginx Proxy Manager — omvänd proxy, SSL, ACL:er
Docker bridge-nätverk — segmenterad kant- vs. intern trafik
End-to-end TLS — krypterat från klient till ursprung, ingen klartext någonstans
Gömd ursprung — inget svarar på en publik IP

Det är fortfarande ett homelab. Men driftsmodellen liknar nu modern ingress-engineering mycket mer än traditionell port-forwardad självhostning.

Den största insikten från detta projekt: modern självhosting kräver i allt högre grad samma ingress-, nätverks- och förtroendegränstänk som finns i produktionsinfrastruktur. Och hårdvaran måste hänga med — tyst, pålitlig, nätverksansluten och alltid på.

ZimaCube 2 levererar precis det.

Bygg din egen zero-trust homelab med ZimaCube 2 →

Vanliga frågor

Vad är en Cloudflare Tunnel och varför skulle jag använda den på min ZimaCube 2?

En Cloudflare Tunnel skapar en krypterad anslutning som endast är utgående från din ZimaCube 2 till Cloudflares edge-nätverk. Istället för att öppna portar på din router (vilket exponerar din infrastruktur mot internet) går all trafik genom denna krypterade tunnel. Din origin-server — ZimaCube 2 — förblir helt dold från allmänheten.

Behöver jag öppna några portar på min router för denna setup?

Nej. Det är poängen. Cloudflare Tunnel gör endast utgående anslutningar. Din router behöver inte någon portvidarebefordringsregel. Detta eliminerar den vanligaste attackvektorn i homelab-nätverk.

Kan ZimaCube 2 hantera att köra en reverse proxy och alla mina tjänster samtidigt?

Ja. Michael ZC2 kör Cloudflare Tunnel, Nginx Proxy Manager och över 10 Docker-containrar samtidigt — allt medan den är tyst och sval. De dubbla 2,5GbE-portarna och NVMe-lagringen säkerställer att nätverk och container-I/O inte blir flaskhalsar.

Varför är Docker-nätverkssegmentering viktig?

Om alla containrar delar samma nätverk ger en komprometterad tjänst en angripare tillgång till allt annat. Genom att placera endast Cloudflare Tunnel och Nginx Proxy Manager på ett "edge"-nätverk (och hålla applikationer på separata interna nätverk) skapar du en kontrollerad gräns mellan publik trafik och dina privata tjänster.

Vad var problemet med TLS-värdnamnsmismatchen?

När Cloudflare Tunnel anslöt till Nginx Proxy Manager internt med ett Docker-värdnamn som reverse-proxy, stämde inte TLS-certifikatet — som utfärdats för en offentlig domän som example.com — överens. Lösningen var att konfigurera Cloudflare Tunnel att använda rätt Origin Server Name samtidigt som trafiken fortfarande dirigerades till det interna Docker-värdnamnet. Detta bevarade full kryptering utan att inaktivera valideringen.

Hur står sig ZimaCube 2:s nätverkshårdvara jämfört med en standard-NAS för detta användningsområde?

De flesta konsument-NAS-enheter levereras med en enda gigabit Ethernet-port. ZimaCube 2 har dubbla 2,5GbE — vilket innebär att du kan dedikera en gränssnitt till edge-trafik (Cloudflare + reverse proxy) och den andra till interna tjänster. Denna separation på fysisk nivå är något du inte kan uppnå med hårdvara som har en enda nätverkskort.