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.

Come ho trasformato lo ZimaCube 2 in un controller di ingresso a zero trust per tutto il mio homelab

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

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

💡

Community Spotlight: Michael Luckenbill, Programma Pionieri ZimaCube 2

Il tuo homelab ha una porta d’ingresso. Se sei come la maggior parte dei self-hosters, quella porta è un port forwarding sul tuo router — ed è spalancata.

Ho passato settimane a ricostruire il mio. Il risultato: un livello di ingress di qualità produttiva che gira interamente su un ZimaCube 2. Nessuna porta aperta sul mio router. Nessun server di origine raggiungibile pubblicamente. TLS end-to-end su ogni connessione. Tutto questo silenziosamente accanto alla mia TV.

Ecco esattamente come l’ho costruito, cosa si è rotto lungo il percorso e perché il ZimaCube 2 si è rivelato la piattaforma perfetta per il lavoro.

Il problema con l’ingress tradizionale degli homelab

Molti homelab sono ancora così:

Porta 443 inoltrata sul router → punta a un reverse proxy
Porta 80 inoltrata → reindirizza alla 443
I servizi sono direttamente raggiungibili se conosci l’IP
L’infrastruttura di origine è a un solo scan di porta dalla scoperta

Questo crea veri problemi. Porte di ingress pubblicamente esposte. Server di origine direttamente raggiungibili. Interfacce di amministrazione che rispondono prima dell’autenticazione. Anche con HTTPS, l’infrastruttura rimane visibile — e la visibilità invita alla ricognizione.

Volevo un modello completamente diverso. Qualcosa di più vicino a come l'infrastruttura cloud moderna gestisce l’ingress: fiducia solo in uscita, zero esposizione in ingresso e tunnel criptati che nascondono l’origine.

Diagramma dell'architettura tradizionale Homelab che mostra il flusso di port forwarding: Internet, router, reverse proxy e container Docker

Perché il ZimaCube 2

Questo tipo di architettura richiede un insieme specifico di caratteristiche hardware. Non potenza bruta — affidabilità, flessibilità e silenziosità.

Il ZimaCube 2 ha soddisfatto ogni requisito:

Sempre Attivo: Funzionamento silenzioso 24/7.
Il livello di ingress deve funzionare continuamente — il design termico del ZC2 permette che ciò avvenga senza dominare la stanza.

Doppio 2.5GbE: Un'interfaccia per la rete edge, una per quella interna. La segmentazione del traffico inizia a livello fisico, non solo in Docker.

Docker Nativo: Storage NVMe per un I/O veloce dei container. Più reti bridge non bloccano il sistema. La piattaforma è stata progettata per questo.

A questo punto, il ZimaCube 2 è diventato di fatto quattro cose in una sola macchina: un host Docker, una piattaforma di reverse proxy, un livello di ingress e un dispositivo di infrastruttura centralizzato. Per il self-hosting moderno, questa combinazione è estremamente pratica.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

La nuova architettura

Invece di aprire porte sul mio router, il nuovo design funziona così:

Cloudflare Tunnel crea connessioni criptate solo in uscita verso l'edge di Cloudflare
Nginx Proxy Manager gestisce il routing, la terminazione SSL e le ACL
Le reti bridge Docker segmentano il traffico edge dai carichi di lavoro interni
Nessuna regola NAT in ingresso — il router non ha idea che qualcosa venga servito

🔒 L'infrastruttura originaria è completamente nascosta. Cloudflare si trova davanti a tutto il traffico pubblico. Il ZimaCube 2 effettua solo connessioni in uscita. Nessuno ascolta su una porta pubblica.

Questo ha subito dato una sensazione più vicina all'architettura moderna di ingress cloud rispetto al tradizionale self-hosting con port forwarding.

Diagramma finale dell'architettura sicura per homelab in esecuzione su ZimaCube 2 con Cloudflare Tunnel, Nginx Proxy Manager e crittografia TLS end-to-end

Segmentazione della rete Docker: Edge ≠ Interna

Uno dei cambiamenti più importanti è stato separare il traffico usando reti bridge Docker.

docker network create \

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

edge

La rete edge ospita esattamente due container: Cloudflare Tunnel e Nginx Proxy Manager. Nient'altro. Le applicazioni vivono su reti Docker interne separate — completamente isolate dal livello di ingresso.

