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.

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

💡

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 de produção a funcionar inteiramente num ZimaCube 2. Sem portas abertas no meu router. Sem servidores de origem acessíveis publicamente. TLS de ponta a ponta em todas as ligações. Tudo isso 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 em si permanece visível — e a visibilidade convida à recolha de informações.

Eu queria um modelo completamente diferente. Algo mais próximo de como a infraestrutura moderna de cloud lida com ingressos: confiança apenas para saída, zero exposição de entrada e túneis encriptados que escondem a origem.

Diagrama da arquitetura tradicional de Homelab mostrando o fluxo de encaminhamento de portas: Internet, router, proxy reverso e containers Docker

Por que 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 que isso aconteça sem dominar a sala.

Dual 2.5GbE: Uma interface para a rede de borda, outra para a interna. A segmentação de 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 isso.

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

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

A Nova Arquitetura

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

Cloudflare Tunnel cria ligações encriptadas só de saída para a edge do Cloudflare
Nginx Proxy Manager gere o encaminhamento, terminação SSL e ACLs
Redes bridge Docker segmentam o tráfego edge 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 fica à 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.

Diagrama final da arquitetura segura do homelab a correr no ZimaCube 2 com Cloudflare Tunnel, Nginx Proxy Manager e encriptação TLS de ponta a ponta

Segmentação de Rede Docker: Edge ≠ Interna

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

docker network create \

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

edge

A rede edge transporta exatamente dois containers: 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 containers devem estar expostos à internet. Se o seu servidor Plex, instância Vaultwarden ou executor CI/CD partilha uma rede com o seu proxy reverso, 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 a inicialização dos containers 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

Este acabou por ser o ensinamento 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 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 é apenas sobre confiança e expiração do certificado. Também valida a identidade do nome do host e as expectativas de 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 correção: configurar o Cloudflare Tunnel com o Nome do Servidor de Origem: example.com enquanto ainda se encaminha internamente para https://reverse-proxy:443. Isso preservou o transporte encriptado, validação correta do nome do host e 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.

Painel de administração da visão geral SSL/TLS da Cloudflare com modo de encriptação Full strict, diagrama de encriptação do tráfego do navegador para o servidor de origem

ACLs e a lição sobre os caminhos do tráfego da infraestrutura

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

Aprendi isto da pior forma quando acidentalmente me bloqueei 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 — apenas dispositivos na minha rede doméstica deveriam aceder ao painel de administração.

O NPM estava na verdade a ver tráfego da rede da ponte 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 muito real de que os caminhos do tráfego da infraestrutura são frequentemente diferentes do que assumimos no papel.

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

Por que Esta Arquitetura é Importante 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 e sempre ligado significa que a camada de ingresso funciona 24/7 num espaço habitado — não num rack de 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 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 — ligações encriptadas apenas de saída, sem portas abertas
Nginx Proxy Manager — proxy reverso, SSL, ACLs
Redes bridge Docker — tráfego segmentado de borda vs. interno
TLS de ponta a ponta — encriptado do cliente à origem, sem texto simples em lado algum
Origem oculta — nada responde num IP público

Continua a ser um homelab. Mas o modelo operacional agora se assemelha muito mais à engenharia moderna de ingresso do que à auto-hospedagem tradicional com encaminhamento de portas.

A maior conclusão deste projeto: a auto-hospedagem moderna requer cada vez mais o mesmo pensamento de ingresso, rede e fronteira de confiança encontrado na infraestrutura de produção. E o hardware precisa acompanhar — silencioso, fiável, em rede e sempre ligado.

Diagrama da Arquitetura Moderna de Ingresso para Homelab comparando o design de túnel Cloudflare apenas de saída vs configuração tradicional arriscada de encaminhamento de portas

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 por que o usaria no meu ZimaCube 2?

Um Cloudflare Tunnel cria uma ligação encriptada apenas 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.