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.

Como Transformei o ZimaCube 2 Numa Controladora de Ingressos Zero-Trust para Todo o Meu Homelab

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

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

💡

Destaque da Comunidade: Michael Luckenbill, Programa Pioneiro ZimaCube 2

O teu homelab tem uma porta da frente. Se és como a maioria dos self-hosters, essa porta da frente é um encaminhamento de porta no teu router — e está completamente aberta.

Passei semanas a reconstruir o meu. O resultado: uma camada de ingresso de nível produção a correr inteiramente num ZimaCube 2. Sem portas abertas no meu router. Sem servidores de origem acessíveis publicamente. TLS ponta a ponta em todas as ligações. Tudo isto a funcionar silenciosamente ao lado da minha TV.

Aqui está exatamente como o construí, o que falhou pelo caminho e por que o ZimaCube 2 acabou por ser a plataforma perfeita para o trabalho.

O Problema com o Ingresso Tradicional em Homelabs

Muitos homelabs ainda se parecem com isto:

Porta 443 encaminhada no router → aponta para um proxy reverso
Porta 80 encaminhada → redireciona para 443
Os serviços são diretamente acessíveis se souberes o IP
A infraestrutura de origem está a um scan de porta de ser descoberta

Isto cria problemas reais. Portas de ingresso expostas publicamente. Servidores de origem diretamente acessíveis. Interfaces de administração que respondem antes da autenticação. Mesmo com HTTPS, a infraestrutura permanece visível — e a visibilidade convida à recolha de informações.

Queria um modelo diferente. Algo mais próximo de como a infraestrutura cloud moderna gere o ingresso: confiança apenas de saída, exposição zero de entrada e túneis encriptados que escondem a origem.

Porquê o ZimaCube 2

Este tipo de arquitetura exige um conjunto específico de características de hardware. Não potência bruta — fiabilidade, flexibilidade e silêncio.

O ZimaCube 2 cumpriu todos os requisitos:

Sempre Ligado: Operação silenciosa 24/7.
A camada de ingresso tem de funcionar continuamente — o design térmico do ZC2 permite isso sem dominar a sala.

Dual 2.5GbE: Uma interface para a rede de borda, outra para a interna. A segmentação do tráfego começa na camada física, não apenas no Docker.

Docker Nativo: Armazenamento NVMe para I/O rápido de containers. Múltiplas redes bridge não sobrecarregam o sistema. A plataforma foi construída para isto.

Neste ponto, o ZimaCube 2 tornou-se efetivamente quatro coisas numa só máquina: um host Docker, uma plataforma de proxy reverso, uma camada de ingresso e um aparelho de infraestrutura centralizado. Para self-hosting moderno, essa combinação é extremamente prática.

Featured

ZimaCube 2 NAS Doméstico de Nuvem Pessoal

ZimaCube2

A Nova Arquitetura

Em vez de abrir portas no meu router, o novo design funciona assim:

Cloudflare Tunnel cria ligações encriptadas apenas de saída para a borda da Cloudflare
Nginx Proxy Manager gere o encaminhamento, terminação SSL e ACLs
Redes bridge Docker segmentam o tráfego de borda dos workloads internos
Zero regras NAT de entrada — o router não tem ideia de que algo está a ser servido

🔒 A infraestrutura de origem está completamente oculta. O Cloudflare está à frente de todo o tráfego público. O ZimaCube 2 só faz ligações de saída. Nada escuta numa porta pública.

Isto imediatamente pareceu mais próximo da arquitetura moderna de entrada em cloud do que do self-hosting tradicional com encaminhamento de portas.

Segmentação de Rede Docker: Edge ≠ Interna

Uma das mudanças mais importantes foi separar o tráfego usando redes bridge Docker.

docker network create \

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

edge

A rede edge transporta exatamente dois contentores: Cloudflare Tunnel e Nginx Proxy Manager. Só isso. As aplicações vivem em redes Docker internas separadas — completamente isoladas da camada de entrada.

