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.

"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, 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 è completamente aperta.

Ho passato settimane a ricostruirlo. Il risultato: un livello di ingresso 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 seduto tranquillamente 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 dell’Ingresso Tradizionale negli Homelab

Molti homelab sono ancora così:

Porta 443 inoltrata sul router → punta a un reverse proxy
Porta 80 inoltrata → reindirizza a 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 ingresso esposte pubblicamente. Server di origine direttamente raggiungibili. Interfacce di amministrazione che rispondono prima dell’autenticazione. Anche con HTTPS, l’infrastruttura stessa 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’ingresso: fiducia solo in uscita, zero esposizione in ingresso e tunnel crittografati che nascondono l’origine.

Perché lo ZimaCube 2

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

Lo ZimaCube 2 ha soddisfatto ogni requisito:

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

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

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

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

Featured

ZimaCube 2 NAS domestico personale cloud

ZimaCube2

La Nuova Architettura

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

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

🔒 L’infrastruttura origin è completamente nascosta. Cloudflare sta davanti a tutto il traffico pubblico. Lo 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.

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. Solo quelli. Le applicazioni vivono su reti Docker interne separate — completamente isolate dallo strato 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 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 con una topologia di rete più complessa.

Il problema TLS che quasi mi ha fatto arrendere

Questa si è rivelata la lezione di ingegneria più interessante di tutto il progetto.

La configurazione sembrava semplice all’inizio. HTTP tra Cloudflare Tunnel e Nginx Proxy Manager funzionava immediatamente:

http://reverse-proxy → ✅ Funziona

Così 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 a 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 a quello sul certificato, la connessione fallisce — anche se tutto il resto è perfetto.

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

Questo è il tipo di lezione che impari solo costruendo.

ACL e la lezione sui percorsi del traffico infrastrutturale

Una lezione operativa che ho imparato molto rapidamente: i reverse proxy spesso vedono IP della rete 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 admin.

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

Aggiungere la subnet Docker alla lista consentiti ha risolto subito. Ma è stato un promemoria reale che i percorsi del traffico infrastrutturale spesso differiscono da quanto assumiamo sulla carta.

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

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 margine per eseguire tunnel, reverse proxy, motore ACL e tutti i tuoi servizi contemporaneamente
Espandibilità significa che puoi aggiungere una NIC dedicata o una scheda acceleratrice in seguito se le tue esigenze di rete crescono

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

Lo Stack Finale

Cosa gira ora sul ZimaCube 2:

Cloudflare Tunnel — connessioni crittografate 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

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

La più grande consapevolezza di questo progetto: il self-hosting moderno richiede sempre più spesso lo stesso approccio a ingress, networking e confini di fiducia tipico delle infrastrutture di produzione. E l'hardware deve stare al passo — silenzioso, affidabile, connesso in rete e sempre attivo.

Il 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 collegava 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.