🎁 Non tutti i container dovrebbero essere esposti a internet. Se il tuo server Plex, l'istanza Vaultwarden o il runner CI/CD condividono una rete con il tuo reverse proxy, un servizio compromesso offre a un attaccante un accesso a tutto il resto.

Il ZimaCube 2 gestisce questa segmentazione in modo pulito. Più reti bridge non creano sovraccarico di prestazioni sulla piattaforma, e lo storage NVMe garantisce che l'avvio dei container e l'I/O di rete rimangano veloci anche quando la topologia di rete diventa più complessa.

Il problema TLS che quasi mi ha fatto crollare

Questo si è rivelato essere la lezione di ingegneria più interessante di tutto il progetto.

L'installazione sembrava semplice all'inizio. HTTP tra Cloudflare Tunnel e Nginx Proxy Manager ha funzionato immediatamente:

http://reverse-proxy → ✅ Funziona

Quindi ho abilitato HTTPS.

https://reverse-proxy → ❌ Fallisce

Il certificato era valido. La data di scadenza era corretta. La catena di fiducia era verificata. Tutto sembrava a posto — eppure HTTPS si rifiutava di connettersi.

Il vero problema era la validazione del nome host TLS.

Il certificato era emesso per i miei domini pubblici (example.com, app.example.com). Ma Cloudflare Tunnel si collegava internamente al reverse-proxy — un nome host Docker che non corrispondeva a nulla sul certificato. La discrepanza del nome host ha causato il fallimento silenzioso della validazione TLS.

💡 La validazione TLS non riguarda solo la fiducia nel certificato e la sua scadenza. Valida anche l'identità del nome host e le aspettative SNI. Se il nome nell'URL non corrisponde al nome sul certificato, la connessione fallisce — anche se tutto il resto è perfetto.

La soluzione: configurare Cloudflare Tunnel con Nome Server di Origine: example.com mantenendo comunque il routing interno verso https://reverse-proxy:443. Questo ha preservato il trasporto criptato, la corretta validazione del nome host e la verifica completa TLS — senza disabilitare alcun controllo di sicurezza.

Questo è il tipo di lezione che si impara solo costruendo.

Panoramica SSL/TLS di Cloudflare nel pannello di amministrazione con modalità di crittografia Full strict, diagramma di crittografia del traffico dal browser al server di origine

ACL e la lezione sui percorsi del traffico infrastrutturale

Una lezione operativa che ho imparato molto rapidamente: i reverse proxy spesso vedono IP del bridge Docker, IP del tunnel e IP del proxy interno invece dell'IP originale del client.

L'ho imparato a mie spese quando mi sono accidentalmente bloccato fuori da Nginx Proxy Manager.

Ho configurato un ACL per consentire solo la mia subnet LAN (192.168.x.x/24). La logica sembrava sensata — solo i dispositivi della mia rete domestica dovrebbero accedere al pannello di amministrazione.

NPM stava effettivamente vedendo traffico dalla rete bridge di Docker. Non dalla mia LAN. Il controllo accessi bloccava tutto, me compreso.

Aggiungere la subnet Docker alla lista consentiti ha risolto immediatamente il problema. Ma è stato un promemoria molto reale che i percorsi del traffico infrastrutturale sono spesso diversi da quelli che assumiamo sulla carta.

🔄 In un ambiente containerizzato, l'IP originale del client viene riscritto a più passaggi: Cloudflare edge → tunnel → bridge Docker → reverse proxy. Ogni passaggio cambia l'indirizzo sorgente. Le regole del firewall devono tenere conto del percorso reale del traffico, non di quello che si immagina.

Perché questa architettura è importante sul ZimaCube 2

C'è un motivo per cui questo stack funziona così bene proprio sul ZC2:

Doppio 2.5GbE significa che il livello di ingresso ha larghezza di banda dedicata — il traffico interno non compete con i servizi esposti su internet
Storage NVMe garantisce una rete container veloce — la larghezza di banda della rete bridge non è limitata da I/O disco lento
Funzionamento silenzioso sempre attivo significa che il livello di ingresso funziona 24/7 in uno spazio abitativo — non in un rack in cantina
Piattaforma nativa Docker con abbastanza risorse per eseguire contemporaneamente tunnel, reverse proxy, motore ACL e tutti i tuoi servizi
Espandibilità significa che puoi aggiungere una NIC dedicata o una scheda acceleratrice in seguito se le tue esigenze di rete crescono