🎁 Nem todos os contentores devem estar adjacentes à internet. Se o seu servidor Plex, instância Vaultwarden ou executor CI/CD partilhar uma rede com o seu reverse proxy, um serviço comprometido dá ao atacante acesso a tudo o resto.

O ZimaCube 2 gere esta segmentação de forma limpa. Múltiplas redes bridge não criam sobrecarga de desempenho na plataforma, e o armazenamento NVMe garante que o arranque dos contentores e o I/O de rede se mantenham rápidos mesmo quando a topologia da rede se torna mais complexa.

O Problema TLS Que Quase Me Quebrou

Isto acabou por ser a lição de engenharia mais interessante de todo o projeto.

A configuração parecia simples à primeira vista. O HTTP entre o Cloudflare Tunnel e o Nginx Proxy Manager funcionou imediatamente:

http://reverse-proxy → ✅ Funciona

Então ativei o HTTPS.

https://reverse-proxy → ❌ Falha

O certificado era válido. A data de expiração estava correta. A cadeia de confiança estava verificada. Tudo parecia correto — e ainda assim o HTTPS recusava-se a ligar.

O verdadeiro problema foi a validação do nome do host TLS.

O certificado foi emitido para os meus domínios públicos (example.com, app.example.com). Mas o Cloudflare Tunnel estava a ligar-se internamente ao reverse-proxy — um nome de host Docker que não correspondia a nada no certificado. A incompatibilidade do nome do host causou a falha silenciosa da validação TLS.

💡 A validação TLS não se trata apenas da confiança e expiração do certificado. Também valida a identidade do nome do host e as expectativas do SNI. Se o nome na URL não corresponder ao nome no certificado, a ligação falha — mesmo que tudo o resto esteja perfeito.

A solução: configurar o Cloudflare Tunnel com o Nome do Servidor de Origem: example.com enquanto ainda se faz o encaminhamento interno para https://reverse-proxy:443. Isso preservou o transporte encriptado, a validação correta do nome do host e a verificação completa do TLS — sem desativar quaisquer verificações de segurança.

Este é o tipo de lição que só se aprende a construir.

ACLs e a Lição Sobre os Caminhos do Tráfego na Infraestrutura

Uma lição operacional que aprendi muito rapidamente: proxies reversos frequentemente veem IPs da bridge Docker, IPs do túnel e IPs do proxy interno em vez do IP original do cliente.

Aprendi isto da pior forma quando me bloqueei acidentalmente fora do Nginx Proxy Manager.

Configurei uma ACL para permitir apenas a minha sub-rede LAN (192.168.x.x/24). A lógica parecia correta — só dispositivos na minha rede doméstica deveriam aceder ao painel de administração.

O NPM estava na verdade a ver tráfego da rede bridge Docker. Não da minha LAN. O controlo de acesso bloqueou tudo, incluindo a mim.

Adicionar a sub-rede Docker à lista de permissões resolveu imediatamente. Mas foi um lembrete real de que os caminhos do tráfego na infraestrutura são muitas vezes diferentes do que assumimos no papel.

🔄 Num ambiente conteinerizado, o IP original do cliente é reescrito em múltiplos saltos: borda Cloudflare → túnel → bridge Docker → proxy reverso. Cada salto altera o endereço de origem. As suas regras de firewall precisam de considerar o caminho real do tráfego, não o que imagina.

Porque Esta Arquitetura Importa no ZimaCube 2

Há uma razão pela qual esta pilha funciona tão bem especificamente no ZC2:

Dual 2.5GbE significa que a camada de ingresso tem largura de banda dedicada — o tráfego da sua rede interna não compete com os serviços expostos à internet
Armazenamento NVMe garante rede rápida para containers — a largura de banda da rede bridge não fica limitada por I/O lento do disco
Funcionamento silencioso sempre ligado significa que a camada de ingresso funciona 24/7 num espaço habitado — não num rack na cave
Plataforma nativa Docker com capacidade suficiente para correr o túnel, proxy reverso, motor ACL e todos os seus serviços simultaneamente
Expansibilidade significa que pode adicionar uma NIC dedicada ou uma placa aceleradora mais tarde se as suas necessidades de rede crescerem

