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

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 reverse 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 ingressportar. Direktåtkomliga ursprungsservrar. Administrationsgränssnitt som svarar innan autentisering. Även med HTTPS är infrastrukturen själv 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, ingen 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 pålitlighet, flexibilitet och tystnad.

ZimaCube 2 uppfyllde alla krav:

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

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Den nya arkitekturen

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

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

Detta 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-bryggnätverk.

Kantnä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 ingångsskiktet.

ZimaCube 2 hanterar denna segmentering på ett rent sätt. Flera bryggnä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

Detta visade sig vara den mest intressanta ingenjörslärdomen i hela projektet.

Installationen verkade enkel från 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 stämde. 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 kopplade internt till reverse-proxy — ett Docker-värdnamn som inte matchade något på certifikatet. Värdnamnsavvikelsen gjorde att TLS-valideringen tyst misslyckades.

Lösningen: konfigurera Cloudflare Tunnel med Origin Server Name: example.com samtidigt som intern routing sker 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: reverse proxies 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 ha tillgång till administrationspanelen.

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.

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ätverkstrafik — 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

Det som körs på ZimaCube 2 just nu:

• Cloudflare Tunnel — endast 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, inget 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 portvidarebefordrad självhostning.

Den största insikten från detta projekt: modern självhostning 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 ditt eget 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 portöppningsregel. 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 varje container 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ärdnamnsmatchningen?

När Cloudflare Tunnel anslöt till Nginx Proxy Manager internt med ett Docker-värdnamn som reverse-proxy, matchade inte TLS-certifikatet — som utfärdats för en offentlig domän som example.com. Lösningen var att konfigurera Cloudflare Tunnel att använda rätt Origin Server Name samtidigt som den fortfarande dirigerade 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ändningsfall?

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.