ZimaCube 2 non ospita solo questi servizi. È la piattaforma giusta per farlo.

Lo Stack Finale

Cosa gira ora sul ZimaCube 2:

Cloudflare Tunnel — connessioni crittografate solo in uscita, zero porte aperte
Nginx Proxy Manager — reverse proxy, SSL, ACL
Reti bridge Docker — traffico segmentato tra edge e interno
TLS end-to-end — crittografato dal client all'origine, nessun testo in chiaro da nessuna parte
Origine nascosta — nessuna risposta su un IP pubblico

Rimane comunque un homelab. Ma il modello operativo ora assomiglia molto di più all'ingegneria moderna dell'ingresso rispetto al tradizionale self-hosting con port forwarding.

La più grande consapevolezza di questo progetto: l'hosting autonomo moderno richiede sempre più lo stesso approccio all'ingresso, alla rete e ai confini di fiducia tipico delle infrastrutture di produzione. E l'hardware deve stare al passo — silenzioso, affidabile, connesso in rete e sempre acceso.

Diagramma dell'architettura moderna di ingresso per homelab che confronta il design del tunnel Cloudflare solo in uscita con la rischiosa configurazione tradizionale di port forwarding

ZimaCube 2 offre esattamente questo.

Costruisci il tuo homelab zero-trust con ZimaCube 2 →

Domande Frequenti

Cos'è un Cloudflare Tunnel e perché dovrei usarlo sul mio ZimaCube 2?

Un Cloudflare Tunnel crea una connessione crittografata in uscita dal tuo ZimaCube 2 alla rete edge di Cloudflare. Invece di aprire porte sul router (che esporrebbe la tua infrastruttura a internet), tutto il traffico passa attraverso questo tunnel crittografato. Il tuo server origin — il ZimaCube 2 — rimane completamente nascosto alla vista pubblica.

Devo aprire delle porte sul mio router per questa configurazione?

No. Questo è il punto. Cloudflare Tunnel effettua solo connessioni in uscita. Il tuo router non necessita di alcuna regola di port forwarding. Questo elimina il vettore di attacco più comune nel networking per homelab.

Il ZimaCube 2 può gestire l'esecuzione simultanea di un reverse proxy e di tutti i miei servizi?

Sì. Michael ZC2 esegue contemporaneamente Cloudflare Tunnel, Nginx Proxy Manager e oltre 10 container Docker — tutto mantenendo un funzionamento silenzioso e fresco. Le porte dual 2.5GbE e lo storage NVMe assicurano che la rete e l'I/O dei container non diventino colli di bottiglia.

Perché la segmentazione della rete Docker è importante?

Se ogni container condivide la stessa rete, un servizio compromesso offre a un attaccante un accesso a tutto il resto. Collocando solo Cloudflare Tunnel e Nginx Proxy Manager su una rete "edge" (e mantenendo le applicazioni su reti interne separate), crei un confine controllato tra il traffico pubblico e i tuoi servizi privati.

Qual era il problema di mismatch del nome host TLS?

Quando Cloudflare Tunnel si è connesso a Nginx Proxy Manager internamente usando un hostname Docker come reverse-proxy, il certificato TLS — emesso per un dominio pubblico come example.com — non corrispondeva. La soluzione è stata configurare Cloudflare Tunnel per usare il corretto Origin Server Name mantenendo comunque il routing verso l'hostname Docker interno. Questo ha preservato la crittografia completa senza disabilitare la validazione.

Come si confronta l'hardware di rete del ZimaCube 2 con un NAS standard per questo caso d'uso?

La maggior parte dei dispositivi NAS consumer è dotata di una singola porta Ethernet gigabit. Il ZimaCube 2 ha due porte 2.5GbE — il che significa che puoi dedicare un'interfaccia al traffico edge (Cloudflare + reverse proxy) e l'altra ai servizi interni. Questa separazione a livello fisico è qualcosa che non puoi ottenere con hardware a singola NIC.