O ZimaCube 2 não está apenas a hospedar estes serviços. É a plataforma certa para eles.

A Pilha Final

O que está a correr no ZimaCube 2 agora:

Cloudflare Tunnel — conexões encriptadas só de saída, zero portas abertas
Nginx Proxy Manager — proxy reverso, SSL, ACLs
Redes bridge Docker — tráfego segmentado entre borda e interno
TLS de ponta a ponta — encriptado do cliente à origem, sem texto simples em lado algum
Origem oculta — nada responde num IP público

Ainda é um homelab. Mas o modelo operacional agora se assemelha muito mais à engenharia moderna de ingressos do que ao self-hosting tradicional com encaminhamento de portas.

A maior conclusão deste projeto: o self-hosting moderno requer cada vez mais o mesmo pensamento de entrada, rede e fronteira de confiança encontrado na infraestrutura de produção. E o hardware tem de acompanhar — silencioso, fiável, em rede e sempre ligado.

O ZimaCube 2 oferece exatamente isso.

Construa o seu próprio homelab de confiança zero com o ZimaCube 2 →

Perguntas Frequentes

O que é um Cloudflare Tunnel e porque é que eu o usaria no meu ZimaCube 2?

Um Cloudflare Tunnel cria uma ligação encriptada só de saída do seu ZimaCube 2 para a rede de borda da Cloudflare. Em vez de abrir portas no seu router (o que expõe a sua infraestrutura à internet), todo o tráfego passa por este túnel encriptado. O seu servidor de origem — o ZimaCube 2 — permanece completamente oculto da vista pública.

Preciso de abrir alguma porta no meu router para esta configuração?

Não. Esse é o objetivo. O Cloudflare Tunnel só faz ligações de saída. O seu router não precisa de nenhuma regra de encaminhamento de porta. Isto elimina o vetor de ataque mais comum em redes de homelab.

O ZimaCube 2 consegue executar um proxy reverso e todos os meus serviços ao mesmo tempo?

Sim. O Michael ZC2 executa simultaneamente o Cloudflare Tunnel, o Nginx Proxy Manager e mais de 10 contentores Docker — tudo isto mantendo uma operação silenciosa e fresca. As portas duplas 2.5GbE e o armazenamento NVMe garantem que a rede e o I/O dos contentores não se tornam gargalos.

Porque é que a segmentação da rede Docker é importante?

Se todos os contentores partilharem a mesma rede, um serviço comprometido dá ao atacante acesso a tudo o resto. Ao colocar apenas o Cloudflare Tunnel e o Nginx Proxy Manager numa rede "de borda" (e mantendo as aplicações em redes internas separadas), cria-se uma fronteira controlada entre o tráfego público e os seus serviços privados.

Qual foi o problema de incompatibilidade do nome de host TLS?

Quando o Cloudflare Tunnel se ligou ao Nginx Proxy Manager internamente usando um nome de host Docker como reverse-proxy, o certificado TLS — que foi emitido para um domínio público como example.com — não correspondia. A solução foi configurar o Cloudflare Tunnel para usar o Nome do Servidor de Origem correto enquanto ainda encaminhava para o nome de host Docker interno. Isto preservou a encriptação total sem desativar a validação.

Como é que o hardware de rede do ZimaCube 2 se compara a um NAS padrão para este caso de uso?

A maioria dos dispositivos NAS para consumidores vem com uma única porta Ethernet gigabit. O ZimaCube 2 tem duas portas 2.5GbE — o que significa que pode dedicar uma interface ao tráfego de borda (Cloudflare + proxy reverso) e a outra aos serviços internos. Esta separação a nível físico é algo que não consegue alcançar com hardware de NIC única.